Работа с регистър на операциите
Понякога има впечатлението, че регистър на операциите, има живот. Пространството вътре в лог файл може да расте и да се свие, без никаква видима причина беше. Ако се чувствате изгубени, когато се работи със списанието, че не сте сами. В този раздел ще хвърли светлина върху вътрешния живот на регистъра на операциите.
Вътрешният свят на регистъра на операциите
регистър на операциите, съдържа всички транзакции в базата данни. Ако сървърът изтрива регистър на транзакциите, всички записани в сделката той използва за възстановяване. В този случай, всички частично отпор на сделката и да прекрати тези, които са били потвърдени в регистъра на операциите, но все още не е записан файла с данни.
На практика, този журнал може да се мисли като последователен списък на сделките сортирани по дата и час. В същото време, на физическо ниво SQL Server записва различните части на физическото дневника на виртуални единици, без някакъв определен ред. Някои части от него могат да бъдат в експлоатация, а останалите части са на разположение за пренаписване, като Changeling.
Разделянето на активни и неактивни части
Всички операции в дневника могат да бъдат разделени в две групи (фиг. 36.4).
Активни сделки - тези, които все още не са потвърдени и не се записват в базата данни.
Inactive сделка - това са настъпили преди ранния активна сделката.
Тъй като всички сделки са на различна продължителност и потвърдени по различно време, вероятността, че активната част на списанието, ще бъдат заделени сделки, е доста висок. Активната част на дневника не е задължително да съдържа само неангажирани сделките - това включва всички сделки от началото на най-старите поети транзакции. Само един много стар непотвърдена сделка може да направи една много голяма част от активното дневника.
Фиг. 36.4. Inactive сделка предхожда най-старият действащ
Контролните пунктове сделка
Разбирането за това как SQL Server използва контролните точки в регистъра на операциите, това е от съществено значение за разбирането на процеса на архивиране и изчистване на дневника. Контролните пунктове изчисляват размера на работата, необходима за възстановяване на базата данни.
точка на контрол се настройва автоматично, когато един от следните условия.
Когато изявлението базата данни ALTER да промените някои параметър на базата данни.
Когато сървърът се изключи.
Когато броят на записи в регистъра надхвърлят очакваните размера на работата, посочен в опциите за конфигуриране на сървъра интервалните възстановяване.
Ако базата данни е инсталиран прост модел за възстановяване или режим на компресия и регистър на транзакциите е изпълнен на 70%.
Контролни точки също могат да бъдат инициирани ръчно от контролно-пропускателен пункт команда. При инсталиране на контролната точка, следното действия.
регистър на транзакциите е маркирана зона контролно-пропускателен пункт.
Дневникът записва монтирането на контролния пункт, съдържащ следното:
• най-старият действащ сделката;
• най-старата сделката, която все още не е повторен в транзакциите репликация;
• списък на всички активни операции;
• информация за размера на работата, необходима за намаление на цените на базата данни.
Записани на диска, изпълнен с всички страници с данни и дневника
По същество, на контролния пункт тегли чертата че при сегашното състояние на базата данни, а след това пише за състоянието на разделителната линия между активна и неактивна част от дневника
Backup регистър на транзакциите
Изпълнение на резервната регистър на транзакциите не се различава от пълната или архивиране диференциал. Има няколко съществени различия.
T-SQL инструкция е както следва:
BACKUP LOG SNA2
На диска = 'E: \ Cha2Backup.bak "
Следният резултат се получава:
Преработен 1 страници за база данни 1 CHA2 1. Файлът "CHA2_log" на файла 9.
BACKUP LOG успешно обработена 1 страници в 0.060 секунди (0.042 MB / сек).
Когато направите резервно копие на регистъра на операциите използва същите параметри, които се използват, когато архивиране на базата данни. Но налице и две допълнителни опции, които имат смисъл само за дневник архива на сделката. no_truncate вариант е да архивирате регистъра на операциите по време на операцията по оползотворяване; norecovery / готовност вариант е да се изпълнява на окачен архивиране сървър. И двете от тези параметри, ние разгледаме по-подробно в раздела "Възстановяване на използване на софтуер T-SQL код."
регистър на операциите, не могат да бъдат запазени, ако някое от следните условия.
Базата данни използва прост модел за възстановяване.
Моделът възстановяване на базата данни се използва за групово влезли, маса операция, и файлове с бази данни е приложена са били повредени.
файлове с бази данни са добавени или изтрити.
Във всеки от тези случаи, трябва да се извърши пълно резервно копие на базата данни.
Свиване на лога
Актуализира и изтрива операции, които не могат да увеличат размера на файла с данни. В същото време данните се добавят всеки операция в регистъра на операциите. регистър на операциите, продължава да се увеличава с всяка операция модификация на данните.
Решението на този проблем е да се върне към неактивната част от списанието и неговото последващо отстраняване. По подразбиране, дневник архива на сделката ще доведе до автоматично отрязване (т.е. компресия) (виж. Фиг. 36.3).
Ако, например, че дискът е пълен, дневник съкращаването на сделката може да изискват от излишни данни. Въпреки това, няма начин на дневник компресия без резервно копие. В същото време, T-SQL езика осигурява опция в лога на отрязване на помощта на Backup команда. NoLog или Backup. TruncateOnly (тези команди са взаимозаменяеми):
BACKUP LOG SNA2
Ако регистър на транзакциите е съкратено с ръка, а след това резервно копие му е създаден Внимание! копие, а след пропуск в последователността на сделката. Всяка последователност от операции, които са след тази разлика не може да бъде възстановен. За да започне отново да се създаде поредица от регистър на операциите на резервни копия, се препоръчва да се извърши пълно резервно копие на базата данни.
регистър на операциите и прост модел
Когато база данни се използва прост модел за възстановяване, регистър на операциите, гарантира, че всички извършени транзакции ще бъдат записани във файла с данни. Когато регистър на транзакциите е изпълнен на 70%, SQL Server поставя точка на прекъсване, а след това отрязва дневника. В този случай, размерът на свободно пространство за журнали ще се колебаят, но минимума е с размерите на активната му част.