|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Tengiz Kharatishvili 2:5020/400 07 Mar 2001 07:03:15
To : All
Subject : Re: безопасность превыше всего?
--------------------------------------------------------------------------------
"Lilya A. Kozlenko" <Lilya.A.Kozlenko@f17.n5025.z2.fidonet.org> wrote in
message news:4274107340@mail.relex.ru...
> Зеркалировать критичные для работы файлы есть хороший тон. Тут пример
> оракловых redo, control уже приводили. Это есть правильно поведение. Одно
> другому не мешает.
> ...
> Это "идиотское" дело может, например, называться raw :).
> Oracle и DB2 их любят... Hу а MS ... Всякое бывает в этой жизни.
>
Конечно, приятно иметь такую возможность, однако, отсутствие оной почти
полностью компенсируется предоставляемыми операционной системой и
современной аппаратурой сервисами и следованием несложным административным
процедурам. Однако, не сомневаюсь, что если это будет нужно, данную
возможность легко можно будет вернуть в MS SQL Server. Хотя, не стоит
забывать, что для SQL Server не существует проблемы работать на всём,
включая кирогаз, поэтому и нет дублирования кода OC для таких случаев. То же
относится и к RAW partitions. Отсюда и несколько отличная философия продукта
и несколько иное представление о "правильности".
> Hу это можно только если сервер баз данных в этот момент остановлен, а то
> заберешь (если тебе конечно позволят это сделать с открытым файлом)
> неизвестно что. Есть такие вещи, как кэш, отложенная запись, и далеко не
> ...
> А если говорить об неинкрементном бэкапе предоставляемым самим сервером,
то
> по хорошему просто должен бэкакп предоставлять разбивку на тома (если уж
ты
> много выгружаешь и нужно резать на кусочки), а в этом случае глубоко
> фиолетово выгружать ли базу, табличное пространство, схему, таблицу и т.п.
В
> этом случае СУБД обязана сама разбираться с физическим размещением данных
> самостоятельно.
> ...
> Hикто не спорит, живые файлы базы бэкапить легче/быстрее, но только,
> извините, не при запущенной СУБД :).
>
Разбивка backup на тома - это базовая функция, и я даже не знаю, какой из
нормальных серверов БД этого не умеет. Hо, бывает совсем не "фиолетово",
когда у Вас рухнет одно из ста устройств и вместо того, чтобы адресно,
средствами самой СУБД восстанавливать только его, Вам приходится делать full
restore.
Если же, речь идёт о SQL Server, у которого backup в чистом виде онлайновый,
то эти проблемы там давно решены. Поинтересуйтесь, пожалуйста,
документацией, если, конечно, это не очередной confusion. И кеши и lazy
write и checkpointing аккуратно учтены - это не бином Hьютона и, тем более,
не rocket science. Когда делается full backup, то вместе со страницами
данных, которые, естественно, могут и не быть в согласованном друг другом
состоянии, вдогонку пишется соответствующая часть журнала транзакций, так
что при восстановлении происходят все необходимые откаты и накаты. Hе
сомневаюсь, что Вы и без меня знаете, как это происходит - Oracle давно
умеет это делать.
File или filegroup backup в SQL Server тоже полностью онлайновый, и сервер
для этого останавливать на надо. Суть, разумеется, то же самая, как и для
full backup: делается, возможно несогласованная, копия file или filegroup.
Для нормального восстановленя необходима ещё и полная цепочка журналов, что
бы откатить/накатить всё, что было сделано момента начала backup. В отличие
от full backup, в случае которого всё полностью автоматизировано, и нужен
только один файл или набор, file или filegroup backup дело немного более
муторное, но таков уж хлеб администратора. Для действительно большой системы
возможность избирательно и быстро восстанавливать file или filegroup на
одном из повреждённых устройств может оказаться очень полезной, а иногда и
вовсе кричичной, когда каждая минута простоя может стоить больших денег.
См.
http://msdn.microsoft.com/library/psdk/sql/8_ar_aa_20z7.htm
http://support.microsoft.com/support/kb/articles/Q281/1/22.ASP
Cheers.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
