|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Tengiz Kharatishvili 2:5020/400 09 Mar 2001 07:54:05
To : All
Subject : Re: MS SQL 2000
--------------------------------------------------------------------------------
Андрей,
Искренне восхищаюсь Вашим несгибаемым упорством! No Pasaran!
> Я говорю о принципально неправильном подходе к логгированию,когда
> вместо того что бы просто взять логжурнал с замироренного файла,
> просто синсталлировать по новой SQL сервер,просто восстановить базу
> данных с копии базы и просто применить к ней логжурнал.
Это, вообще говоря, довольно необычная операция, которая требует
искусcтвенной отмены всех записей о контрольных точках и наката/отката всех
изменений с момента последего backup. И формат журнала SQL Server позволяет
это сделать, в конце концов, именно из него и генерится резервная копия
журнала, которя ведь предназначена для того же.
Однако, проблема (разумеется, в принципе, решаемая) здесь в том, что
database backup содержит ещё и порцию журнала транзакций, и при
восстановлении нужно место куда эту порцию предварительно разместить. И это
место, как не трудно догадаться - текущее журнальное устройство, при этом
уцелевший при аварии журнал будет затёрт. Именно поэтому и нужно
предварительно произвести аварийное резервное копирование журнала.
> Причем формат у логжурнала должен быть выбран таким образом, что даже
> какое то повреждение хвоста логфайла не должно мешать загрузке
> предидущих закоммиченных транзакций.
Формат-то, как раз, именно такой и log manager очень даже умеет определять
последнюю корректную запись в журнале. И именно это работает при
автоматическом восстановлении баз при запуске сервера, когда подчищаются
хвосты, оставшиеся от предыдущей остановки и делаются последние checkpoints,
включая, разумеется, и случаи, когда предыдущая остановка сервера была
аварийной. И для этого страницы данных должны быть живы. Что правда, то
правда.
А возможность сделать резервную копию повреждённого журнала, о которой Вы
говорили, вплоть до точки отказа, была бы действительно полезной.
> в лог журнал должны заносится все проведенные операции, включая изменения
> структуры базы даных, текстов хранимых процедур, триггеров и так далее.
>
В отличие от Oracle (именно там и есть разделение на rollback, redo и
control), всё это идёт в один журнал. Читайте документацию - См. ALTER
DATABASE ... SET RECOVERY FULL. Там всё про это написано. Hадеюсь, Вас это
порадует.
> Ты предлагаешь сисадмину заниматся щаманскими
> танцами с бубном вокруг подохшего SQL сервера.Вот это и есть принципиально
> неверный подход потому как последняя выгрузка журнала транзакций из
> логсегмента в бакуп файл производится самим же SQL сервером,то есть
> покойником.:)))
Я не настольно детально разбираюсь в том, как описываемые Вами ситуации
решаются другими DBMS, но сдаётся мне, что того, чего бы Вам хотелось ещё
никто не реализовал настолько прозрачным для пользователся образом.
Администратору в любом случае придётся поработать для устранения аварии.
Пристыдите меня, если это не так, конкретным примером не очень экзотического
коммерческого продукта.
> Hормально продуманная система должна описывать процедуру _полного_
> восстановления базы данных,максимум в пяти пунктах,и быть простой как
> автомат калашникова. А так ты тут на тему "Инструкция по восстановлению
> баз данных под MS-SQL" можешь написать целую поэму, причем для
> каждого конкретного случая она у тебя будет разной.
>
А Вы, часом, не кремлёвский мечтатель? Почитайте многостраничные детальные
инструкции по disaster database recovery, скажем, от Oracle или IBM. Думаю,
будет интересно.
Cheers
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
