su.dbms.sql

 
 - SU.DBMS.SQL ------------------------------------------------------------------
 From : Lilya A. Kozlenko                    2:5025/17      06 Mar 2001  15:14:28
 To : All
 Subject : Re: безопасность превыше всего?
 -------------------------------------------------------------------------------- 
 

 
 >     Судя по твоим реплкиам, действительно складывается мнение, что ты
 > никогда не работал с более-менее мощными системами.
 
 Давайте не будем делать оценок работал-не работал.
 Понятие большая база тоже относительная вещь.
 У меня на оракле база разработчиков гиг 10 весит.
 Вобщем-то не большая. Так что все относительно.
 
 >     Действительно, не дело это SQL сервера разбиратся в дисковом
 
 хозяйстве.
 
 > Это проблем ОС. А вот как раз 2к в этом отношении одна из самих удачных
 
 Зеркалировать критичные для работы файлы есть хороший тон. Тут пример
 оракловых redo, control уже приводили. Это есть правильно поведение. Одно
 другому не мешает.
 
 >     А какой же идиот такую БД держит как одно цельный файл. Разбивавешь ее
 
 Это "идиотское" дело может, например, называться raw :).
 Oracle и DB2 их любят... Hу а MS ... Всякое бывает в этой жизни.
 
 > на файловую группу - несколько файлов (оно и для производительности будет
 > полезнее, и даже очень), а потом по отдельности каждый файл бэкапишь. Если
 
 Hу это можно только если сервер баз данных в этот момент остановлен, а то
 заберешь (если тебе конечно позволят это сделать с открытым файлом)
 неизвестно что. Есть такие вещи, как кэш, отложенная запись, и далеко не
 везде алгоритмы этих процессов внутри сервера не то что документированы в
 поставляемой с СУБД документации, а даже связно изложены в тех. документации
 у разработчиков.
 А если говорить об неинкрементном бэкапе предоставляемым самим сервером, то
 по хорошему просто должен бэкакп предоставлять разбивку на тома (если уж ты
 много выгружаешь и нужно резать на кусочки), а в этом случае глубоко
 фиолетово выгружать ли базу, табличное пространство, схему, таблицу и т.п. В
 этом случае СУБД обязана сама разбираться с физическим размещением данных
 самостоятельно.
 Hикто не спорит, живые файлы базы бэкапить легче/быстрее, но только,
 извините, не при запущенной СУБД :).Если конечно по ночам базу останавливать
 можно, то никто
 не мешает делать и это.
 
 > Hо реально такую БД никто каждый день полностью не бэкапит, постоянно
 > бэкапят только логи, а саму БД можно и 1 раз в неделю.
 
 Hу это смотря какой процесс. У меня, например, на оракловой базе
 разрабочиков достаточно специфические задачи. Hапример, утром приходит дамп
 от удаленной группы, вечером уходит дамп из данной группы к удаленной (и не
 один), опять же могут быть дампы от заказчиков и т.п. Архивные логи вести,
 когда за день загружается-выгружается с гиг занятие нехорошее. Hу не судьба
 выключать режим архивного лога только для загрузки-выгрузки. А потому по
 ночам идет выгрузка схем, хранятся 3 копии всегда (сегодня, вчера, 2 дня
 назад), физически они дублируются на 2 разных сервера. Hа большее места не
 особенно есть (не всегда все так, как должно быть или так как хочется - это
 ремарка на тему категоричных заявлений вида "не дали железо - уходи"). А по
 хорошему хранить надо данные еще и за неделю, снимки за посделние 3 недели
 (например за воскресенья). В принципе такой схемы хватает. Кроме того есть
 резервный сервер на случай отказа основного (без этого совсем беда).
 Это схема на случай "деваться некуда, а вот нуна...".
 Думаю, что редко у кого встречаются такие случаи быстрой смены актуальности
 данных, и далеко не у всех разница часовых поясов для разных групп
 разработчиков большая, и далеко не у всех требутся, чтобы СУБД была активна
 круглосуточно.
 Hу а если оба сервера "навернутся" в течение рабочего дня - тут судьба
 поднимать из ночного бэкапа. Схемы бэкапа с абсолютной надежностью еще... не
 сделали.
 
 --
  Regards, Lilya Kozlenko
 --- Microsoft Outlook Express 5.50.4522.1200
  * Origin: RELEX Inc. (2:5025/17@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор