Qanday Yaxshi

Qanday	Yaxshi	yomon
Jami
Dt-ga yuklash	Juda ixcham format.	Bu shakllanish uchun juda ko'p vaqt talab etiladi, eksklyuziv kirish talab etiladi, ba'zi ahamiyatsiz ma'lumotlarni saqlamaydi (masalan, oldingi versiyalardagi foydalanuvchi sozlamalari), joylashtirish uchun ko'p vaqt talab etiladi.	Bu zaxira qilish usuli emas, balki ma'lumotlarni bir muhitdan ikkinchisiga uzatish usuli. Tor kanallar uchun ideal.
MDF va ldf fayllarini nusxalash	Ajam administratorlar uchun juda aniq usul.	Ma'lumotlar bazasi fayllarini qulflashdan ozod qilishni talab qiladi, agar ma'lumotlar bazasi oflayn bo'lsa (kontekst menyusining oflayn buyrug'ini oling), uzilib qolsa (ajratib oling) yoki server to'xtatilsa. Shubhasiz, foydalanuvchilar hozircha ishlay olmaydilar.	Ushbu usuldan foydalanish, agar faqat baxtsiz hodisa ro'y bergan bo'lsa, qayta tiklanayotganda, hech bo'lmaganda tiklanish boshlangan variantga qaytishingiz mumkin.
OS yoki gipervizorni zaxiralash	Atrof-muhitni rivojlantirish va sinovdan o'tkazish uchun qulay usul.	Ma'lumotlarning yaxlitligi bilan har doim ham do'stona emas. Resurslarni talab qiladigan usul.	Rivojlanish uchun cheklangan darajada foydalanish mumkin. Oziq-ovqat muhitida uning amaliy ma'nosi yo'q.
MS SQL yordamida zaxira nusxasi	Bo'sh vaqt talab qilinmaydi. Agar siz bu haqda oldindan tashvishlansangiz, o'zboshimchalik bilan ajralmas holatni tiklashga imkon beradi. Zo'r avtomatlashtirilgan. Vaqt va boshqa manbalar bo'yicha iqtisodiy.	Juda ixcham format emas. Ushbu usuldan kerakli darajada foydalanishni hamma ham bilavermaydi.	Oziq-ovqat mahsulotlari muhiti uchun - bu asosiy vosita.

O'rnatilgan MS SQL vositalari yordamida zaxira nusxasini ishlatishda asosiy qiyinchiliklar ishlash tamoyillarini elementar noto'g'ri tushunishdan kelib chiqadi. Bu qisman katta dangasalik bilan, qisman "tayyor retseptlar" darajasida oddiy va tushunarli tushuntirishning yo'qligi bilan izohlanadi (hmm, aytaylik, men uchratmadim) va forumlarda mifologik maslahat "underdog" bilan og'irlashadi. Dangasalik bilan nima qilishni bilmayman, lekin zaxira nusxalarini tushuntirishga harakat qilaman.

BIZ NIMANI TEJAYAPMIZ VA NIMA UCHUN?

Uzoq vaqt oldin uzoq galaktikada 1C: Enterprise 7.7 kabi muhandislik va buxgalteriya hisobi mahsuloti mavjud edi. Ehtimol, 1C: Enterprise-ning birinchi versiyalari mashhur dbf fayl formatidan foydalanish uchun ishlab chiqilganligi sababli, uning SQL versiyasi ma'lumotlar bazasida MS SQL zaxira nusxasini to'laqonli deb hisoblash uchun etarli ma'lumotni saqlamagan va hattoki har bir tuzilish o'zgarishi bilan ham buzilgan. to'liq tiklanish modelining ish sharoitlari, shuning uchun zaxira tizimini asosiy funktsiyasini bajarish uchun turli xil hiyla-nayranglarga borishingiz kerak edi. Ammo 8-versiya chiqqanidan beri DBA-lar nihoyat bo'shashishga muvaffaq bo'lishdi. Standart zaxira vositalari to'liq va to'liq zaxira tizimini yaratishga imkon beradi. Zaxira nusxasiga faqat jurnalni va formalarning holatini belgilash kabi ba'zi bir mayda-chuydalar (eski versiyalarda) qo'shilmaydi, ammo bu ma'lumotlarning yo'qolishi tizimning ishiga ta'sir qilmaydi, garchi bu jurnalning zaxira nusxalarini yaratish aniq va foydalidir.

Nima uchun bizga zaxira nusxasi kerak? Hmm. Bir qarashda bu g'alati savol. Ehtimol, birinchi navbatda, tizimning nusxasini tarqatish va ikkinchidan, ishlamay qolganda tizimni tiklash imkoniyatiga ega bo'lish uchun? Birinchisida men roziman, ammo ikkinchisi bu birinchi zaxira afsonasi.

Zaxira nusxalari tizimingizni xavfsiz saqlashning so'nggi qatoridir. Agar ma'lumotlar bazasi ma'muri mahsulot tizimini zaxira nusxalaridan tiklashi kerak bo'lsa, ehtimol ishni tashkil etishda ko'plab qo'pol xatolarga yo'l qo'yilgan. Ma'lumotlarning yaxlitligini ta'minlashning asosiy usuli sifatida siz zaxira nusxasini ko'rib chiqa olmaysiz, yo'q, lekin u o't o'chirish tizimiga yaqinroq. Yong'in o'chirish tizimi talab qilinadi. U tuzilgan, sinovdan o'tgan va funktsional bo'lishi kerak. Ammo agar u ishlagan bo'lsa, demak, bu juda salbiy oqibatlarga olib keladigan jiddiy favqulodda holat.

Zaxiradan faqat "tinchlik" maqsadlarida foydalanilishini ta'minlash uchun ishlashni ta'minlash uchun boshqa vositalardan foydalaning:

• 
  Serverlaringizni jismonan xavfsiz saqlang: yong'inlar, toshqinlar, elektr ta'minotining yomon manbalari, farroshlar, quruvchilar, meteoritlar va yovvoyi tabiat sizning server xonangizni yo'q qilishni kutmoqda.
  
• 
  Axborot xavfsizligiga tahdidlar uchun javobgardir.
  
• 
  Tizimda professional tarzda o'zgarishlar qiling va iloji boricha ushbu o'zgarishlarning yomonlashishiga olib kelmasligiga ishonch hosil qiling. O'zgarishlar rejasidan tashqari, "ishlar noto'g'ri ketsa nima qilish kerak" rejasini tuzgan ma'qul.
  
• 
  Keyinchalik baxtsiz hodisalar oqibatlarini tozalash o'rniga tizimning mavjudligi va ishonchliligini oshirish uchun texnologiyalardan faol foydalaning. MS SQL uchun siz quyidagi xususiyatlarga e'tibor berishingiz kerak:
  
  • 
    MS SQL klasterlaridan foydalanish (garchi, rostini aytganda, bu 24x7 talab qilmaydigan tizimlar uchun DBA-ni band qilishning eng qimmat va foydasiz usullaridan biri deb o'ylayman)
    
  • 
    Ma'lumotlar bazasini aks ettirish (mavjudligi, ishlashi va xarajat talablariga qarab sinxron va asenkron)
    
  • 
    Yuk tashish operatsiyalari jurnallari
    
  • 
    1C yordamida tarqatish (tarqatilgan ma'lumotlar bazalari)
    

Tizimning mavjud bo'lish talablariga va ushbu maqsadlar uchun ajratilgan byudjetga qarab, ishlamay qolish vaqtini va ishlamay qolish vaqtini 1-2 darajaga qisqartiradigan echimlarni tanlash mumkin. Erişilebilirlik texnologiyalaridan qo'rqishning hojati yo'q: ular MS SQL bo'yicha asosiy bilimlarga ega bo'lgan bir necha kun ichida o'rganish uchun juda sodda.

Ammo, hamma narsaga qaramay, zaxira nusxasi hali ham zarur. Bu boshqa barcha qutqaruv uskunalari ishlamay qolganda foydalanishingiz mumkin bo'lgan zaxira parashyutidir. Ammo, buning uchun haqiqiy zaxira parashyuti kabi:

• 
  ushbu tizim oldindan to'g'ri va professional tarzda tuzilgan bo'lishi kerak,
  
• 
  tizimdan foydalanadigan mutaxassis uni qo'llash bo'yicha nazariy va amaliy ko'nikmalarga ega bo'lishi kerak (muntazam ravishda mustahkamlanib boriladi),
  
• 
  tizim eng ishonchli va oddiy komponentlardan iborat bo'lishi kerak (bu bizning so'nggi umidimiz).
  

MS SQL MA'LUMOTLARINI SAQLASH VA QAYTA ISHLASH HAQIDA ASOSIY MA'LUMOTLAR

MS SQL-dagi ma'lumotlar odatda ma'lumotlar fayllarida saqlanadi (bundan keyin FD - bu tez-tez ishlatib bo'lmaydigan qisqartma, ushbu maqolada juda keng tarqalgan bo'lmagan bir nechta qisqartmalar mavjud) mdf yoki ndf kengaytmalari bilan. Ushbu fayllardan tashqari, ldf kengaytmali fayllarda saqlanadigan tranzaksiyalar jurnallari (TT) ham mavjud. Ajam ma'murlar uchun VT-larni ham ishlash, ham saqlashning ishonchliligi nuqtai nazaridan mas'uliyatsiz va beparvolik bilan qabul qilish odatiy hol emas. Bu juda qo'pol xato. Darhaqiqat, aksincha, agar ishonchli ishlaydigan zaxira tizimi mavjud bo'lsa va tizimni tiklash uchun ko'p vaqt ajratilishi mumkin bo'lsa, siz ma'lumotlarni tezkor, ammo o'ta ishonchsiz RAID-0-da saqlashingiz mumkin, ammo keyin VT alohida ishonchli va samarali manbada saqlanishi kerak (garchi RAID-1da bo'ladi). Nega bunday? Keling, batafsilroq ko'rib chiqaylik. Taqdimot biroz soddalashtirilgan, ammo dastlabki tushunchalar uchun etarli bo'lganligi uchun darhol rezervasyon qilaman.

FD ma'lumotlarni 8K sahifalarda saqlaydi (ular 64K hajmda birlashtiriladi, ammo bu muhim emas). MS SQL kafolat bermaydima'lumotlarni o'zgartirish buyrug'i bajarilgandan so'ng darhol ushbu o'zgarishlar FDga tushadi. Yo'q, faqat xotirada bir sahifa "saqlash uchun" deb belgilanadi. Agar serverda etarli resurs mavjud bo'lsa, unda tez orada bu ma'lumotlar diskda bo'ladi. Bundan tashqari, server "optimistik" ishlaydi va agar bu o'zgarishlar tranzaktsiyada yuz bersa, ular tranzaktsiyani amalga oshirishdan oldin diskka tushishi mumkin. Ya'ni, odatda, faol ish bilan FD to'liq bo'lmagan ma'lumotlar va tugallanmagan bitimlarning tarqoq qismlarini o'z ichiga oladi, ular uchun ularning bekor qilinishi yoki sodir etilishi noma'lum. "CHECKPOINT" maxsus buyrug'i mavjud bo'lib, u serverga barcha saqlanmagan ma'lumotlarni "hozircha" diskka yuborishini aytadi, ammo bu buyruq doirasi juda aniq. 1C uni ishlatmasligini aytish kifoya (men u bilan uchrashmaganman) va ish paytida FD odatda ajralmas holatda emasligini tushunaman.

Ushbu betartiblikni engish uchun bizga VT kerak. Unga quyidagi voqealar yozilgan:

• 
  Bitimning boshlanishi va uning identifikatori to'g'risida ma'lumot.
  
• 
  Bitimni amalga oshirish yoki bekor qilish faktlari to'g'risida ma'lumot.
  
• 
  FD-dagi ma'lumotlarning barcha o'zgarishlari (taxminan, nima bo'lgan va nima bo'lgan) haqida ma'lumot.
  
• 
  FDning o'zi yoki ma'lumotlar bazasi tuzilishini o'zgartirish to'g'risida ma'lumotlar (fayllarni ko'paytirish, fayllarni qisqartirish, sahifalarni ajratish va chiqarish, jadvallar va indekslarni yaratish va o'chirish)
  

Ushbu ma'lumotlarning barchasi, u sodir bo'lgan bitimning identifikatori ko'rsatilishi bilan yozilgan va ushbu operatsiyadan oldin holatdan ushbu operatsiyadan keyin holatga qanday o'tishni tushunish uchun etarli hajmda va aksincha (istisno - bu ommaviy ro'yxatga olingan tiklash modeli).

Ushbu ma'lumot darhol diskka yozilishi juda muhimdir. Ma'lumot VT-da qayd etilmaguncha, buyruq bajarilgan deb hisoblanmaydi. Oddiy vaziyatda, VT hajmi etarlicha hajmga ega bo'lganda va u juda bo'linmagan bo'lsa, yozuvlar unga ketma-ket kichik yozuvlarda yoziladi (8 kb ga ko'paytirilishi shart emas). Tranzaktsiyalar jurnaliga faqat tiklash uchun juda zarur bo'lgan ma'lumotlar kiradi. Jumladan emas qaysi so'rov matni modifikatsiyaga olib kelganligi, ushbu so'rov qanday bajarilish rejasi bo'lganligi, qaysi foydalanuvchi tomonidan ishga tushirilganligi va qayta tiklash uchun keraksiz bo'lgan boshqa ma'lumotlar haqida ma'lumot olinadi. So'rov orqali tranzaktsiyalar jurnalining ma'lumotlar tuzilishi haqida ba'zi fikrlarni berish mumkin

* Dan :: fn_dblog-ni tanlang (, null)

Qattiq disklar ketma-ket yozish bilan o'qish va yozish buyruqlarining xaotik oqimiga qaraganda ancha samarali ishlashi sababli va SQL buyruqlari VTga yozish tugaguncha kutib turishi sababli quyidagi tavsiyalar paydo bo'ladi:

Agar eng kichik ehtimollik bo'lsa, u holda ishlab chiqarish muhitida VTlar alohida (hamma narsadan) jismoniy ommaviy axborot vositalarida, tercihen ketma-ket yozib olish uchun minimal kirish vaqti va maksimal ishonchlilik bilan joylashtirilgan bo'lishi kerak. Oddiy tizimlar uchun RAID-1 yaxshi.

Agar tranzaksiya bekor qilinsa, server allaqachon kiritilgan barcha o'zgarishlarni avvalgi holatiga qaytaradi. Shunung uchun

MS SQL Server-da tranzaktsiyani bekor qilish, odatda operatsiyaning o'zi ma'lumotlarini o'zgartiradigan operatsiyalarning umumiy davomiyligi bilan taqqoslanadigan darajada davom etadi. Tranzaktsiyalarni bekor qilmaslikka yoki bekor qilish to'g'risida qarorni iloji boricha erta qabul qilishga harakat qiling.

Agar server kutilmaganda biron bir sababga ko'ra ishlamay qolsa, qayta ishga tushirilgandan so'ng, FD-dagi qaysi ma'lumotlar ajralmas holatga to'g'ri kelmasligi tahlil qilinadi (ro'yxatga olinmagan, ammo amalga oshirilgan operatsiyalar va qayd qilingan, ammo bekor qilingan operatsiyalar) va ushbu ma'lumotlar tuzatiladi. Shuning uchun, masalan, siz katta jadval indekslarini tiklashni boshlagan bo'lsangiz va serverni qayta ishga tushirgan bo'lsangiz, uni qayta ishga tushirganingizda, ushbu operatsiyani qaytarib olish uchun juda ko'p vaqt kerak bo'ladi va bu jarayonni to'xtatishning imkoni yo'q.

VT fayl oxiriga yetganda nima bo'ladi? Bu oddiy - agar boshida bo'sh joy bo'lsa, u faylning boshidagi bo'sh joyga egallab olingan maydonga yozishni boshlaydi. Loopback lentasi kabi. Agar boshida bo'sh joy bo'lmasa, u holda server odatda tranzaksiyalar jurnali faylini kengaytirishga harakat qiladi, server uchun ajratilgan yangi bo'lak esa yangi virtual tranzaksiyalar jurnali bo'lib, ulardan jismoniy tranzaksiyalar faylida ko'p bo'lishi mumkin, ammo bu zaxira nusxasiga taalluqli emas. Agar server faylni kengaytira olmasa (diskdagi bo'sh joy tugagan bo'lsa yoki sozlamalarni LT-ni kengaytirish taqiqlangan bo'lsa), u holda 9002 xato bilan joriy operatsiya bekor qilinadi.

Afsus! Va VT-da doimo o'z joyiga ega bo'lish uchun nima qilish kerak? Bu erda biz zaxira tizimiga va tiklash modellariga kelamiz. Tranzaktsiyalarni bekor qilish va to'satdan to'xtab qolish holatida serverning to'g'ri holatini tiklash uchun eng erta ochilgan tranzaksiya boshlangan paytdan boshlab ZhT-da yozuvlarni saqlash kerak. Ushbu minimal VTda yoziladi va saqlanadi albatta... Ob-havodan qat'i nazar, server sozlamalari va administratorning xohish-istaklari. Server ushbu ma'lumotlarning yo'q bo'lishiga yo'l qo'yishi mumkin emas. Shuning uchun, agar siz bitimni bitta seansda ochsangiz va boshqalarda turli xil harakatlarni amalga oshirsangiz, tranzaksiyalar jurnali kutilmaganda tugashi mumkin. Eng erta operatsiyani DBCC OPENTRAN buyrug'i bilan aniqlash mumkin. Ammo bu faqat kerakli minimal ma'lumot. Keyinchalik bog'liq tiklash modellari... SQL Serverda ulardan uchtasi mavjud:

•