Adatbázis tömörítés 1C MS SQL Server
Tárgy adatbázisok 1C kompressziós jelenleg gyakran tárgyalt. Előnyei kompressziós ismert - mérete csökken az adatbázis, csökkenti a terhelést a lemezalrendszer, és néhány végrehajtásának felgyorsítását nehéz olvasási / írási műveleteket. Között a hiányosságok - kis mértékű növekedése a terhelés az adatbázis szerver processzorok miatt fogyasztása források tömörítés / kicsomagolás adat. De amikor használják MSSQL és DB2 (az Oracle és PostgreSQL nem lehet azt mondani, mert nem tudom) egy „buktató” - a szerkezetátalakítási zajlik dekompressziós új táblák és indexek. Ez akkor fordulhat elő mind során végrehajtott konfiguráció frissítés változások a szerkezetben a metaadatok, és amikor a vizsgálat elvégzése és a korrekció IB (újraindexelésé felépíti csak az indexek és az átalakítást -, és a táblák és indexek). „A probléma” abban rejlik, hogy a kompresszió jelző egyedileg tábla és index.
Megoldás az MS SQL Server.
Létrehozása DDL kiváltó művelet, hogy hozzon létre egy táblázatot:
CREATE TRIGGER [data_compression]
MINDEN SERVER
UTÁN CREATE_TABLE
AS
--szöveg ravaszt
Létrehozása DDL kiváltó index létrehozása:
CREATE TRIGGER [index_compression]
MINDEN SERVER
UTÁN CREATE_INDEX
AS
--szöveg ravaszt
Állítsa be a tömörítés funkció oldalak az asztalra futtatja a kódot:
ALTER TABLE [adatbázis neve]. [Sémanév]. [Táblázat neve] REBUILD partíció = MIND (DATA_COMPRESSION = PAGE)
Állítsa be a tömörítés funkció oldalak az index kell futtatni a kódot:
ALTER INDEX [index neve] Az [adatbázis neve]. [Sémanév]. [Táblázat neve] REBUILD partíció = MIND (DATA_COMPRESSION = PAGE)
Általában ez már elég ahhoz, hogy hozzon létre egy működőképes mechanizmus, amely nem tenné 1C hogy hozzon létre egy új tábla vagy index tömörítés nélkül, de szerettem volna nagyobb rugalmasságot beállítások :).
Az alábbiakban egy olyan megoldás, abban a formában, amelyben használjuk itt. Ez automatikusan alkalmazni tömörítés minden adatbázis a szerveren.
Alkotó CompressionSetting szolgáltatás adatbázisban két táblázatot:
1) adatbázisok - tárolja a listát az adatbázisok, amelyek összenyomódnak nem szükséges.
CREATE TABLE [dbo]. [Adatbázisok] (
[Név] [nvarchar] (100) NULL,
[Aktív] [int] NULL
) ON [Elsődleges]
200 adatbázisokat a szerver tettem ebben a táblázatban csak egy - tempdb:
2) Trace - ellenőrzésére DDL-flop
CREATE TABLE [dbo]. [Trace] (
[Text] [nvarchar] (max) NULL,
[DatabaseName] [nvarchar] (max) NULL,
[DateTime] [datetime] NULL
) ON [Elsődleges]
Ezután hozzon létre egy DDL-2 Trigger:
Közvetlenül létrehozását követően kiváltó változás nem az összeg a bázisok, természetesen, nem fog megtörténni. Tömöríteni meglévő adatbázisok, akkor az alábbi módszerekkel:
1) Írj egy script felváltva válogató táblák és indexek és a tömörítési beállításokat ezekhez a funkciót. Nem szeretem ezt az opciót, mert A tömörítés nagy táblák igényel sok időt a bázis megduzzad, majd nagyon sokáig csökkentjük ZSUGORODÓ tárol.
2) Végezzünk teljes átalakítását, a „Tesztelés és korrekció.” Mire gyorsabban, hanem bázis megduzzad, és akkor kellene csökkenteni ZSUGORODÓ tárol.
3) A legoptimálisabb beállítás, véleményem -, hogy újra az adatbázis segítségével dt-fájlt. Ebben az esetben a kész alap kezdetben egy minimális méretet, és az alapja a kompressziós betöltési ideje kicsit különbözik a boot rendesen.
”... Azt is feltételezhetjük, hogy a helyzet úgy véljük, hogy ezeknek a használata lehetőségeket kell tiltani vagy sem megengedett, de megfelelő támogatást (módszertani vagy szoftver). Az opció használata őket anélkül, hogy megfelelő támogatást, úgy véljük, hibás, mert problémákhoz vezet az adminisztráció. "
Így nem hiszem, hogy azt javaslom megközelítést kell alkalmazni nagy mennyiségben.
Az adminisztrátor, aki úgy döntött, hogy tisztában kell lenni azzal, hogy mit csinál, és milyen következményei lehetnek.
az
20. Tatiana Lustina (Silverbulleters) 126 09/04/16 23:51 Most a témában
Azt hiszem, hogy ki a témában, azok számára, akik olvasni ezt a cikket a jövőben
sőt, abban a pillanatban van néhány ellentmondásos helyzetet
egyértelmű - a szerkezet ALTER TABLE, ALTER INDEX (is mellesleg a CREATE INDEX) egy interferencia az adatbázis szerkezet (séma Adatok módosítása), amelyet tilt a licencszerződést.
* Azonban sok vállalat az utolsó birtokában MSSQL Enterprise Management többi dokumentumot, nevezetesen,
a lusta, aki nem akar menni a linket idézni
Mit lehet tömöríteni? Bármi az alábbi listában, amely megfelel a fenti kritériumoknak, ...
Egy asztal egyetlen szervezet ( „halom” szerkezet);
A táblázat szervezett, mint a fürtözött index;
A fürtözött index;
Egy indexelt nézet (ne felejtsük, ezek meg is fennállnak a lemezen);
Particionált táblák és indexek (minden partíción külön konfigurálható);
Mint mindannyian emlékezni, mi érdekli
A táblázat szervezett, mint a fürtözött index;
A fürtözött index;
mivel ezek a főbb mi lemezeket a világon 1C.
Megengedem magamnak, hogy jegyezze
Az adattömörítés számos előnnyel jár. Ez lemezterületet takarít, és ez javíthatja a teljesítményt bizonyos terhelések. Az előnyök adattömörítés jön árán magasabb CPU használat számára tömörítő és az adatokat. Ezért fontos, hogy megértsük a terhelési jellemző az asztalra mielőtt egy kompressziós stratégia. Az adattömörítés rugalmasságot biztosít szempontjából szintek tömörítés (sor- vagy), és a tárgyak akkor tömöríteni (asztal, index, partíció). Ez lehetővé teszi a finomhangolás a kompressziós tulajdonságai alapján az adatok és a munkateher.
Egy másik fontos előnye, adattömörítés, hogy működik átláthatóan az alkalmazást, és jól működik más SQL Server funkciók, mint például a TDE és hát tömörítés.
Az eredményeket ebben a fehér papír adatai alapján és az alkalmazott hardver a tesztek során. Az eredmények függ a saját adatait, a terhelés és a hardver. Végezze alapos tesztelés, amikor arról döntenek, milyen táblák és indexek tömöríteni.
nagyon fontos pont
Egy másik fontos előnye, adattömörítés, hogy átlátható legyen a kérelmet, és jól működik más SQL Server funkciók, mint a TDE és hát tömörítés.
vagyis nincs kockázata. úgy tűnik azonban.
Megvalósítása tömörítés egy többlépéses folyamat:
Kitalálni, hogy milyen objektumokat kell tömöríteni
Terv, hogy kezelje az összes környezetben (dev, QA, termelés)
Tömöríteni őket során alacsony aktivitású ablakban
Rendszeresen járőröznek a környezet ellenőrzése hozzáadott objektumokat, amelyek nem tömörített
Tartsa a környezetben szinkronban
Ügyeljen arra, hogy ajánlásokat a Microsoft mérnökei PFE
* Terv pontosan milyen tárgyakat MUSZÁJ présel
* A tömörítés minden kontúrok alkalmazása nemcsak produktív
* A tömörítés során alkalmazott időszakok alacsonyabb aktivitású
* Rendszeresen ellenőrizze, milyen objektumokat nem tömöríti
* Szinkronizálás környezet
azok számára, akik nem tudják, - van egy ilyen trükkös változata az SQL Server Developer Edition, ez a változat teljesen működőképes, és célja, hogy teszteljék a funkciókat a fejlesztő, míg az Enterprise, a vizsgálati áramkör (nem termelő)
De térjünk vissza az ellentmondás - mint látjuk a használata tömörítés, megköveteli a hazai mérnök SQL Server és az egyes menedzsment a tulajdonosi jogosultságot az SQL Server.
És most kiderül, hogy miért a partner konferencia válaszol
Az opció használata őket anélkül, hogy megfelelő támogatást, úgy véljük, hibás, mert problémákhoz vezet az adminisztráció.
mint látjuk, a tetején ez általában ajánlásaival összhangban a vállalat a Microsoft - buzdumno és támogatása nélkül tartalmazzák tömörítés csak nem a legjobb Practics a Microsoft.
És most egy kis megjegyzés - Ha egy kompressziós tanácsolom, hogy megismerjék egy érdekes dolog
Az illetékes DBA, tömörítés, és a történet a tempdb felgyorsítása SPP 4,5-szer legalább ;-).
24. Antonio Antonio (Fragster) 702 12/09/16 12:45 Most a témában
Letettem a ravaszt kísérleti alapon szövege megváltozott oly módon:
CREATE TRIGGER [data_compression]
Az adatbázis
UTÁN CREATE_TABLE
AS
DECLARE
@SchemaName nvarchar (150),
@ObjectName nvarchar (150),
@DatabaseName nvarchar (150),
@cmd nvarchar (500)
--Szerezze be a séma nevét a parancs végrehajtásakor CRE ATE TABLE
SET @SchemaName = EVENTDATA (). Érték ( '(/ EVENT_INSTANCE / SchemaName) [1]', 'nvarchar (150)')
--Megkapjuk a tábla neve
SET @ObjectName = EVENTDATA (). Érték ( '(/ EVENT_INSTANCE / ObjectName) [1]', 'nvarchar (150)')
--Megkapjuk az adatbázis neve
SET @DatabaseName = EVENTDATA (). Érték ( '(/ EVENT_INSTANCE / DatabaseName) [1]', 'nvarchar (150)')
--Mi, a kívánt parancsot a kapott adatokat a tömörítés, jellegzetes asztal
beállítva @cmd = 'ALT ER TÁBLÁZAT [' + @DatabaseName + ']. [' + @SchemaName + ']. [' + @ObjectName + '] REBUILD partíció = MIND (DATA_COMPRESSION = PAGE)'
--Most ellenőrizze a beállításokat - ha az adatbázis nem szerepel a táblázatban a jel CompressionSetting.dbo.Databases Active = 1, akkor futtatja a parancsot, vagy figyelmen kívül hagyja
INS ERT INTO CompressionSetting.dbo.trace (szöveg, DatabaseName, DateTime) SELE CT @cmd, @DatabaseName, getdate ()
Van egy hiba a szerkezetátalakítás:
A folyamat során a frissítése a tudásbázis Kritikus hiba történt
miatt:
Adatbázis hiba:
A Microsoft SQL Server Native Client 11,0: Nem találja a tárgy „dbo._Node6782NG”, mert nem létezik, vagy nem rendelkezik jogosultsággal.
HRESULT = 80040E37, SQLSrvr: SQLSTATE = 42S02, állapot = C, súlyossága = 10, natív = 1088 vonal = 1
25. Aleksey Bochkov (Aleksey.Bochkov) 2725. 14/12/16 08:33 Most a témában
26. Evgeny Voropaev (user643364_voropaev.evgeny) 20.02.17 19:10 Most a témában
Jó napot mindenkinek!
900Mb.
Ehhez használja a normál, a leírtak szerint, az eljárást az átadás: a kirakodás után betöltés adatátvitel adatbázis.
De az átvitel során az SQL fájl letöltése időben Konfigurator1S Stop hiba a SQLya, printskrin amely idézek.
Mindenesetre, itt megy:
SQL Állam: 23000
Natív: 1505
Üzenet: [Microsoft] [ODBC SQL Server Driver] [SQL Server] Készítsen egyedi INDEX leállt, mert pótkulcsot találtak index ID2. A legtöbb jelentős elsődleges kulcs „15N”.
SQL Állam: 01000
Natív: 3621
Üzenet: [Microsoft] [ODBC SQL Server Driver] [SQL Server] A nyilatkozatot megszűnt.
Gesztus bekezdés tesztelés és kármentesítés adatbázisa 1C Konfiguratora- nem befolyásolja az eredményt: Hiba nem megy el.
Cam nem vagyok programozó 1C és SQL dba. Vagyok szakértője hálózatokban.
27. Aleksey Oleshko (RETIF) 12.04.17 10:44 Most a témában
Sozdanie29.01.12 14:52
Obnovlenie09.12.16 09:34
Kód jelzett otkrytNe
