Qanday Yaxshi
Download 1.38 Mb.
|
MS SQL ZAXIRA NUSXASI AVTOMATIK RAVISHDA FAYLGA. MS SQL SERVER MA'LUMOTLAR BAZASINING MUNTAZAM ZAXIRA NUSXASINI O'RNATISH
- Bu sahifa navigatsiya:
- Qanday Yaxshi yomon Jami
- Simple sizga diskning quyi tizimidagi yukni kamaytirishga imkon beradi
- Toliq
- "RKZT-da oldingi toliq yoki differentsial zaxiradagi tranzaksiyalar jurnali malumotlari mavjud."
- VT vaqti-vaqti bilan qol bilan tozalanishi, kamaytirilishi, qisqarishi kerak.
|
MS SQL ZAXIRA NUSXASI AVTOMATIK RAVISHDA FAYLGA. MS SQL SERVER MA'LUMOTLAR BAZASINING MUNTAZAM ZAXIRA NUSXASINI O'RNATISH JB ma'murlari zaxira nusxasini yaratadigan va zaxira nusxasini yaratadiganlarga bo'linadi. KIRISH Ushbu maqola MS SQL Server 2008 R2 vositalaridan foydalangan holda 1C axborot xavfsizligining eng keng tarqalgan zaxira nusxasini tavsiflaydi, nima uchun buni boshqacha emas, balki shu tarzda qilish kerakligini tushuntiradi va bir nechta afsonalarni tarqatib yuboradi. Maqolada MS SQL hujjatlariga juda ko'p havolalar mavjud, ushbu maqola to'liq qo'llanma emas, balki zaxira mexanizmlarining umumiy ko'rinishi. Ammo bu vazifa bilan birinchi marta duch kelganlar uchun oddiy vaziyatlarga taalluqli oddiy va bosqichma-bosqich ko'rsatmalar beriladi. Maqola ma'muriyat gurusi, gurusi uchun mo'ljallanmagan va shuning uchun hamma buni biladi, ammo o'quvchi MS SQL Serverni o'zi o'rnatishi va bu dushmanlik texnologiyasining mo''jizasini o'z ichkarisida ma'lumotlar bazasini yaratishga majbur qilishi, bu esa o'z navbatida 1C ma'lumotlarini saqlashga majbur qilishi mumkin deb taxmin qilinadi. Men TSQL BACKUP DATABASE buyrug'ini (va uning ukasi BACKUP LOG) asosan MS SQL Serverni DBMS sifatida ishlatadigan 1C ma'lumotlar bazalari uchun yagona zaxira vositasi deb bilaman. Nima uchun? Keling, umuman qanday usullarimiz borligini ko'rib chiqamiz:
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: Oddiy - faqat hayot uchun zarur bo'lgan VT qoldig'i saqlanadi. To'liq - butun VT oxirgi zaxira nusxasidan beri saqlanadi operatsiyalar jurnali... Iltimos, to'liq zaxira nusxasidan boshlab emas, e'tibor bering! Ommaviy tizimga yozildi - operatsiyalarning bir qismi (odatda juda kichik qismi) juda ixcham shaklda yoziladi (aslida faqat ma'lumotlar faylining falon sahifasi o'zgartirilganligi haqidagi yozuv). Aks holda to'liq bilan bir xil. Qayta tiklash modellari bilan bog'liq bir nechta afsonalar mavjud. Simple sizga diskning quyi tizimidagi yukni kamaytirishga imkon beradi... Bu unday emas. u Bulk jurnalida yozilgan bilan bir xil tarzda yoziladi, faqat u ancha oldin bepul hisoblanadi. Ommaviy ravishda ro'yxatdan o'tgan diskning quyi tizimidagi yukni kamaytiradi... 1C uchun bu deyarli emas. Darhaqiqat, daf bilan qo'shimcha raqsga tushmasdan, minimal jurnalga tushishi mumkin bo'lgan bir nechta operatsiyalardan biri - ma'lumotlarni dt formatida tushirish va jadvallarni qayta tuzish. Bulk logged modelidan foydalanganda, ba'zi operatsiyalar tranzaksiyalar jurnali zaxirasiga kiritilmaydi va bu sizga ushbu zaxira nusxasini olish paytida holatni tiklashga imkon bermaydi. Bu butunlay to'g'ri emas. Agar operatsiya minimal ro'yxatga olinganlardan biri bo'lsa, u holda ma'lumotlar mavjud bo'lgan sahifalar zaxira nusxasini yaratadi va tranzaksiyalar jurnalini oxirigacha "o'ynash" mumkin bo'ladi (garchi minimal ro'yxatga olingan operatsiyalar bo'lsa, o'zboshimchalik bilan bir lahzani amalga oshirish mumkin emas). 1C ma'lumotlar bazalari uchun ommaviy ro'yxatga olingan modeldan foydalanish deyarli ma'nosiz, shuning uchun biz uni endi ko'rib chiqmaymiz. Ammo To'liq va Oddiy tanlov keyingi qismida batafsil muhokama qilinadi. Tranzaksiyalar jurnalining tuzilishi Qayta tiklash modellari va tranzaktsiyalar jurnalini boshqarish Tranzaksiyalar jurnalini boshqarish Tranzaksiya jurnalining zaxira nusxalarini ishlatish ODDIY VA TO'LIQ TIKLASH MODELLARIDA ZAXIRA NUSXASI QANDAY ISHLAYDI Shakllanish turlari bo'yicha zaxira nusxalarining uch turi mavjud: To'liq (To'liq) Differentsial (Differentsial, differentsial) Kirish (Ushbu atama qanchalik tez-tez ishlatilishini hisobga olgan holda tranzaksiyalar jurnallarining zaxira nusxasi FCTCgacha qisqartiriladi) Bu erda chalkashmang: to'liq tiklanish modeli va to'liq zaxira - bu tubdan farq qiladigan narsalar. Ularni chalkashtirmaslik uchun quyida tiklash modeli uchun inglizcha va zaxira nusxalari uchun rus tilidan foydalanaman. To'liq va differentsial nusxalar oddiy va to'liq uchun bir xil ishlaydi. Simple-da tranzaksiyalar jurnalining zaxira nusxasi umuman yo'q. TO'LIQ ZAXIRA NUSXASI Ma'lumotlar bazasining holatini ma'lum vaqt ichida tiklashga imkon beradi (zaxira nusxasi ishga tushirilgan). Ma'lumotlar fayllarining ishlatilgan qismining sahifadan nusxasiga va tranzaksiyalar jurnalining zaxira nusxasi hosil bo'lgan vaqtdagi faol qismidan iborat. DIFFERENTSIAL ZAXIRA Oxirgi to'liq zaxiradan keyin o'zgargan ma'lumotlar sahifalarini saqlaydi. Qayta tiklashda avval to'liq zaxira nusxasini tiklashingiz kerak (NORECOVERY rejimida quyida misollar keltirilgan), so'ngra hosil bo'lgan "stub" ga keyingi differentsial nusxalardan birini qo'llashingiz mumkin, ammo, albatta, faqat keyingi to'liq zaxiralashdan oldin olingan nusxalarni. Bu zaxira nusxasini saqlash uchun disk maydonini sezilarli darajada kamaytirishi mumkin. Muhim fikrlar:
Differentsial nusxasi oldingi to'liq zaxirasiz foydasizdir. Shuning uchun ularni bir-biriga yaqin joyda saqlash maqsadga muvofiqdir. Har bir keyingi differentsial zaxira nusxasi avvalgi to'liq zaxiradan so'ng tuzilgan oldingi differentsial zaxiraga kiritilgan barcha sahifalarni saqlaydi (garchi, ehtimol, har xil tarkib bilan). Shuning uchun har bir keyingi differentsial nusxa oldingi nusxalarga qaraganda kattaroq bo'lib, to'liq nusxa qayta tiklangunga qadar (agar bu buzilgan bo'lsa, bu faqat siqish algoritmlari tufayli) Bir lahzaga tiklanish uchun bu etarli oxirgi bu vaqtda to'liq zaxira nusxasi va oxirgi bu erda differentsial nusxa. Qutqarish uchun oraliq nusxalar kerak emas (garchi ular qachon tiklanishini tanlash uchun kerak bo'lishi mumkin bo'lsa ham) RCWT Muayyan muddat uchun VT nusxasini o'z ichiga oladi. Odatda, avvalgi RCWTdan boshlab hozirgi RCWT shakllanishigacha. FCZHT holatini NORECOVERY rejimida tiklangan nusxasidan VTning tiklangan nusxasi davriga kiritilgan istalgan vaqtgacha, tiklangan zaxira oralig'iga kiritilgan vaqtning istalgan nuqtasiga qadar tiklashga imkon beradi. Standart parametrlarga ega zaxira nusxasini yaratishda tranzaksiyalar jurnali faylida bo'sh joy bo'shatiladi (oxirgi ochiq tranzaksiya paytigacha). Shubhasiz, RCLT Simple modelida mantiqiy emas (u holda LT oxirgi yopilmagan bitimdan beri faqat ma'lumotni o'z ichiga oladi). RCWT dan foydalanishda muhim tushuncha paydo bo'ladi - uzluksiz RKZHT zanjiri... Ushbu zanjirni ushbu zanjirning ba'zi zaxira nusxalarini yo'qotish yoki ma'lumotlar bazasini oddiy va orqaga almashtirish orqali to'xtatish mumkin. E'tibor bergan: RCST to'plami, agar u doimiy zanjir bo'lmasa, aslida foydasiz, va oxirgi muvaffaqiyatli to'liq yoki differentsial zaxiraning boshlanish vaqti bo'lishi kerak ichidaushbu zanjirning davri. Tez-tez noto'g'ri tushunchalar va afsonalar: "RKZT-da oldingi to'liq yoki differentsial zaxiradagi tranzaksiyalar jurnali ma'lumotlari mavjud." Yoq bu unday emas. RCWT oldingi RCWT va undan keyingi to'liq zaxira o'rtasida befoyda ko'rinadigan ma'lumotlarni o'z ichiga oladi. "To'liq yoki differentsial zaxira nusxalari operatsiyalar jurnali ichidagi bo'sh joyni bo'shatishi kerak."Yoq bu unday emas. To'liq va differentsial zaxira nusxalari RKZHT zanjiriga tegmaydi. VT vaqti-vaqti bilan qo'l bilan tozalanishi, kamaytirilishi, qisqarishi kerak.Yo'q, bu kerak emas va hatto aksincha - bu istalmagan. Agar VTlar FCLTlar orasida chiqarilsa, tiklash uchun zarur bo'lgan FCLT zanjiri buziladi. Va faylning doimiy kamayishi / kengaytmasi uning fizikaviy va mantiqiy bo'linishiga olib keladi. QANDAY QILIB ODDIY ISHLAYDI Aytaylik, 1000 Gb ma'lumotlar bazasi mavjud. Har kuni ma'lumotlar bazasi 2 Gbaytga o'sadi, 10 Gb eski ma'lumotlar o'zgaradi. Quyidagi zaxira nusxalari yaratildi 1-fevral soat 0:00 dan boshlab F1-ning to'liq nusxasi (1000 Gb hajm, biz soddaligi uchun siqishni hisobga olmaymiz) Delta nusxasi D1.1 2 fevral soat 0:00 dan (12 GB hajmda) Delta nusxasi D1.2 3 fevral soat 0:00 dan (19 GB) Delta nusxasi D1.3 4-fevral kuni soat 0:00 (25GB) Delta nusxasi D1.4 5-fevral kuni soat 0:00 (31GB) Delta nusxasi D1.5 6-fevral kuni soat 0:00 (36GB) Delta nusxasi D1.6 7-fevral kuni soat 0:00 (40GB) 8-fevral soat 0:00 dan F2 ning to'liq nusxasi (hajmi 1014 GB) Delta nusxasi D2.1 9-fevral kuni soat 0:00 (12 Gb hajmda) Delta nusxasi D2.2 10 fevral soat 00:00 da (19 GB) Delta nusxasi D2.3 11 fevral soat 0:00 dan (25 GB hajmda) Delta nusxasi D2.4 12 fevral soat 12:00 dan (31GB) Delta nusxasi D2.5 13 fevral soat 0:00 dan (36 Gb) Delta nusxasi D2.6 14-fevral kuni soat 0:00 (40 Gb) Ushbu to'plam yordamida biz ma'lumotlarni 1-dan 14-fevralgacha bo'lgan har qanday vaqtda soat 00: 00da tiklashimiz mumkin. Buning uchun biz 1-7 fevral kunlari uchun F1 ning to'liq nusxasini yoki 8-14 fevral kunlari uchun F2 ning to'liq nusxasini olishimiz, NORECOVERY rejimida tiklashimiz va keyin kerakli kunning differentsial nusxasini qo'llashimiz kerak. QANDAY QILIB U TO'LIQ ISHLAYDI Bizda oldingi misolda bo'lgani kabi bir xil to'liq va differentsial zaxira nusxalari mavjud. Bunga qo'shimcha ravishda quyidagi FCWTlar mavjud: 1-RCWT 31-yanvar soat 12:00 dan 2-fevral soat 12:00 gacha (taxminan 30 GB) RCWT 2 2 fevral soat 12:00 dan 4 fevral 12:00 gacha (taxminan 30 GB) RCWT 3 4 fevral soat 12:00 dan 6 fevral 12:00 gacha (taxminan 30 GB) RCWT 4 6 fevral soat 12:00 dan 7 fevral 12:00 gacha (taxminan 30 GB) RCWT 5 8 fevral soat 12:00 dan 10 fevral 12:00 gacha (taxminan 30 GB) RCWT 6 10 fevral soat 12:00 dan 12 fevral 12:00 gacha (taxminan 30 GB) RCWT 7 12 fevral soat 12:00 dan 14 fevral 12:00 gacha (taxminan 30 GB) RCWT 8 14 fevral soat 12:00 dan 16 fevral 12:00 gacha (taxminan 30 GB) Eslatma: FCTC hajmi taxminan doimiy bo'ladi. Biz zaxira nusxalarini differentsial yoki to'liq zaxira nusxalaridan kamroq yoki tez-tez qilishimiz mumkin, shunda ular hajmi kichikroq bo'ladi. Endi biz tizimning holatini istalgan nuqtaga 1 fevral soat 0:00 dan tiklashimiz mumkin, u erda biz eng dastlabki to'liq nusxaga egamiz - 16 fevral soat 12:00 gacha. Oddiy holatda, biz tiklashimiz kerak: Qayta tiklashdan oldin oxirgi to'liq nusxa Qayta tiklashdan oldin so'nggi delta nusxasi Barcha RCST-lar, oxirgi differentsial nusxadan tiklangan paytgacha 8-fevral soat 0:00 dan boshlab F2-ning to'liq nusxasi Delta nusxasi D2.2 10 fevral soat 0:00 dan RCWT 6 10 yanvar soat 12:00 dan 12 fevral 12:00 gacha Birinchidan, F2 qayta tiklanadi, keyin D2.2, keyin RCWT 6 10 fevral soat 13: 13: 13gacha. Ammo To'liq modelning muhim ustunligi shundaki, bizda tanlov mavjud - oxirgi to'liq yoki differentsial nusxasini ishlatish yoki oxirgisi YO'Q. Masalan, agar D2.2 nusxasi buzilganligi aniqlangan bo'lsa va biz 10 fevral soat 13: 13: 13gacha bo'lgan vaqtni tiklashimiz kerak bo'lsa, unda oddiy model uchun bu biz ma'lumotlarni faqat D2.1 lahzasida tiklashimiz mumkinligini anglatadi. Full - "DON" T PANIC "bilan bizda quyidagi imkoniyatlar mavjud: 10-fevral kuni soat 13:13:13 gacha F2, keyin D2.1, keyin RKZHT 5, keyin RKZhT 6-ni tiklang. 10 fevral kuni soat 13: 13: 13gacha F2, keyin RKZhT 4, keyin RKZhT 5, keyin RKZhT 6 ni tiklang. Yoki odatda F1-ni qayta tiklang va barcha RCWT-larni RCWT 6-ga 10-fevral soat 13: 13: 13gacha haydang. Ko'rib turganingizdek, to'liq model bizga ko'proq tanlov beradi. Endi tasavvur qilaylik, biz juda ayyormiz. Muvaffaqiyatsizlikdan bir necha kun oldin (10-fevral kuni 13:13:13) Bilamizki, muvaffaqiyatsizlik bo'ladi. Biz ma'lumotlar bazasini qo'shni serverdagi to'liq zaxiradan tiklaymiz, keyingi holatlarni differentsial nusxalari yoki RKZHT bilan aylantirishni davom ettirish imkoniyatini qoldiramiz, ya'ni uni NORECOVERY rejimida qoldirdik. Va har safar, RKZHT tashkil etilgandan so'ng, biz uni "NORECOVERY" rejimida qoldirib, ushbu zaxira bazasiga qo'llaymiz. Voy! Ma'lumotlar bazasini tiklash endi ulkan ma'lumotlar bazasini tiklash o'rniga atigi 10-15 daqiqa vaqtni oladi! Tabriklaymiz, biz ish vaqtini qisqartirish usullaridan biri bo'lgan loglarni etkazib berish mexanizmini qayta kashf etdik. Agar siz ma'lumotni shu tarzda bir davrda bir necha marta, lekin doimiy ravishda uzatsangiz, u holda aks ettirish allaqachon olingan bo'ladi va agar manba bazasi oyna bazasini yangilashni kutayotgan bo'lsa, demak bu sinxron aks etish, agar bo'lmasa, keyin asenkron. Yuqori darajadagi vositalar haqida ko'proq ma'lumotni yordamdan o'qishingiz mumkin:
Mavjudligi yuqori (ma'lumotlar bazasi mexanizmi) Mavjudligi yuqori bo'lgan echimlarni tushunish Mavjudlikning yuqori darajasi. O'zaro hamkorlik va hamkorlik ZAXIRALASHNING BOSHQA JIHATLARI Agar siz zaxira sozlamalarini sinab ko'rish uchun nazariya va qichishishdan zeriksangiz, ushbu bo'limni xavfsiz ravishda o'tkazib yuborishingiz mumkin. FAYL GURUHLARI 1C: Korxona aslida fayl guruhlari bilan ishlay olmaydi. Bitta fayl guruhi mavjud va shu bilan. Aslida, dasturchi yoki MS SQL ma'lumotlar bazasi ma'muri ba'zi jadvallarni, indekslarni, hatto jadvallar va indekslarning qismlarini alohida fayl guruhlariga (eng sodda shaklda, alohida fayllarga) joylashtirishga qodir. Bu ba'zi ma'lumotlarga kirishni tezlashtirish uchun (uni juda tezkor vositalarga joylashtirish) yoki aksincha, ularni arzonroq axborot vositalariga joylashtirish uchun tezligidan voz kechish uchun kerak (masalan, kam ishlatilgan, ammo hajmli ma'lumotlar). Fayl guruhlari bilan ishlashda ularning zaxira nusxalarini alohida-alohida qilish mumkin, shuningdek ularni alohida tiklashingiz mumkin, ammo shuni hisobga olish kerakki, barcha fayl guruhlari RKZHT-ni siljitish orqali bir lahzaga "tutilishi" kerak bo'ladi. MA'LUMOTLAR FAYLLARI Agar ma'lumotlarni turli xil fayl guruhlariga joylashtirishni shaxs boshqarsa, u holda fayllar guruhi ichida bir nechta fayllar mavjud bo'lganda, MS SQL Server ulardagi ma'lumotlarni mustaqil ravishda surib yuboradi (teng hajmdagi fayllar bilan u bir tekis harakat qiladi). Ilova nuqtai nazaridan, bu I / U operatsiyalarini parallellashtirish uchun ishlatiladi. Va zaxira nusxasi nuqtai nazaridan yana bir nuqta bor. SQLdan oldingi 2008 yildagi juda katta ma'lumotlar bazalari uchun to'liq zaxira nusxasini yaratish uchun bir-biriga yaqin oynani ajratish odatiy muammo edi va ushbu zaxira nusxasi uchun mo'ljallangan disk shunchaki uni sig'dira olmasligi mumkin. Bu holda eng oson yo'li har bir faylning (yoki fayl guruhining) zaxira nusxasini o'z oynasida yaratish edi. Endi, zaxira siqishni faol ravishda ko'payishi bilan, bu muammo kamaydi, ammo siz hali ham ushbu texnikani yodda tutishingiz mumkin. ZAXIRA NUSXALARINI SIQISH MS SQL Server 2008 super-mega-ultra xususiyatiga ega. Bundan buyon zaxira nusxalarini yaratishda siqish mumkin. Bu 1C ma'lumotlar bazasini zaxiralash hajmini 5-10 baravar qisqartiradi. Va odatda disk quyi tizimining ishlashi DBMSning tor yo'lidir, bu nafaqat saqlash narxining pasayishini, balki zaxiralashning kuchli tezlashishini ham beradi (garchi protsessorlarga yuk ortadi, lekin odatda protsessor hajmi DBMS serverida etarli). Agar 2008 yilgi versiyada bu xususiyat faqat Enterprise nashriga tegishli bo'lsa (bu juda qimmat), unda 2008 yil R2 da ushbu xususiyat standart versiyaga berilgan, bu juda yoqimli. Siquv sozlamalari quyidagi misollarda ko'rib chiqilmagan, ammo zaxira siqishni o'chirish uchun aniq bir sabab bo'lmasa foydalanishni tavsiya etaman. BITTA ZAXIRA FAYL - KO'PLAB ICHKI FAYLLAR Darhaqiqat, zaxira nusxasi shunchaki fayl emas, bu juda ko'p zaxira nusxalarini saqlash mumkin bo'lgan juda murakkab konteyner. Ushbu yondashuv juda qadimiy tarixga ega (men buni shaxsan 6.5-versiyadan beri kuzatganman), ammo hozirda "oddiy" ma'lumotlar bazalari, ayniqsa 1C ma'lumotlar bazalari ma'murlari uchun "bitta zaxira - bitta fayl" usulidan foydalanmaslik uchun jiddiy sabab yo'q. ... Umumiy rivojlanish uchun bitta faylga bir nechta zaxira nusxalarini qo'shish imkoniyatini o'rganish foydalidir, ammo, ehtimol siz uni ishlatishingizga to'g'ri kelmaydi (yoki agar kerak bo'lsa, ushbu imkoniyatdan malakasiz foydalangan bo'lajak ma'murning xarobalarini saralash). KO'P OYNALI NUSXALAR SQL Serverda yana bir ajoyib xususiyat mavjud. Siz bir nechta qabul qilgichda parallel ravishda zaxira nusxasini yaratishingiz mumkin. Oddiy misol sifatida siz bitta nusxani mahalliy diskka tashlab, bir vaqtning o'zida uni tarmoq ulushiga qo'shishingiz mumkin. Mahalliy nusxa ko'chirish qulay, chunki undan qutqarish tezroq bo'ladi, uzoqdan nusxa ko'chirish esa boshqa ma'lumotlar bazasi serverining jismoniy yo'q qilinishiga toqat qiladi. ZAXIRA TIZIMLARIGA MISOLLAR Nazariya etarli. Bu butun oshxona ishlayotganligini amaliyot bilan isbotlash vaqti keldi. XIZMAT KO'RSATISH REJALARI ORQALI ODATDAGI SERVER ZAXIRALARINI SOZLASH Ushbu bo'lim tushuntirishlar bilan tayyor retseptlar shaklida qurilgan. Ushbu bo'lim rasmlar tufayli juda zerikarli va uzoq, shuning uchun uni o'tkazib yuborishingiz mumkin. TA'MINOT REJASI USTASINI ISHLATISH TSQL SKRIPTLARI, BA'ZI FUNKTSIYALARGA MISOLLAR YORDAMIDA SERVERLARNING ORTIQCHA MIQDORINI SOZLASH Darhol savol tug'iladi, yana nima kerak? Hammasi yangi tashkil etilganga o'xshaydi va hamma soat kabi ishlaydi? Nima uchun har xil skriptlar bilan bezovtalanish kerak? Ta'minot rejalari quyidagilarga yo'l qo'ymaydi: Ko'zguli ortiqcha ishdan foydalaning Siquv sozlamalarini server sozlamalaridan farqli ravishda foydalaning Yuzaga keladigan vaziyatlarga moslashuvchan munosabatda bo'lishga yo'l qo'ymaydi (xatolarni ko'rib chiqish qobiliyatlari yo'q) Xavfsizlik sozlamalaridan moslashuvchan foydalanishga yo'l qo'ymaydi Xizmat ko'rsatish rejalari juda ko'p sonli serverlarda (hatto, ehtimol allaqachon 3-4) joylashtirilishi (va huddi shunday saqlanishi) juda noqulay. Quyida odatiy zaxira buyruqlari keltirilgan TO'LIQ ZAXIRA NUSXASI To'liq zaxira nusxasi, mavjud faylning ustiga yozish (agar mavjud bo'lsa) va yozishdan oldin sahifa summasini tekshirish. Zaxira nusxasini yaratishda taraqqiyotning har bir foizi hisobga olinadi DISKGA Zaxira ma'lumotlar bazasi \u003d N "C: \\ Backup \\ mydb.bak" INIT, FORMAT, STATS \u003d 1, CHECKSUM BILAN
Xuddi shunday - differentsial nusxa DISKGA Zaxira ma'lumotlar bazasi \u003d N "C: \\ Backup \\ mydb.diff" BILAN DIFFERENTIAL, INIT, FORMAT, STATS \u003d 1, CHECKSUM
Tranzaksiyalar jurnalini zaxiralash DISKGA ZAXIRA KIRISH \u003d N "C: \\ Backup \\ mydb.trn" INIT, FORMAT BILAN
Bir vaqtning o'zida bitta zaxira nusxasini emas, balki ikkitasini nusxalash juda qulay. Misol uchun, kimdir serverda mahalliy darajada yotishi mumkin (shunda u yonida), ikkinchisi esa darhol jismonan uzoqdan shakllanadi va zararli ta'sirlardan saqlanadi: DISKGA Zaxira ma'lumotlar bazasi \u003d N "C: \\ Backup \\ mydb.bak", Oyna DISK \u003d N "\\\\ safe-server \\ backup \\ mydb.bak" INIT, FORMAT BILAN Tez-tez e'tibordan chetda qoladigan muhim nuqta: MSSQL Server jarayoni boshlangan foydalanuvchi "\\\\ safe-server \\ backup \\" resursiga kirish huquqiga ega bo'lishi kerak, aks holda nusxalash xato bilan tugaydi. Agar MSSQL Server tizim nomidan ishlayotgan bo'lsa, unda "server_name $" domeni foydalanuvchisiga ruxsat berilishi kerak, ammo MS SQL-ni ishga tushirishni maxsus yaratilgan foydalanuvchi nomidan to'g'ri sozlagan ma'qul. Agar siz MIRROR TO-ni ko'rsatmasangiz, u holda bu o'zgaruvchan printsipga binoan 2 ta oynaga bo'lingan ikkita nusxa emas, balki bitta nusxa bo'ladi. Va ularning har biri alohida-alohida foydasiz bo'ladi. Ushbu maqolada Microsoft SQL Server Management Studio-dan foydalanib ma'lumotlar bazasini to'liq zaxira nusxasini qanday qilib qo'lda yaratish haqida tavsiflanadi. 1. ZAXIRA NUSXASINI YARATISH Bu aslida juda oddiy. Biz snap-inni ishga tushiramiz " » (« Boshlang» — « Barcha dasturlar» — « SQL Server 2008 R2» — « Microsoft SQL Server Management Studio») Va avtorizatsiya qilish uchun ma'lumotlarni kiriting. 
Keyin, ob'ektlar brauzerida “yorlig'ini oching Ma'lumotlar bazasi"Va zaxira nusxasini yaratmoqchi bo'lgan ma'lumotlar bazasini o'ng tugmasini bosing. Ko'rsatilgan kontekst menyusida “ Vazifalar» ( Vazifalar) — « Zaxira nusxasini yarating» ( Zaxira nusxasi ...) . 
Oyna “ Ma'lumotlar bazasini zaxiralash» ( Ma'lumotlar bazasini zaxiralash). Bunga arziydi " To'liq» ( To'liq), agar kerak bo'lsa, ism va tavsifni o'rnating, shuningdek zaxiralashning maqsadini ko'rsating. Odatiy bo'lib, kompyuterning qattiq diskida SQL server ma'lumotlar bazalarining asosiy joylashuvi zaxira papkasiga yo'l tanlangan. Nusxa olish joyini o'zgartirish uchun avval " O'chirish» ( Olib tashlash) mavjud topshiriqni olib tashlash uchun, keyin esa " qo'shish» ( Qo'shish…) Yangisini qo'shish uchun. 
Bu erda biz zaxira faylining joylashishini va nomini o'rnatamiz va "tugmasini bosing OK". Siz bir nechta bunday yo'nalishlarni belgilashingiz mumkin. Bunday holda, zaxira nusxasi ko'rsatilgan qismdagi har bir qism teng qismlarga bo'linadi. 
Barcha sozlamalar o'rnatilganda, "tugmasini bosing OK"Va vazifa bajarilishini kuting. Agar hamma narsa to'g'ri bajarilgan bo'lsa, biz SQL ma'lumotlar bazasining zaxira nusxasini ko'rsatilgan katalogdan topamiz. 
2. MA'LUMOTLAR BAZASINI ZAXIRA NUSXASIDAN TIKLASH Qayta tiklash shunga o'xshash tarzda amalga oshiriladi. IN " Microsoft SQL Server Management Studio»Baza tanlang Download 1.38 Mb. Do'stlaringiz bilan baham: 
|