|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Tengiz Kharatishvili 2:5020/400 06 Mar 2001 02:27:04
To : All
Subject : Re: MS SQL 2000
--------------------------------------------------------------------------------
"Andrey" <Andrey@p5.f13.n5083.z2.fidonet.org> wrote in message
news:2856603010@p5.f13.n5083.z2.ftn...
> Tengiz Kharatishvili wrote in a message to All:
> TK> Это какую такую "принципиальную неверную" систему ведения
> TK> журнала оставили в MS SQL Server? Очень интересно, что Вы
> TK> имеете в виду.
> Да ту которая не позволяет вести логгирование каждой закоммиченной
> транзакции и назначать мирроры на лог журналы. То есть MS-SQL фактически
> ведет лог журнал в той же самой базе данных что и сами данные,и лишь
> периодически скидывает логжурнал в бакуп файлы. Крах системы между
бакупами
> ...
> противном случае ты обязательно потеряешь данные. Естественно что никто не
> делает бакупы каждую секунду поэтому какая то часть информации неизбежно
будет
> потерянна.Вот это и есть принципиальное неверная организация системы
> логгирования.
>
Видимо, Вам нужно освежить в памяти Ваши сведения о MS SQL Server, в том
числе и о старых версиях тоже, и, в частности, то, как ведётся журнал
транзакций. Принципиальная возможность расположить данные и журнал в одном
файле в старых версиях не означает принципильной невозможности сделать это
иначе, не правда ли?
Для MS SQL Server 7 и выше - вообще остутствует возможность иметь данные и
журнал в одном файле и обязанность по организации зеркалирования возложена
на операционную систему - Windows NT. А с появлением SAN (Storage Area
Networks) зеркалирование на уровне СУБД и даже на уровне операционной
системы вообще может стать анахронизмом.
Кроме того, наличием заркального журнала можно воспользоваться только при
разумной организации резервного копирования. В документации MS по
планированию и организации данных / журналов / дисковых устройств для
обеспечения высокой готовности, рекомендуется буквально следующее:
1. Разнести данные и журналы на физически разные устройства.
2. Разместить хотя бы журналы на устройствах с зеркалированием (для 6.5 и
ниже был также возможен было вариант зеркалированя на уровне database
engine).
3. Расположить системные базы данных с журналами (кроме tempdb - это
отдельная история) на отдельном устройстве с зеркалированием.
4. Есть подробнейшие рекомендации по стратегии и технике резервного
копирования сводящие к минимуму вероятность каких либо потерь данных.
При отказе устройств с данными и одного из журналов делается backup log с
живого журнала и, соответственно, не теряется вообще ничего кроме времени -
восстанавливаются данные, затем накатываются журналы транзакций, включая,
естественно, самый последний, взятый после отказа устройства с данными.
Отказ всех устройств - катастрофическое событие, при котором потери данных
неизбежны для любого сервера. При тупом следовании несложным (но таким
скучным, я понимаю) рекомендациям по организации резеврного копирования
теряется только то, что произошло после последнего backup log.
Это - элементарные правила, которые неплохо соблюдать, даже при наличии
относительно нежёстких требования к минимизации возможных потерь. Hикто не
делает из этого тайны и всё это описано в документации и White Papers. Для
сколько нибудь серьёзных приложений не разместить журнал транзакций на
устройстве с зеркалированием - вообще дурной тон.
См.
http://www.microsoft.com/technet/showcase/itops/availsql.asp
http://msdn.microsoft.com/library/psdk/sql/ad_bkprst_63eh.htm
http://msdn.microsoft.com/library/techart/msdn_sql7perftune.htm#sql7perftune
_diskperform
А также см. статью от BMC Software - Recovery: An Enterprise-Class Plan for
Securing Microsoft SQL Server Databases:
http://www.bmc.com/products/whitepaper.html
Cheers.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
