su.dbms.sql

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

 
 "Tengiz Kharatishvili" <tengiz.kharatishvili@gte.net> wrote in message
 news:9848b5$1hef$1@ddt.demos.su...
 
 > > Зеркалировать критичные для работы файлы есть хороший тон. Тут пример
 > > оракловых redo, control уже приводили. Это есть правильно поведение.
 
 Одно
 
 > > другому не мешает.
 > > ...
 > > Это "идиотское" дело может, например, называться raw :).
 > > Oracle и DB2 их любят... Hу а MS ... Всякое бывает в этой жизни.
 > Конечно, приятно иметь такую возможность, однако, отсутствие оной почти
 > полностью компенсируется предоставляемыми операционной системой и
 
 Так никто не мешает СУБД делать так, как ей надо, а не так, как надо
 операционке,
 которая вообще говоря может и не ведать о том, что надо СУБД.
 
 > современной аппаратурой сервисами и следованием несложным административным
 > процедурам. Однако, не сомневаюсь, что если это будет нужно, данную
 > возможность легко можно будет вернуть в MS SQL Server. Хотя, не стоит
 > забывать, что для SQL Server не существует проблемы работать на всём,
 > включая кирогаз, поэтому и нет дублирования кода OC для таких случаев. То
 
 же
 
 Hапример, тот самый кирогаз, а именно NT (на других кирогазах MS SQL пока
 еще
 не умеет :) ), очень сильно любит выкидывать страницы на диск (чтоб его этот
 самый
 своп), причем даже если физически свободно памяти 3/4, а занята только 1/4.
 Hу это
 так, лирика. А вообще говоря, мне про кирогаз понравилось :).
 
 > относится и к RAW partitions. Отсюда и несколько отличная философия
 
 продукта
 
 > и несколько иное представление о "правильности".
 
 Hу ... философию я устойчиво нелюблю :).
 
 > Разбивка backup на тома - это базовая функция, и я даже не знаю, какой из
 > нормальных серверов БД этого не умеет. Hо, бывает совсем не "фиолетово",
 > когда у Вас рухнет одно из ста устройств и вместо того, чтобы адресно,
 > средствами самой СУБД восстанавливать только его, Вам приходится делать
 
 full
 
 > restore.
 
 Hу дык это... предохраняться надо. К-во наворотов прямо пропорционально
 ценности
 данных, которые бэкапятся.
 
 > Если же, речь идёт о SQL Server, у которого backup в чистом виде
 
 онлайновый,
 
 > то эти проблемы там давно решены. Поинтересуйтесь, пожалуйста,
 
 Кажется разобиделся...
 
 > документацией, если, конечно, это не очередной confusion. И кеши и lazy
 > write и checkpointing аккуратно учтены - это не бином Hьютона и, тем
 
 более,
 
 > не rocket science. Когда делается full backup, то вместе со страницами
 > данных, которые, естественно, могут и не быть в согласованном друг другом
 > состоянии, вдогонку пишется соответствующая часть журнала транзакций, так
 > что при восстановлении происходят все необходимые откаты и накаты. Hе
 > сомневаюсь, что Вы и без меня знаете, как это происходит - Oracle давно
 > умеет это делать.
 
 Я разве утверждала, что MS SQL настолько некультурный, что бэкап происзводит
 без учета журнала транзакций? Или может быть тоже самое утверждала про
 оракла?
 
 > File или filegroup backup в SQL Server тоже полностью онлайновый, и сервер
 
 Сказано же было, что у нормальной СУБД поставляемое с нею средство бэкапа
 просто обязано все это уметь. Hу и зачем мне повторять, как крут в твоем
 понимании
 MS? Документацию я и сама читать умею :).
 То, что ты написал не есть великое достижение, это есть нормальный набор
 средств
 бэкапа, без которых как бы это сказать, несколько тяжеловато говорить о
 сохранности
 данных в случае чего нехорошего.
 
 --
  Regards, Lilya Kozlenko
 --- Microsoft Outlook Express 5.50.4522.1200
  * Origin: RELEX Inc. (2:5025/17@fidonet)
 
 

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