Baze de date Obiect de compresie 1C în prezent adesea discutate. Avantajele cunoscut de compresie - scădere a dimensiunii bazei de date, reducând sarcina pe subsistemul disc, și unele de accelerare a punerii în aplicare a operațiunilor de citire / scriere grele. Printre deficiențele - o mică creștere a sarcinii pe procesoare de server de baze de date ca urmare a consumului de resurse pentru comprimare / decomprimare a datelor. Dar, atunci când sunt utilizate ca MSSQL și DB2 (pentru Oracle și PostgreSQL nu pot spune pentru că nu știu) este un „pitfall“ - în cazul în care restructurarea are loc depresurizarea noi tabele și indici. Acest lucru poate avea loc atât atunci când efectuați o actualizare de configurare cu modificări în structura metadatelor, precum și la efectuarea testului și corectarea IB (Reindexați reconstruiește doar indicii și restructurarea - și tabelele și indexurile). „Problema“ constă în faptul că steagul de compresie este setat individual pentru fiecare masă și index.
Soluție pentru MS SQL Server.
Crearea DDL declanșează o operațiune pentru a crea un tabel:
CREATE TRIGGER [data_compression]
ON ALL SERVER
DUPĂ CREATE_TABLE
AS
--de declanșare a textului
Crearea DDL declanșează pentru crearea de index:
CREATE TRIGGER [index_compression]
ON ALL SERVER
DUPĂ CREATE_INDEX
AS
--de declanșare a textului
Pentru a seta paginile de caracteristici de compresie pentru tabel rulați codul:
ALTER TABLE [numele bazei de date]. [Nume schemă]. [Numele tabelului] REBUILD PARTITIE = ALL WITH (DATA_COMPRESSION = PAGE)
Pentru a seta paginile de caracteristici de compresie pentru indicele nevoie pentru a rula codul:
ALTER INDEX [name index] ON [numele bazei de date]. [Nume schemă]. [Numele tabelului] REBUILD PARTITIE = ALL WITH (DATA_COMPRESSION = PAGE)
În general, acest lucru este deja suficient pentru a crea un mecanism viabil care să nu permită 1C pentru a crea un nou tabel sau indexeze, fără compresie, dar am vrut mai multă flexibilitate în setările :).
Mai jos este o soluție în forma în care este utilizat aici. Acest lucru se va aplica în mod automat de compresie pentru toate bazele de date de pe server.
Creat de baze de date de servicii CompressionSetting cu două tabele:
1) - Baze de date pentru a stoca o listă de baze de date, care nu comprima necesare.
CREATE TABLE [DBO]. [Baze de date] (
[Name] [nvarchar] (100) NULL,
[Activ] [int] NULL
) ON [PRIMARY]
200 baze de date de pe server am făcut în acest tabel doar un singur - tempdb:
2) Trace - pentru monitorizarea DDL-flops
CREATE TABLE [DBO]. [Trace] (
[Text] [nvarchar] (max) NULL,
[Databasename] [nvarchar] (max) NULL,
[DateTime] [datetime] NULL
) ON [PRIMARY]
Apoi, creați un declanșator DDL-2:
Imediat după crearea declanșatoare nici o schimbare in cantitatea de baze, desigur, nu se va întâmpla. Pentru a comprima bazele de date existente, puteți utiliza următoarele metode:
1) scrie un scenariu pentru sortare alternativ tabele și indexurile și setările de compresie pentru aceste caracteristici. Nu-mi place această opțiune, deoarece Compresia de mese mari necesită o mulțime de timp cu swells de bază, și apoi un timp foarte lung este redus prin BAZA DE DATE SHRINK.
2) Se efectuează o restructurare completă prin „Testare și corecție.“ Până când mai repede, dar, de asemenea, se umfla de bază, și atunci ar trebui să reducă cu BAZA DE DATE SHRINK.
3) Opțiunea cea mai optimă, în opinia mea - pentru a recrea baza de date prin intermediul dt-fișier. În acest caz, baza finită va fi inițial o dimensiune minimă, iar baza timpului de încărcare de compresie este puțin diferită de boot în mod normal.
“... Putem presupune poziția pe care noi credem că utilizarea acestor oportunități ar trebui să fie fie interzise sau permise, dar cu suport adecvat (metodologic sau software). Opțiunea de a le utiliza fără sprijinul adecvat, credem greșit, deoarece duce la probleme în administrare. "
Astfel, nu cred că propun o abordare care urmează să fie utilizate în cantități mari.
Administratorul, care a decis că ar trebui să fie clar înțeles ce făcea și ceea ce ar putea fi consecințele.
20. Tatiana Lustina (Silverbulleters) 126 09/04/16 23:51 Acum subiect
Cred că pentru a aduce în discuție subiectul, pentru cei care citesc acest articol în viitor
de fapt, în acest moment există o anumită situație contradictorie
este clar - structura ALTER TABLE, ALTER INDEX (de asemenea, întâmplător ca și CREATE INDEX) este o interferență în structura bazei de date (date schimbare schemă), care este interzisă prin acordul de licență.
* Cu toate acestea, în multe societăți în posesia finală MSSQL Enterprise Management Alte documente, și anume,
pentru leneși care nu doresc să meargă la link-ul cita
Ce se poate comprima? Orice în lista de mai jos, care îndeplinește criteriile de mai sus ...
Un tabel cu nici o organizație ( „heap“ structură);
Un tabel organizat ca un index grupat;
Un indice nonclustered;
O vedere indexată (amintiți-vă, acestea persistă pe disc);
tabele și indexurile partiționate (fiecare partiție poate fi configurat în mod diferit);
După cum ne amintim cu toții, suntem interesați
Un tabel organizat ca un index grupat;
Un indice nonclustered;
deoarece acestea sunt principalele tipuri de plăci noastre în 1C mondială.
Îmi permit să citez
Comprimarea datelor oferă mai multe beneficii. Se economisește spațiu pe disc, și poate ajuta la îmbunătățirea performanțelor anumitor sarcini de lucru. Beneficiile de compresie a datelor vin la costul de utilizare a procesorului mai mare pentru comprimarea și decomprimarea datelor. Prin urmare, este important să se înțeleagă caracteristicile volumului de lucru pe o masă înainte de a decide cu privire la o strategie de compresie. Comprimarea datelor oferă flexibilitate în ceea ce privește nivelurile de compresie (rând sau pagina) și obiectele pe care le puteți comprima (tabel, index, partiție). Acest lucru permite reglarea fină compresia pe baza caracteristicilor de date și volumul de muncă.
Un alt avantaj important al compresiei de date este că funcționează în mod transparent la aplicarea, și funcționează bine cu alte caracteristici SQL Server, cum ar fi TDE și de compresie de rezervă.
Rezultatele prezentate în această lucrare albă se bazează pe datele și hardware-ul utilizat în testele noastre. Rezultatele vor varia în funcție de propria dvs. de date, volumul de muncă și hardware. Efectuați testarea amănunțită atunci când se decide ce tabele și indexurile pentru a comprima.
Punct foarte important
Un alt avantaj important al compresiei de date este că este transparent, la cerere, și funcționează bine cu alte caracteristici SQL Server, cum ar fi TDE și de compresie de rezervă.
adică fără niciun risc. s-ar părea, cu toate acestea.
compresie de implementare este un proces cu mai multe etape:
Figura ce obiecte ar trebui să comprimați
Planul de a se ocupe de toate mediile (dev, QA, producție)
Comprimarea-le în timpul unei ferestre cu activitate scăzută
patrulează regulat mediile de verificare pentru obiectele adăugate care nu au fost comprimate
Păstrați mediile sincronizate
Să acorde o atenție recomandărilor de la Microsoft ingineri PFE
* Planul exact ce obiecte TREBUIE stoarce
* Utilizarea de compresie pe toate aplicatiile sale contururi, nu numai productiv
* Compresia este aplicat în timpul perioadelor de activitate inferioară
* Verificati in mod regulat ce obiecte nu sunt comprimate
* Mediu Sincronizați
pentru cei care nu știu - există o astfel de versiune dificil ca Developer Edition SQL Server, această versiune este pe deplin funcțional și este proiectat pentru a testa funcționalitatea dezvoltator până Enterprise, pe circuitul de testare (nu productiv)
Dar să revenim la contradicția - după cum vom vedea utilizarea de compresie, necesită inginer intern pentru SQL Server și de management anumit este procesul de proprietate a SQL Server.
Și acum devine clar de ce conferința de partener a fost răspuns
Opțiunea de a le utiliza fără sprijinul adecvat, credem greșit, deoarece duce la probleme în administrare.
după cum vom vedea în partea de sus, este, în general, în concordanță cu recomandările companiei Microsoft - buzdumno și fără sprijinul includ compresie pur și simplu nu Practics cele mai bune de la Microsoft.
Și acum o notă mică - Dacă utilizați o compresie sfătuim să luați cunoștință cu un lucru mai interesant
DBA competent, de compresie, și povestea tempdb pentru a accelera SPP de 4,5 ori cel puțin ;-).
24. Antonio Antonio (Fragster) 702 12/09/16 12:45 Acum subiect
Am închis pe trăgaci pe bază de teste, a modificat textul astfel:
CREATE TRIGGER [data_compression]
baza de date
DUPĂ CREATE_TABLE
AS
DECLAR
@SchemaName nvarchar (150),
@ObjectName nvarchar (150),
@DatabaseName nvarchar (150),
nvarchar @cmd (500)
--Obține numele de schemă a comenzii fiind executate CRE ATE TABLE
SET @SchemaName = EVENTDATA (). Valoare ( '(/ EVENT_INSTANCE / SchemaName) [1]', 'nvarchar (150)')
--Obținem numele tabelului
SET @ObjectName = EVENTDATA (). Valoare ( '(/ EVENT_INSTANCE / ObjectName) [1]', 'nvarchar (150)')
--Obținem numele bazei de date
SET @DatabaseName = EVENTDATA (). Valoare ( '(/ EVENT_INSTANCE / databasename) [1]', 'nvarchar (150)')
--Formăm comanda dorită din datele recepționate pe un tabel care prezintă caracteristici de compresie
set @cmd = 'ER TABLE ALT [' + @DatabaseName + ']. [' + @SchemaName + ']. [' + @ObjectName + '] REBUILD PARTITIE = ALL WITH (DATA_COMPRESSION = PAGE)'
--Acum, verificați setările - în cazul în care baza de date nu este în tabel cu un semn CompressionSetting.dbo.Databases activ = 1, apoi executați comanda, sau ignora
INS ERT ÎN CompressionSetting.dbo.trace (text, databasename, DateTime) SELE CT @cmd, @DatabaseName, getDate ()
Am primit o eroare în restructurare:
În procesul de actualizare a bazei de cunoștințe a avut loc eroare critică
din cauza:
Eroare bază de date:
Microsoft SQL Server Client nativ 11.0: Nu se poate găsi obiectul „dbo._Node6782NG“, deoarece nu există sau nu aveți permisiuni.
HRESULT = 80040E37, SQLSrvr: SQLSTATE = 42S02, starea = C, Severitatea = 10, nativ = 1088, linia = 1
25. Aleksey Bochkov (Aleksey.Bochkov) 2725 14/12/16 8:33 Acum subiect
26. Evgeny Voropaev (user643364_voropaev.evgeny) 20.02.17 19:10 Acum subiect
Bună ziua tuturor!
900Mb.
Pentru a face acest lucru, utilizați standard, așa cum este descris, procedura de transfer de: după descărcare-încărcare a bazei de date fișier de transfer de date.
Dar, în timpul transferului către fișierul SQL timpul de descărcare, Konfigurator1S eroare Stop pe SQLya, printskrin pe care am citat.
În orice caz, aici merge:
SQL Stare: 23000
Nativ: 1505
Mesaj: [Microsoft] [ODBC SQL Server Driver] [SQL Server] CREATE UNIQUE INDEX încheiată, deoarece a fost găsită o cheie duplicat pentru indexul ID2. Cea mai semnificativă cheie primară este „15N“.
SQL Stare: 01000
Nativ: 3621
Mesaj: [Microsoft] [ODBC SQL Server Driver] [SQL Server] Declarația a fost încheiată.
Gestuală punctul de testare și baza de date de reabilitare a 1C Konfiguratora- nu afectează rezultatul: O eroare nu dispare.
Cam Nu sunt un programator 1C și SQL dba. Sunt un specialist în rețele.
27. Aleksey Oleshko (Retif) 12.04.17 10:44 Acum subiect
Sozdanie29.01.12 14:52
Obnovlenie09.12.16 09:34
Codul indicat otkrytNe
