Maraming Microsoft Administrator SQL Server nahaharap sa problema ng isang makabuluhang pagtaas sa pisikal na laki ng database at mga file ng log ng transaksyon at, siyempre, nais nilang kahit papaano ay bawasan ang laki na ito upang hindi gumawa ng anumang aksyon na may kaugnayan sa pagtaas ng libreng espasyo sa hard drive. Paraan para mabawasan pisikal na sukat database at transaction log files in SQL server meron – ito compression.
Ano ang compression sa Microsoft SQL Server?
Compression ay ang proseso ng pag-alis ng hindi nagamit na espasyo sa database at mga file ng log ng transaksyon.
Ang pisikal na laki ng mga file ng database ay lumalaki sa paglipas ng panahon, ito ay dahil sa pagdaragdag ng data, ngunit kapag sila ay tinanggal, ang pisikal na laki ng mga file ay nananatiling hindi nagbabago, gayunpaman, ang lohikal na hindi nagamit na espasyo ay lilitaw sa mga file na ito, na maaaring tanggalin.
Ang pinakamalaking epekto ng compression ay nakakamit kapag ang compression operation ay ginanap pagkatapos ng operasyon ng pagtanggal ng mga talahanayan mula sa database o pagtanggal ng data mula sa mga talahanayan.
Dapat mong makilala ang pagitan ng transaction log compression at transaction log truncation. Ang compression ay ang proseso ng pagbabawas ng pisikal na sukat ng isang log sa pamamagitan ng pag-alis ng hindi nagamit na espasyo, habang ang truncation ay ang proseso ng pagpapalaya ng espasyo sa lohikal na log para sa muling gamitin (mga. nalikha ang hindi nagamit na espasyo) log ng transaksyon na may sukat pisikal na file hindi bumababa.
Awtomatikong nangyayari ang pagputol ng log ng transaksyon:
- Sa isang simpleng modelo ng pagbawi - pagkatapos makamit control point, na maaaring lumitaw, halimbawa, pagkatapos paggawa ng BACKUP database, kapag ang isang tahasang CHECKPOINT na pahayag ay naisakatuparan, o kapag ang laki ng log ng lohikal na transaksyon ay 70 porsiyentong puno, sa lahat ng mga kasong ito, awtomatikong paglilinis hindi aktibong bahagi ng log, i.e. pagputol nito;
- Sa modelo ganap na paggaling o sa isang maramihang naka-log na modelo ng pagbawi, pagkatapos malikha ang isang log backup, sa kondisyon na ang isang checkpoint ay naabot na mula noong ang huling log backup ay ginawa.
Kung gumagamit ka ng isang buong modelo ng pagbawi o isang bulk-log na modelo ng pagbawi at ang iyong mga file ng log ng transaksyon ay masyadong malaki, malamang na matagal ka nang hindi nakagawa ng BACKUP ( backup na kopya) log ng transaksyon. SA sa kasong ito Kailangan mo munang gumawa ng BACKUP ng log ng transaksyon, at pagkatapos ay magsagawa ng compression ng log ng transaksyon, na titingnan namin sa ibaba.
Posible rin na ang mga file ng log ng transaksyon ay masyadong malaki ( parehong may simple at ganap na mga modelo ng pagbawi) dahil sa pagkaantala ng pamamaraan ng truncation, i.e. Ang laki ng log ay pangunahing binubuo ng aktibong bahagi ng log, at ang aktibong bahagi ay hindi maaaring putulin, kaya lumalaki ang pisikal na sukat ng log. Ang mga salik na nakakaapekto sa latency ng pamamaraan ng truncation ay kinabibilangan ng: mga aktibong transaksyong matagal nang tumatakbo, ilang naka-mirror na database at mga senaryo sa pagmamapa ng log ng transaksyon, ilang mga sitwasyon ng pagtitiklop ng log ng transaksyon at transaksyon, at hindi posible ang pagputol ng log sa panahon ng operasyon. backup at pagbawi ng data. Sa kasong ito, kailangan mong alisin ang mga sanhi ng pagkaantala, pagkatapos ay putulin ( mga. halimbawa, para sa buong modelo pagbawi BACKUP magazine), at pagkatapos ay i-compress sa isang katanggap-tanggap na laki.
Kadalasan kung sa patuloy na batayan Sa sa ilang mga agwat ay nililikha mga backup log ng transaksyon o database ( na may simpleng modelo ng pagbawi), hindi lumalaki ang mga file ng log ng transaksyon, at hindi nagaganap ang pag-apaw ng log ng transaksyon.
Paano i-compress ang isang database sa MS SQL Server?
Maaari mo ring i-compress ang database at mga file ng log ng transaksyon gamit ang GUI Management Studio at paggamit ng mga pahayag ng Transact-SQL: DBCC SHRINKDATABASE At DBCC SHRINKFILE. Posible ring i-configure ang database para sa awtomatikong compression sa pamamagitan ng pagtatakda ng parameter ng AUTO_SHRINK database sa ON.
Tandaan! Isasaalang-alang ko ang database compression gamit ang halimbawa ng Microsoft SQL Server 2016 Express.
Pag-compact ng Database Gamit ang Management Studio
Ilunsad ang Management Studio at buksan ang object sa Object Browser " Mga database" Pagkatapos ay i-click i-right click mouse sa database na kailangang i-compress, pagkatapos ay piliin ang “ Mga Gawain ->Compress -> Database (o Mga File, kung, halimbawa, kailangan mo lang i-compress ang log ng transaksyon)" Halimbawa, pipiliin ko ang " Database».
Bilang resulta, ang window " Pag-compress ng database", kung saan, sa pamamagitan ng paraan, maaari mong obserbahan ang laki ng database, pati na rin ang magagamit libreng espasyo, na maaaring tanggalin ( mga. pisilin). I-click ang " OK».
Pagkaraan ng ilang oras, depende sa laki ng database, makukumpleto ang compression.
I-compress namin ang database gamit ang SHRINKDATABASE at SHRINKFILE na mga tagubilin
Sa MS SQL Server, mayroong dalawang pahayag na SHRINKDATABASE at SHRINKFILE upang maisagawa ang compression ng database at mga file ng log ng transaksyon.
- DBCC SHRINKDATABASE– ito ay isang utos upang i-compress ang database;
- DBCC SHRINKFILE- gamit ang command na ito maaari mong i-compress ang ilang mga file ng database ( halimbawa, ang log ng transaksyon lamang).
Upang maisagawa ang database compression ( halimbawa TestBase) tulad ng ginawa namin kanina sa Management Studio, sundin ang mga sumusunod na tagubilin.
DBCC SHRINKDATABASE(N"TestBase")
Ang SHRINKDATABASE ay may mga sumusunod na parameter:
- database_name o database_id - ang pangalan o identifier ng database na kailangang i-compress. Kung tinukoy mo ang isang halaga ng 0, ang kasalukuyang database ay gagamitin;
- target_percent – libreng espasyo bilang isang porsyento na dapat manatili sa database pagkatapos ng compression;
- NOTRUNCATE - nag-compress ng data sa mga file sa pamamagitan ng paglipat ng mga inilalaang pahina mula sa dulo ng file patungo sa lugar ng mga hindi inilalaang pahina sa simula ng file. Kung tinukoy ang parameter na ito, hindi mababago ang pisikal na laki ng file;
- TRUNCATEONLY - pinapalaya ang lahat ng libreng espasyo sa dulo ng file operating system, ngunit hindi naglilipat ng mga pahina sa loob ng file. Ang data file ay binabawasan hanggang sa huling inilaan na lawak lamang. Kung ang parameter na ito ay tinukoy, ang target_percent parameter ay hindi naproseso;
- WITH NO_INFOMSGS - pinipigilan ang lahat mga mensahe ng impormasyon na may mga antas ng kalubhaan mula 0 hanggang 10.
Syntax SHRINKDATABASE
DBCC SHRINKDATABASE (database_name | database_id | 0 [ , target_percent ] [ , ( NOTRUNCATE | TRUNCATEONLY ) ]) [ WITH NO_INFOMSGS ]
Upang i-compress lamang ang log ng transaksyon na maaari mong gamitin Mga tagubilin sa SHRINKFILE, Halimbawa.
DBCC SHRINKFILE (N"TestBase_log")
Sa kasong ito, i-compress namin ang log file ( Ang TestBase_log ay ang pangalan ng file ng log ng transaksyon), sa paunang halaga nito, i.e. sa default na halaga. Upang i-compress ang isang file sa isang partikular na laki, tukuyin ang laki sa megabytes bilang pangalawang parameter. Halimbawa, kasama ang mga sumusunod na tagubilin babawasan namin ang laki ng file ng log ng transaksyon sa 5 megabytes.
DBCC SHRINKFILE (N"TestBase_log" , 5)
Kinakailangan din na isaalang-alang na kung tinukoy mo ang isang sukat na mas maliit kaysa sa kinakailangan upang mag-imbak ng data sa file, ang file ay hindi mai-compress sa laki na ito. Halimbawa, sabihin natin kung tinukoy mo ang 5 megabytes, ngunit ang file ay nangangailangan ng 7 megabytes upang mag-imbak ng data, ang file ay mai-compress lamang sa 7 megabytes.
Ang SHRINKFILE ay mayroon ding mga opsyon na NOTRUNCATE at TRUNCATEONLY.
SHRINKFILE Syntax
DBCC SHRINKFILE (( file_name | file_id ) ( [ , EMPTYFILE ] | [ [ , target_size ] [ , ( NOTRUNCATE | TRUNCATEONLY ) ] ] )) [ WITH NO_INFOMSGS ]
- Ang isang database compaction operation ay maaaring maging sanhi ng index fragmentation at pabagalin ang database. Samakatuwid, hindi inirerekomenda na i-compress ang database nang madalas;
- Mas mainam na i-compress ang database bago ang index rebuild operation, i.e. pagkatapos ng compression, simulan ang index rebuild procedure;
- Database parameter AUTO_SHRINK ( awtomatikong pag-compress) ay mas mahusay na huwag itakda ito sa ON, ngunit iwanan ito sa default, i.e. sa OFF, maliban kung siyempre mayroon kang sapat na seryosong mga dahilan para dito;
- Ang pahayag ng SHRINKDATABASE ay hindi nagpapahintulot sa iyo na bawasan ang laki ng database sa isang sukat na mas maliit kaysa sa paunang sukat, i.e. pinakamababa. Gayunpaman, magagawa ito ng pagtuturo ng SHRINKFILE ( ang pangalawang parameter ay nagpapahiwatig na ang laki ay mas mababa sa minimum). Minimum na sukat Ang laki ng database ay ang laki na tinukoy kapag ang database ay nilikha o tahasang itinakda ng isang pagpapatakbo ng pagbabago ng laki ng database gaya ng DBCC SHRINKFILE o ALTER DATABASE. Halimbawa, kung ang isang database ay nilikha na may sukat na 10 megabytes, pagkatapos ay lumaki sa 100 megabytes, maaari itong i-compress gamit ang SHRINKDATABASE lamang sa paunang 10 megabytes, kahit na ang lahat ng data ay tinanggal mula sa database;
- Hindi ma-compress ang mga file ng database at log ng transaksyon habang bina-back up ang mga ito. Sa kabaligtaran, hindi ka makakalikha ng mga backup na kopya ng database at log ng transaksyon habang sila ay pini-compress;
- Ang pagpapatakbo ng DBCC SHRINKDATABASE statement nang hindi tinukoy ang NOTRUNCATE o TRUNCATEONLY na opsyon ay kapareho ng pagpapatakbo ng DBCC SHRINKDATABASE na statement na may NOTRUNCATE na opsyon pagkatapos magpatakbo ng DBCC SHRINKDATABASE na statement na may TRUNCATEONLY na opsyon;
- Habang ang database ay na-compress, ang mga user ay maaaring magtrabaho dito ( mga. hindi na kailangang ilipat ang database sa single-user mode);
- Sa anumang oras, maaari mong matakpan ang proseso ng pagsasagawa ng mga pagpapatakbo ng SHRINKDATABASE at SHRINKFILE, habang naka-save ang lahat ng natapos na gawain;
- Bago simulan ang pamamaraan ng compression, suriin kung mayroong libreng puwang para sa pagtanggal sa mga file ng database, i.e. posible bang i-compress ang mga file sa pamamagitan ng pagpapatakbo ng sumusunod na query ( ipapakita nito sa megabytes kung magkano ang maaari mong bawasan ang mga file ng database).
Iyon lang para sa akin, sana ay naging kapaki-pakinabang sa iyo ang artikulo, good luck!
Pag-compress ng data sa SQL Server 2008.
Kinailangan kong ilipat kamakailan ang aking data warehouse mula sa SQL Server 2005 patungo sa SQL Server 2008. Tulad ng alam mo, isa sa mga inobasyon sa SQL Server 2008 ay ang data compression. Ang tampok na ito ay idinisenyo upang mapabuti ang pagganap ng database sa pamamagitan ng pag-compress ng data at pag-index sa mga talahanayan at mga na-index na view, na nagreresulta sa pinababang I/O. Gayundin, salamat sa compression, ang laki ng database ay maaaring makabuluhang bawasan, na ginagawang mas madali ang pangangasiwa at pamamahala. Ang lahat ng ito ay tila nakakaakit, kaya nagpasya akong samantalahin ang pagkakataong ito.
Ang dahilan na nag-udyok sa akin na tingnan ang pag-andar na ito at sa huli ay isulat ang artikulong ito ay nakatanggap ako ng isang ganap na naiibang resulta kaysa sa inaasahan :)
Nagpasya akong i-compress ang tatlong pinakamalaking talahanayan ng katotohanan, na mga istruktura na may mga column na kasing siksik hangga't maaari, na tumutukoy sa mga sanggunian ng dimensyon at naglalaman ng ilang indicator na pinagsama-sama sa mga ulat. Nasa ibaba ang isang tipikal na istraktura ng isang talahanayan ng katotohanan at isang karaniwang query sa talahanayang ito, sa isang pinasimpleng anyo.
Ngunit sa aking sorpresa, pagkatapos ng compression, hindi lamang ako nakakuha ng anumang pakinabang sa pagganap, ngunit sa kabaligtaran, ang pagpapatupad ng query ay bumagal. Sa ilang mga kaso, ang pagganap ay nanatiling pareho.
Napagpasyahan na siyasatin ang epekto ng compression ng data at magsagawa ng pagsubok upang masagot ang tanong ng pagbaba sa pagganap.
Paghahanda sa pagsusulit.
Kaya, mayroong isang talahanayan, tawagin natin itong ProductMMR, na naglalaman ng ilang mga katotohanan sa ilang mga seksyon.
Narito ang istraktura nito:
Warehouse
produkto
Petsa
Uri ng bodega
Dami
Ang paunang sukat ng talahanayan ay 16 GB, ang mga index ay 18 GB (ginamit ko ang system HPsp_spaceused upang matukoy ang mga laki at index ng data).
Ngayon na ang oras upang magpasya kung anong pamantayan ang gagamitin namin upang suriin ang kahusayan ng compression.
Dahil halos lahat ng developer o administrator ay nagmamalasakit sa pagganap ng kanyang mga server at application, malinaw na ang pangunahing pamantayan para sa pagtatasa ng pagiging epektibo ng compression ay ang oras na ginugol sa pagsasagawa ng mga query, ang bilang ng mga operasyon ng I/O, at ang dami ng CPU. oras na ginugol. Ang nabakante espasyo sa disk bilang resulta ng compression.
Narito ang isang pagsubok na query para piliin ang talahanayang ito:
I-SET ANG ORAS NG ISTATISTIKA -- para sukatin ang oras ng pagpapatupad ng query
I-SET ang STATISTICS IO ON -- para sukatin ang lohikal at pisikal na I/O operations
GO
PUMILI
katotohanan.DateID,
katotohanan.StockID,
SUM(fact.Qty) AS Qty
MULA sa katotohanan.ProductMMR katotohanan
SAAN (fact.DateID BETWEEN @DateIDBegin AT @DateIDEnd)
GROUP BY fact.DateID, fact.StockID
Ang isang yugto ng panahon na 30 araw ay tinukoy (sa talahanayan ng katotohanan ito ay tumutugma sa higit sa 150 milyong mga tala).
Kahulugan ng diskarte sa compression at pagpapatupad nito.
Mga detalye tungkol sapagpapatupad ng compression Mababasa mo ito sa MSDN. Ang pagpapatupad ng compression para samga pahina at para samga linya . Ang epekto ng compression ay nakasalalay sa data sa talahanayan - kung gaano karaming mga dobleng halaga ang mayroon at kung ano ang uri ng data.
Ngayon ay lumipat tayo sa pagpapatupad ng compression, na dati nang tinukoy ang diskarte nito.
Sunil Agarwal sa kanyangblog nagbibigay ng ilang rekomendasyon sa bagay na ito, hayaan mong ibuod ko ang mga ito at ipakita ang mga ito dito:
1. Walang saysay na i-compress ang data o mga index na maliit. Kung ang talahanayan ay 10 pahina ang haba at mai-compress sa isa, hindi ito magiging kapaki-pakinabang sa kasong ito. Mahalagang tandaan na ang naka-compress na data ay dapat na i-decompress sa tuwing maa-access ito. Bago ilapat ang compression, dapat mong tantyahin ang kasalukuyang laki ng talahanayan/index at ang inaasahang laki pagkatapos ng compression.
2. Kung ang mesa ay labis na ginagamit Mga pahayag ng DML at SELECT, ang compression ay maaaring magresulta sa sobrang overhead ng CPU mula sa decompression sa tuwing maa-access ang data. Sa kasong ito, kailangan mong maging maingat lalo na tungkol sa pagiging posible ng pag-compress sa talahanayan/index.
3. Kung mababa ang matitipid mula sa compression, hindi inirerekomenda ang compression. May mga kaso kapag ang laki ng naka-compress na data ay mas malaki kaysa sa hindi naka-compress na data. Iminumungkahi nito na ang talahanayan ang pinakamaraming gumagamit mga uri ng compact datos.
4. Kung mayroon kang karaniwang OLTP application, dapat mong piliin ang ROW compression sa pangkalahatan. Ang ganitong uri ng compression ay mas mura sa mga tuntunin ng data decompression. Gayunpaman, bilang panuntunan, ang PAGE compression ay mas mahusay sa mga tuntunin ng potensyal na libreng espasyo.
Maaari mong suriin ang mga benepisyo ng compression alinman sa isang wizard o gamit ang isang naka-imbak na pamamaraansp_estimate_data_compression_savings.
Sa aking kaso nakuha ko ang mga resultang ito:
Talahanayan 1.
Ang kahusayan sa pag-compress ng data.
Uri ng compression | Sukat bago i-compress | Sukat pagkatapos ng compression | % compression |
HANAY | 33.4 GB | 22.7 GB | 32 % |
PAGE | 33.4 GB | 18.3 GB | 45 % |
Tulad ng makikita mula sa talahanayan, posibleng makuha ang epekto ng data compression. Bagaman sa kasong ito, hindi ito ang pinaka magandang indicator, sa maraming kaso ang data ay na-compress ng 70-80%.
Sa maraming mga kaso ang compression ratio ay magiging mas mataas, at sa ilang mga kaso ay mas mataas, kaysa sa nakuha ko sa pagsusulit na ito. Depende ang lahat sa mga uri ng data at kung gaano karaming duplicate na data ang mayroon ka sa iyong mga talahanayan.
Makikita mo na sa test table, ang row-level compression ay hindi magiging kasing epektibo ng page compression. Tandaan na ang PAGE compression ay isang superset ng ROW compression.
Maaari mong ipatupad ang compression ng isang PAGE/ROW table gamit ang compression wizard, na bumubuo ng code na tulad nito:
ALTER TABLE. REBUILD PARTITION = LAHAT
SA
(DATA_COMPRESSION = ROW
)
Maaari mong ilapat ang uri ng PAGE compression sa pamamagitan ng paggamit ng parameter na DATA_COMPRESSION = PAGE.
Sa pamamagitan ng pagtukoy sa DATA_COMPRESSION = NONE maaari mong kanselahin ang data compression.
Hindi ko ibibigay dito ang syntax para sa pag-compress ng mga index at mga partisyon ay madaling mahanap ang mga ito sa BOL.
Tandaan na bago mo paganahin o huwag paganahin ang row o page compression, kailangan mo ng parehong dami ng puwang sa disk tulad ng gagawin mo upang lumikha o muling bumuo ng isang index.
Mga resulta ng pagsubok.
Kaya, bago at pagkatapos ng compression gamit ang uri ng PAGE, isang pagsubok na kahilingan ay naisakatuparan.
Narito ang mga resulta nito, sa isang "warm up" cache:
Talahanayan 2.
Mga resulta ng pagsusulit No. 1*.
Uri ng compression | Oras ng pagpapatupad ng query (ms) | Mga operasyong lohikal na pagbasa** | Oras na Ginugol ng CPU (ms) |
Walang compression | 26 147 | 1 419 113 | 308 736 |
PAGE compression | 41 104 | 709 360 | 486 453 |
*Ang kahilingan ay isinagawa sa isang server na may 12 core at 32 GB ng RAM, 10 RAID disk subsystem.
** Ang mga lohikal na pagpapatakbo ng pagbasa lamang ang ipinapakita, dahil walang pisikal na pagbabasa - ang data ay nasa cache.
Kapag nakikita ang mga resultang ito, maaari kang mabigla - pagkatapos ng lahat, ang mga operasyong lohikal na pagbasa sa naka-compress na data ay ginawa nang dalawang beses na mas kaunti, ngunit ang oras ng pagpapatupad ng query ay 36% na mas mahaba. At ang buong punto ay tila bagaman may mas kaunting mga operasyon sa pagbabasa at lahat ay binabasa mula sa memorya, ang overhead para sa pag-unpack ng data ay mataas. Pagkatapos ng lahat, hindi ang buong pahina ang na-unpack, ngunit ang bawat tala ay hiwalay.
Maaaring ipagpalagay na kung ang data ay hindi naka-cache, kung gayon sa kasong ito ang isang pakinabang sa pagganap ay maaaring makamit sa pamamagitan ng pagbabawas ng bilang ng mga mamahaling pisikal na operasyon sa pagbasa sa kaso ng naka-compress na data.
Samakatuwid, napagpasyahan na magsagawa ng isa pang pag-ikot ng mga pagsubok, ngunit sa pagkakataong ito sa isang malamig na cache.
Ang parehong kahilingan sa pagsubok ay naisakatuparan, ngunit ang cache ng pamamaraan at buffer ay unang na-clear gamit ang mga utosDBCC FREEPROCCACHE At DBCC DROPCLEANBUFFERS .
Narito ang mga resulta ng isang kahilingan sa pagsubok bago at pagkatapos ng compression, sa isang "malamig" na cache:
1 419 105
1 420 868
235 266
PAGE data compression
48 887
707 495
710 105
416 689
Kinukumpirma ng mga resultang ito ang naunang sinabing palagay. Tulad ng nakikita mo, ang oras ng pagpapatupad ay naiiba ng 12%, sa halip na 36% mula sa unang pagsubok.
Ang mga istatistika sa mga pagpapatakbo ng lohikal na pagbasa ay pareho, ngunit sa pagsubok na ito mayroong isang pisikal na pagbabasa, na makabuluhang nakakaapekto sa pagganap ng query (ihambing ang oras ng pagpapatupad sa unang pagsubok). At, tila, ang data compression ay magkakaroon ng positibong epekto sa mga tuntunin ng pagganap kapag ang mga query ay naisakatuparan laban sa mga bihirang ginagamit, malalaking data array, na ang compression ay magbibigay-daan samakatipid sa mga operasyon pisikal na pagbasa , kumpara sa kung aling pag-unpack ng data mula sa buffer pool ay isang mas murang operasyon. Isang magandang halimbawa Ito ay maaaring compression ng mga partition na may data para sa pinakamaagang panahon sa storage o compression ng iba pang malalaki, bihirang ginagamit na mga talahanayan. Hayaan akong ipaalala sa iyo na maaari mong i-compress ang data pareho sa antas ng talahanayan at sa antas ng mga partisyon at index. Bukod dito, maaari mong pagsamahin ang mga uri ng compression.
Nagawa kong tiyakin na sa talahanayan ng pagsubok, ang pagsa-sample ng naka-compress na data para sa mas mahabang panahon ay nagsimulang isagawa sa humigit-kumulang sa parehong antas ng sampling ng hindi naka-compress na data para sa parehong panahon, i.e. Kung mas malaki ang array ng data na na-access ng kahilingan, mas malaki ang positibong epekto ng compression, dahil kinailangan munang makipag-ugnayan ng server para sa malaking halaga ng data sistema ng disk at hindi ang buffer pool.
Pero ang pinaka pangunahing dahilan Ang dahilan kung bakit bumaba ang pagganap ng query sa aking kaso ay ang medyo mababang compression ratio, mas mababa sa 50%. Nagpatakbo ako ng ilan pang pagsubok at nalaman na ang mga talahanayang iyon na na-compress ng 60-75% ay nagpabuti ng pagganap ng query kumpara sa mga hindi naka-compress na talahanayan.
Malinaw, mas mataas ang porsyento ng compression, mas malaki ang epekto sa mga nadagdag sa pagganap.
Sa anumang kaso, bago simulan ang operasyong ito, kinakailangan na magsagawa ng pagsubok at suriin ang epekto ng compression ng data.
Sergey Kharybin, MCTS SQL Server.
I) Mga problemang sinusubukan naming lutasin sa pagbagsak ng database
1) Pagtaas ng laki ng database
2) Mahina ang pagganap pagpapatupad ng mga kahilingan
3) Malaking volume"hindi kinakailangang data" na nakakasagabal sa karanasan ng user
a) Paghahati ng database sa mga pangkat ng file
b) Paglalagay ng database o bahagi nito sa network drive
c) Compression ng mga talahanayan ng database
d) Paghahati ng mga talahanayan ng database
2) Ang problema ng mahinang pagganap ng query
3) Ang problema ng malaking halaga ng "hindi kinakailangang data" na nakakasagabal sa karanasan ng user
SA modernong kondisyon Kakaiba minsan na marinig ang "kailangan nating i-shut down ang 1C database - ang laki nito ay lumampas sa 50 GB." Kung gagawin ito ng mga administrator ng SAP R3 o Oracle e Business Suite o kahit na MS Dynamics Ax system, malamang na matanggal sila sa trabaho. Gayunpaman, para sa 1C ito ay "karaniwang kasanayan".
Para sa mga bersyon ng file Ang kuwento ay bumalik sa bersyon 1C 7.7 na may 2GB na limitasyon sa laki ng database. Ngayon ang 2GB na limitasyon ay nasa sukat lamang ng talahanayan; ang laki ng file ay maaari nang maging napakaliit. Totoo, kung ang iyong database ay lumaki sa ganoong laki, kung gayon ang data ay malamang na aktibong ipinasok doon - marahil kailangan mong mag-isip tungkol sa isang client-server?
Sa totoo lang, ang layunin ng artikulong ito ay "iwasan" ang mga user mula sa pagsasagawa ng database rollup bersyon ng client-server 1C, sa pamamagitan ng paggamit ng medyo mas "advanced" na mga teknolohiya.
I) Mga problema na sinusubukan naming lutasin sa pamamagitan ng pagbagsak ng database
1) Pagtaas ng laki ng database
Sa totoo lang pangunahing tanong: bakit bawasan ang laki ng database?
Mag-apply tayo ng kaunting matematika:
server hard drive para sa 500 GB nagkakahalaga ito ng halos 10 libong rubles. Upang pagsamahin sa RAID 1 para sa pagiging maaasahan ito ay magiging 20 libong rubles.
Naturally, maaaring may mga problema sa kakulangan ng espasyo para sa bago mga hard drive sa server mismo...
Ngunit ang pagbili ng isang panlabas na hanay ng disk ay hindi magiging mura. Ano ang gagawin?
Oo, ang lahat ay simple - ilagay ang mga file ng database sa isang network drive, ngunit paano? Well, higit pa sa artikulong ito mamaya.
Ang pagtaas ng puwang sa disk na magagamit para sa database ay nagkakahalaga sa amin ng 20 libong rubles. + 10 minuto ng trabahong espesyalista. Ilang oras ng trabahong dalubhasa ang kakailanganin para i-roll up ang database? Gaano karaming downtime ang maaaring magkaroon? Ayon sa pinakakonserbatibong pagtatantya, para sa convolution ng isang UPP na may dami ng 60 gigabytes, na may average na bilang ng mga error, batch accounting na may pag-verify ng mga resulta ng convolution, ang pagwawasto ng parehong batch accounting ay nagkakahalaga ng 30-40 thousand .
Ang pagpoproseso ng unibersal ay hindi malamang na tiklupin ang lahat nang sabay-sabay, lalo na kung ang iyong base ay halos "hindi hihinto." Dapat itama ang party accounting sa anumang kaso. Sa pangkalahatan, maraming trabaho doon. At ang pinakamahalagang bagay ay ang huling pagsusuri ay dapat na masinsinan, at magkakaroon pa rin ng mga pagkakamali...
Bilang karagdagan, kung ang database ay hindi na 60 GB ang laki, ngunit, halimbawa, 120 GB... ang pinakamaliit na error sa 1C code sa panahon ng convolution at iyon na... ang pamamaraan ay nagtatapos nang hindi matagumpay. At tiyak na magkakaroon ng mga pagkakamali. Tulad ng "hindi sapat na memorya" kapag nagtatrabaho sa mga teknikal na detalye, at mga error tulad ng
Ang panghuling bilang ay 30-40 tonelada kumpara sa 20-25 sa kaso mahirap mag shopping disk, at makakuha ng 500 GB ng karagdagang espasyo
Kaya naman lumalabas ang mga produktong tulad ng [kailangan mong magparehistro para matingnan ang link].
Malamang na ang mga ito ay mahusay na mga produkto, at tinutupad nila ang kanilang mga layunin. Nagbabago lang ang istraktura ng mga talahanayan mula sa bersyon patungo sa bersyon ng platform. Sinabi sa amin ng 1C ang tungkol dito nang higit sa isang beses. May lumabas na data separator sa ika-14 na release at iyon lang... malamang na hindi na magiging angkop ang pagproseso na ito para sa ika-14 na release. At kahit papaano ay nakakatakot, hindi banggitin ang isang paglabag sa kasunduan sa lisensya.
At kahit na pagkatapos nito, magkakaroon ng mga user na "biglang biglang kailangan" na nagbubura ng data, na "gusto lang iwasto" ang ilang numero na "hindi nakakaapekto sa mga pagkakasunud-sunod" sa isang dokumento ng saradong panahon. At mas masahol pa kung lumalabas na ang isang tao ay patuloy na tumitingin sa mga dokumentong ito para sa ilang layunin na alam lamang niya. Siyempre, ang lahat ng ito ay mga pagkakamali lamang sa pamamaraan ng pagpapatakbo, ngunit gayunpaman, magkakaroon ng hindi kasiyahan ng gumagamit.
2) Hindi magandang pagganap ng query
Well, sino ang nagsabi sa iyo na "mas maliit ang mas mabilis"? Para sa isang wastong nabuong IS, ang pahayag na ito ay hindi totoo.
Ang figure sa ibaba ay maikli at "sa wika ng ibon" ay nagpapakita pinakasimpleng halimbawa pagpili sa pamamagitan ng B-Tree type index ng isang entry sa address table:
Hindi ko nais na bungkalin ang paksa ng mga index, lalo na dahil ang lahat ay medyo mas kumplikado doon. Ang pinakamahalagang bagay ay ang paghahanap ay hindi nagaganap nang "pahalang" sa kabuuan ng talahanayan, ngunit "patayo" sa "mga antas" ng index.
pagkakatulad - kuwaderno: Ang bawat pahina ay nagsisimula sa sarili nitong titik, tanging sa bawat pahina ay mayroon ding parehong notebook kung saan maaari mong piliin ang pangalawang titik sa salita, at iba pa hanggang sa makatagpo ka ng isang pahina kung saan magkakaroon ng isa o higit pang mga entry. Komportable? Siyempre, maginhawa kung mayroon kang higit sa ilang daang mga contact. Paano kung sampu ka lang nila? Hindi ba mas madaling isulat ang mga ito sa isang piraso ng papel na maaari mong tingnan sa pamamagitan ng iyong mga mata? Ang parehong naaangkop sa mga index. Ito ay epektibo kung mayroong ilang libong mga tala sa talahanayan, ngunit kung mayroon lamang, ito ay hindi masyadong epektibo. Sa kabutihang palad, natutunan ng mga DBMS na independiyenteng pumili ng isang "plano ng query" at magpasya kung gagamitin ito o hindi ang index na iyon. Ngunit sa kaso ng "pagdadala sa" lahat ng mga hilera ng isang talahanayan na walang index, ang DBMS ay madalas na ni-lock ang buong talahanayan na ito, at napapansin mo ang "mga kandado na nagmumula sa isang hindi kilalang pinagmulan" pagkatapos ng pagbagsak ng seguridad ng impormasyon.
Karaniwan naming binabago ang mga talahanayan ng balanse. Sa talahanayan ng mga balanse, ang unang field sa lahat ng mga index ay ang panahon. Iyon ay, para sa anumang mga kahilingan, talaga itaas na antas index, ang mga kinakalkula na balanse para sa kinakailangang panahon ay mapipili na. Samakatuwid, ang pagbagsak ng database ay magkakaroon ng hindi bababa sa epekto sa mga kahilingan para sa mga balanse, inuulit ko, kapag maayos na organisasyon mga sistema.
Magpadala muna ng newsletter sa iyong mga user tungkol dito. At makakatanggap ka ng isang bungkos ng mga mensahe na "hindi kailangan ang data." Gayunpaman, maraming tao ang hindi gustong "makita ang mga makasaysayang dokumento" at "data ng archival"; Ngunit nalulutas ba ng pagkakasundo ang mga problemang ito? Tinatanggal ba nito ang mga hindi kinakailangang item mula sa direktoryo ng nomenclature? Mga counterparty na hindi ka na makakatrabaho? At tulad ng ipinapakita sa pagsasanay, dito namamalagi ang karamihan sa mga problema.
II) "Teknolohiya" na mga solusyon sa mga problema
1) Ang problema ng pagtaas ng laki ng database
a) hatiin ang database sa mga pangkat ng file
Buksan ang Management Studio sa listahan ng mga database, piliin ang kailangan mo, buksan ang mga katangian nito.
- Pumunta sa tab na "Mga pangkat ng file" tulad ng ipinapakita sa figure, at magdagdag ng isa pang pangkat ng file (sa halimbawa ito ay tinatawag na SECONDARY
Pumunta sa tab na "Mga File" at magdagdag bagong file, kung saan pipiliin namin ang nilikhang pangkat ng file. Ang file na ito PWEDENG MATATAGPUAN SA IBANG DISK
Ngayon, gamit ang pagpoproseso halimbawa: http://infostart.ru/public/78049/ tinutukoy namin kung aling mga talahanayan ang maaari naming ligtas na "mag-donate" sa isang mas mabagal (o kabaligtaran, lahat sa mabagal, ang natitira sa isang mas mabilis) na daluyan. Nalalapat dito ang panuntunang 80/20. 80% ng mga operasyon ay isinasagawa gamit ang 20% ng data, kaya isipin kung aling mga plato ang kailangan mo nang mabilis at kung alin ang hindi gaanong. "Imbakan" karagdagang impormasyon", mga dokumento para sa pagpasok ng mga paunang balanse, mga dokumento na hindi mo na ginagamit, agad na tukuyin ang mga ito bilang mga maaaring ilipat sa isang "mabagal" na pangkat ng file.
Piliin ang talahanayan na kailangang ilipat sa isa pang pangkat ng file - piliin ang menu para sa pagbabago ng talahanayan (proyekto) at baguhin ang pangkat ng file sa mga katangian:
ang mga index ng talahanayan ay inililipat din sa pangkat ng file na ito.
Isang medyo maginhawang mekanismo para sa pamamahagi ng mga talahanayan sa kabuuan hanay ng disk iba't ibang bilis. Kasunduan sa lisensya hindi ito sumasalungat, dahil sa solusyon hindi kami gumagamit ng access sa data at base ng impormasyon sa pamamagitan ng paraan maliban sa 1C platform. Inaayos lang namin ang pag-iimbak ng data na ito sa isang maginhawang paraan.
b) I-save ang database sa isang network drive
DBCC TRACEON (1807)
Nagsusulat kami utos na ito sa Management Studio, gumaganap kami at matagumpay na makakagawa ng mga database sa network. Siyempre, ang pagkakataong ito SQL Server dapat ilunsad sa ngalan ng domain account, at ang entry na ito ay dapat may mga karapatan sa ninanais folder ng network.
Ngunit mangyaring maging maingat kapag ginagamit ang utos na ito kung ang iyong network ay bumaba habang nagtatrabaho sa database, ang buong database ay hindi maa-access habang wala ito. Hindi para sa wala na isinara ng Microsoft ang pagkakataong ito para sa malawakang paggamit. Sa pangkalahatan, ang posibilidad na ito ay inilaan upang lumikha ng mga database sa Mga imbakan ng NAS, na lubos kong inirerekomenda. Angkop bilang matatag at maaasahan file server pagkakaroon direktang koneksyon sa server na nagpapatakbo ng MS SQL DBMS.
Maaari kang magbasa nang higit pa tungkol sa iba pang mga bakas na flag sa artikulo [kailangan mong magparehistro upang tingnan ang link]
Yung. Ang bahagi ng pangkat ng file ay maaaring maimbak sa network, at doon ang puwang ng disk ay maaaring mapalawak nang walang mga problema.
c) Pag-compress ng mga talahanayan ng database
EXEC sp_MSforeachtable "ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)" GO
Pagkatapos isagawa ang code na ito, ang lahat ng mga talahanayan sa database ay mai-compress. Malinaw, maaari mo ring i-compress ang mga talahanayan nang paisa-isa... ito ay uri ng iyong pinili. Ano ang ginagawa ng compression?
- Nagse-save ng espasyo sa disk
- Nabawasan ang pagkarga sa disk subsystem
Ano ang kinakain? - Oras ng CPU.
Kaya kung ang iyong processor ay na-load sa 70% o mas mataas sa lahat ng oras, hindi ka maaaring gumamit ng compression. Kung ang processor load ay 20-30%, at ang disk queue ay lumalaki sa 3-4... kung gayon ang table compression ay ang "lunas" lamang para sa iyo. Matuto nang higit pa tungkol sa pag-compress ng mga talahanayan ng database - [kailangan mong magparehistro para matingnan ang link na ito]
Mahalagang Paalala- Ang function ng table compression ay magagamit lamang para sa mga may-ari ng Enterprise na bersyon ng SQL Server
d) Paghahati ng mga talahanayan ng database
Siyempre, magandang hatiin ang mga talahanayan sa iba't ibang mga grupo ng file... ngunit sasabihin mo na mayroong isang pares ng mga talahanayan dito... na nangyayari mula noong 2005... at kumukuha na ng isang dosenang gigabytes.. . Nais kong mailagay ko ang lahat ng data sa kanila at maglagay ng hiwalay na disk, ngunit iwanan ang mga kasalukuyang.
Hindi ka maniniwala, ngunit posible rin ito, kahit na hindi masyadong simple:
Lumikha ng isang function para sa paghahati ayon sa petsa:
lumikha ng partition function YearSection(datetime)
bilang tamang hanay para sa mga halaga ("20110101");
Lahat bago ang 2011 ay mahuhulog sa isang seksyon, lahat pagkatapos ay mapupunta sa isa pa.
- Gumawa ng partitioning scheme
lumikha ng partition scheme YearScheme
bilang partition YearSection to (SECONDARY, PRIMARY);
Sa pamamagitan nito, sinasabi namin na ang lahat ng data hanggang sa taong 11 ay mapupunta sa "Secondary" file group at pagkatapos nito - sa "Pangunahing"
Ngayon ang natitira na lang ay muling itayo ang talahanayan sa pamamagitan ng paghahati nito sa mga seksyon. Ang pinakamadaling paraan upang gawin ito ay ang paggamit studio ng pamamahala, dahil hindi simple ang proseso. Kailangan mong muling itayo ang clustered index sa talahanayan (na kung saan ay mahalagang talahanayan mismo), pagpili ng nilikha na scheme ng partition para sa index:
Sa figure na nakikita mo na ang pagpipilian ay hindi magagamit - lahat ay tama, ang paghahati ng talahanayan ay posible lamang sa Enterprise na bersyon ng MS SQL Server. Ang cluster index ay madaling makilala - isang larawan na may panaklong. Ito ay nilikha para sa RN at lahat ng 1C na bagay. Para sa RN, palaging mayroong cluster index ayon sa tuldok. Para sa mga dokumento at direktoryo, mas mabuti, siyempre, na gumawa ng isa pa na kasama ang mga detalye kung saan magaganap ang sectioning... ngunit ito ay magiging isang paglabag sa kasunduan sa lisensya.
2) Mababang pagganap ng query.
Ang lahat ng mga pagkilos na inilarawan sa itaas ay hindi dapat makaapekto sa bilis ng pagpapatupad ng mga pangunahing query. Bukod dito, ang paggamit ng mga pangkat ng file at mga seksyon ng talahanayan ay magbibigay-daan sa iyo na ilagay ang pinakamadalas na ginagamit na data sa mabilis na mga array ng disk, magbibigay-daan sa iyong baguhin ang pagsasaayos ng mga array ng disk, at gumamit ng maliliit na laki ng i/o accelerators. Papataasin lamang nito ang bilis ng pagsasagawa ng query. At ang table compression ay magbibigay-daan sa iyo upang higit pang mapawi ang disk subsystem kung ito ay isang bottleneck. Sa pangkalahatan, kung pag-uusapan natin ang bilis ng pagpapatupad ng query, pagkatapos ay ang pagsusuri sa kanilang mga plano sa pagpapatupad at pag-optimize ng mga query para sa wastong paggamit ng mga index ay magbibigay ng mas makabuluhang pagtaas ng pagganap kaysa sa lahat ng "trick" sa antas ng MS SQL.
3) Isang malaking halaga ng "hindi kinakailangang data" na nakakasagabal sa karanasan ng user
Ngunit upang gawin ito, hindi mo kailangang i-collapse ang database, ngunit gawin ang sumusunod:
a) Ipaliwanag sa lahat kung paano gamitin ang mga seleksyon, kung paano sila na-save, kung paano gamitin ang mga pagitan ng log, kung paano sila na-save
b) Markahan ang hindi kinakailangang data para sa pagtanggal kung wala itong anumang semantikong kahulugan (mga counterparty at item na hindi mo na ginagamit) - magdadala ito ng mga user mas maraming benepisyo kaysa sa isang bundle. Kung available ang mga mapagkukunan, mag-set up ng awtomatikong pagmamarka para sa pagtanggal ng mga hindi nagamit na bagay at gumawa ng default na pagpili sa code ng programa upang hindi maipakita bilang default kailangan ng mga gumagamit mga bagay - minarkahan para sa pagtanggal
c) Mag-set up ng iba pang kapaki-pakinabang na "mga default na pagpipilian" - halimbawa, upang makita lamang ng bawat tagapamahala ang kanyang sariling mga dokumento bilang default. At kung gusto niyang tingnan ang mga dokumento ng kanyang "kasama", kailangan niyang i-off ang pagpili.
Para sa lahat ng mga detalye na lumahok sa pagpili, huwag kalimutang lagyan ng tsek ang kahon na "Index na may karagdagang pag-order" - kung gayon ang mga "kaginhawaan" ay hindi makakaapekto sa pagganap ng system.
Mga Tag: 1C, 1C Optimization, sql, 1C Administration, Training, Programming, Technologies
[kailangan mong magparehistro para matingnan ang link]
Sa modernong mga kondisyon, minsan ay napakakakaibang marinig na "kailangan nating i-collapse ang 1C database - ang dami nito ay lumampas sa 50 GB." Kung gagawin ito ng mga administrator ng SAP R3 o Oracle e Business Suite o kahit na MS Dynamics Ax system, malamang na matanggal sila sa trabaho. Gayunpaman, para sa 1C ito ay "karaniwang kasanayan".
Para sa mga bersyon ng file, babalik ang kuwento sa bersyon 1C 7.7 na may 2GB na limitasyon sa laki ng database. Ngayon ang 2GB na limitasyon ay nasa sukat lamang ng talahanayan; ang laki ng file ay maaari nang maging napakaliit. Totoo, kung ang iyong database ay lumaki sa ganoong laki, kung gayon ang data ay malamang na aktibong ipinasok doon - marahil kailangan mong mag-isip tungkol sa isang client-server?
Sa totoo lang, ang layunin ng artikulong ito ay "iwasan" ang mga user ng client-server na bersyon ng 1C mula sa pagsasagawa ng database rollup, sa pamamagitan ng paggamit ng medyo mas "advanced" na mga teknolohiya.
Ang huling bilang ay 30-40 tonelada, pinakamababa kumpara sa 20-25 sa kaso ng pagbili hard drive, at makatanggap ng 500 GB ng karagdagang espasyo
Iyon ang dahilan kung bakit tulad ng mga produkto
Malamang na ang mga ito ay mahusay na mga produkto, at tinutupad nila ang kanilang mga layunin. Nagbabago lang ang istraktura ng mga talahanayan mula sa bersyon patungo sa bersyon ng platform. Sinabi sa amin ng 1C ang tungkol dito nang higit sa isang beses. May lumabas na data separator sa ika-14 na release at iyon lang... malamang na hindi na magiging angkop ang pagproseso na ito para sa ika-14 na release. At kahit papaano ay nakakatakot, hindi banggitin ang isang paglabag sa kasunduan sa lisensya.
At kahit na pagkatapos nito, magkakaroon ng mga user na "biglang biglang kailangan" na nagbubura ng data, na "gusto lang iwasto" ang ilang numero na "hindi nakakaapekto sa mga pagkakasunud-sunod" sa isang dokumento ng saradong panahon. At mas masahol pa kung lumalabas na ang isang tao ay patuloy na tumitingin sa mga dokumentong ito para sa ilang layunin na alam lamang niya. Siyempre, ang lahat ng ito ay mga pagkakamali lamang sa pamamaraan ng pagpapatakbo, ngunit gayunpaman, magkakaroon ng hindi kasiyahan ng gumagamit.
-
Buksan ang Management Studio sa listahan ng mga database, piliin ang kailangan mo, buksan ang mga katangian nito.
- Pumunta sa tab na "Mga pangkat ng file" tulad ng ipinapakita sa figure, at magdagdag ng isa pang pangkat ng file (sa halimbawa ito ay tinatawag na SECONDARY)
- Pumunta sa tab na "Mga File" at magdagdag ng bagong file, kung saan pipiliin namin ang nilikhang pangkat ng file. Ang file na ito PWEDENG MATATAGPUAN SA IBANG DISK
-
Ngayon, gamit ang pagpoproseso halimbawa: tinutukoy namin kung aling mga talahanayan ang maaari naming ligtas na "mag-donate" sa isang mas mabagal (o kabaligtaran, lahat sa mas mabagal, ang natitira sa isang mas mabilis) na medium. Nalalapat dito ang panuntunang 80/20. 80% ng mga operasyon ay isinasagawa gamit ang 20% ng data, kaya isipin kung aling mga plato ang kailangan mo nang mabilis at kung alin ang hindi gaanong. "Imbakan ng karagdagang impormasyon", mga dokumento para sa pagpasok ng mga paunang balanse, mga dokumento na hindi mo na ginagamit, agad na kilalanin ang mga ito bilang mga maaaring ilipat sa isang "mabagal" na grupo ng file.
Piliin ang talahanayan na kailangang ilipat sa isa pang pangkat ng file - piliin ang menu para sa pagbabago ng talahanayan (proyekto) at baguhin ang pangkat ng file sa mga katangian:
ang mga index ng talahanayan ay inililipat din sa pangkat ng file na ito.
Isang medyo maginhawang mekanismo para sa pamamahagi ng mga talahanayan sa mga array ng disk na may iba't ibang bilis. Hindi ito sumasalungat sa kasunduan sa lisensya, dahil Sa solusyon, hindi kami gumagamit ng access sa data at base ng impormasyon sa pamamagitan ng paraan maliban sa 1C platform. Inaayos lang namin ang pag-iimbak ng data na ito sa isang maginhawang paraan.
DBCC TRACEON (1807)
Isinulat namin ang command na ito sa Management Studio, isagawa ito at maaaring matagumpay na lumikha ng mga database sa network. Siyempre, ang halimbawa ng SQL Server ay dapat na ilunsad sa ilalim ng isang domain account, at ang account na ito ay dapat na may mga karapatan sa nais na folder ng network.
Ngunit mangyaring maging maingat kapag ginagamit ang command na ito kung ang iyong network ay bumaba habang nagtatrabaho sa database, ang buong database ay hindi maa-access sa panahon na wala ito. Hindi para sa wala na isinara ng Microsoft ang pagkakataong ito para sa malawakang paggamit. Sa pangkalahatan, ang tampok na ito ay inilaan para sa paglikha ng mga database sa mga imbakan ng NAS, na lubos kong inirerekomenda. Ang isang matatag at maaasahang file server na may direktang koneksyon sa server na nagpapatakbo ng MS SQL DBMS ay angkop din.
Maaari kang magbasa nang higit pa tungkol sa iba pang pagsubaybay sa mga flag sa artikulo http://msdn.microsoft.com/ru-ru/library/ms188396.aspx
Yung. Ang bahagi ng pangkat ng file ay maaaring maimbak sa network, at doon ang puwang ng disk ay maaaring mapalawak nang walang mga problema.
Siyempre, magandang hatiin ang mga talahanayan sa iba't ibang mga grupo ng file... ngunit sasabihin mo na mayroong isang pares ng mga talahanayan dito... na nangyayari mula noong 2005... at kumukuha na ng isang dosenang gigabytes.. . Nais kong mailagay ko ang lahat ng data sa kanila at maglagay ng hiwalay na disk, ngunit iwanan ang mga kasalukuyang.
Hindi ka maniniwala, ngunit posible rin ito, kahit na hindi masyadong simple:
Lumikha ng isang function para sa paghahati ayon sa petsa:
lumikha ng partition function YearSection(datetime)
bilang tamang hanay para sa mga halaga ("20110101");
Lahat bago ang 2011 ay mahuhulog sa isang seksyon, lahat pagkatapos ay mapupunta sa isa pa.
Paglikha ng isang partitioning scheme
lumikha ng partition scheme YearScheme
bilang partition YearSection to (SECONDARY, PRIMARY);
Sa pamamagitan nito, sinasabi namin na ang lahat ng data hanggang sa taong 11 ay mapupunta sa "Secondary" file group at pagkatapos nito - sa "Pangunahing"
Ngayon ang natitira na lang ay muling itayo ang talahanayan sa pamamagitan ng paghahati nito sa mga seksyon. Ang pinakamadaling paraan upang gawin ito ay ang paggamit ng management studio, dahil ang proseso ay hindi simple. Kailangan mong muling itayo ang clustered index sa talahanayan (na kung saan ay mahalagang talahanayan mismo), pagpili ng nilikha na scheme ng partition para sa index:
Sa larawan nakikita mo na ang pagpipilian ay hindi magagamit - lahat ay tama, Posible lamang ang paghahati ng talahanayan sa bersyon ng Enterprise ng MS SQL Server. Ang cluster index ay madaling makilala - isang larawan na may panaklong. Ito ay nilikha para sa RN at lahat ng 1C na bagay. Para sa RN, palaging mayroong cluster index ayon sa tuldok. Para sa mga dokumento at direktoryo, mas mabuti, siyempre, na gumawa ng isa pa na kasama ang mga detalye kung saan magaganap ang sectioning... ngunit ito ay magiging isang paglabag sa kasunduan sa lisensya.
Ngunit upang gawin ito, hindi mo kailangang i-collapse ang database, ngunit gawin ang sumusunod:
a) Ipaliwanag sa lahat kung paano gamitin ang mga seleksyon, kung paano sila na-save, kung paano gamitin ang mga pagitan ng log, kung paano sila na-save
b) Markahan ang hindi kinakailangang data para sa pagtanggal kung wala itong anumang kahulugan (mga counterparty at item na hindi mo na ginagamit) - ito ay magdadala ng higit na benepisyo sa mga user kaysa sa pagbabawas. Kung magagamit ang mga mapagkukunan, i-set up ang awtomatikong pagmamarka para sa pagtanggal ng mga hindi nagamit na bagay at gumawa ng default na pagpili sa program code upang ang mga bagay na hindi kailangan ng mga user - ang mga minarkahan para sa pagtanggal - ay hindi ipinapakita bilang default
c) Mag-set up ng iba pang kapaki-pakinabang na "mga default na pagpipilian" - halimbawa, upang makita lamang ng bawat tagapamahala ang kanyang sariling mga dokumento bilang default. At kung gusto niyang tingnan ang mga dokumento ng kanyang "kasama", kailangan niyang i-off ang pagpili.
Para sa lahat ng mga detalye na lumahok sa pagpili, huwag kalimutang lagyan ng tsek ang kahon na "Index na may karagdagang pag-order" - kung gayon ang mga "kaginhawaan" ay hindi makakaapekto sa pagganap ng system.
