|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Sergey Pratch 2:5020/400 03 Mar 2001 13:32:33
To : All
Subject : Re: MS SQL 2000
--------------------------------------------------------------------------------
Hi!
"Andrey" <Andrey@p5.f13.n5083.z2.fidonet.org> сообщил/сообщила в новостях
следующее: news:2847538896@p5.f13.n5083.z2.ftn...
> TT> По поводу MSSQL7 и выше - практически 100% - все падения -
> TT> это либо кривые руки, либо кривое железо.
> Hормальный SQL сервер должен работать безглючно как при криворуком
сисадмине
> так и на кривом железе. Hа то он и SQL сервер, я допускаю сбой в системе
по
> причине криворукости сисадмина только в том случае если же сбой произошол
> по причине удаления базы данных или же таблицы из интерпрайзера,во всех
> остальных случаях кривым является сервер. А кривость железа должна
> локализовыватся на уровне операционной системы,причем так же без особого
> участия систадмина. Так как даже у самого прямого железа есть вероятность
> в один прикрасный момент стать кривым. Поэтому в расчете относительной
Это как, типа "1 from 1 bad CPU detected, OS jumped to emulated CPU
mode...". Или она должна замещать "битые" столбцы в DIMMах за счет кэша
процессора? А что делать ОС если, "мудрый" сисадмин посадил на ISA-шину
сервера звуковуху, личного производства, которая упорно "закорачивает шину
PCI?
> глючности MS SQL 2000 криворукость сисадмина и кривость железа учитывать
> не будем вообще. Так как эти величины весьма постоянны для всех SQL
серверов
> и для всех операционных систем.Поэтому,что бы получить результаты в
чистом
> виде будем просто считать количество потерянных гигабайт, и количество
> фатальных сбоев на фиксированном промежутке времени. Хотя утерянные
гигабайты
> считать то же как то не очень справедливо,потому как падение одного
> терабайтного сервера под Oracle 8i запросто может заменить ежедневное
падение
> 10000 бухгалтерских базенок под MS SQL 2000.
Оно то правильно и такая математика вполне уместна, вот только что
прикажите называть падением. И уж слишком это "по-русски" (вспомни слова
Сталина об одном убитом и миллионах погибших). Если сисадмин, с
форсированным драйвером CurveHands, закрутил память серверу до 4 метров, то
тяжело отличить такую ситуацию от настоящего падения (GPF и аналогичное),
особенно с точки зрения пользователя.
Hу а если по взрослому, то как раз в описаной ситуаци, падение 1 Oracle
на терабайтной БД не так уж и страшно, так как никто ему ее в одиночку
обслуживать не позволит, пусть даже он и Oracle. Такие БД обслуживают
кластеры, да еще и распределяют их по целой сети кластеров. Поэтому факт
падения может быть вполне обнаружен не так уж и скоро, от нескольких минут
до нескольких часов. В зависисмости от того, с какой частотой происходит
сбор статистики командой, которая эту БД обслуживает. Для твоего примера
будет означать, что общий прстой БД будет составлять не более нескольких
секунд, за счет времени, пока востановленый кластер войдет в круг своих
обязанностей. Реально же это вообще будет просто увеличение задержки при
выполнении некоторых запросов.
А вот отказ 10000 MSSQL, это в серднем DoS-state более чем 100 000
клиентов. А если учесть, чо каждый такой клиент обеспечивает работу (т.е.
право на хлеб насущный) где-то 2-5 человек, то ситуация не такая уж и
безболезнення. По масшатабам Европы это означает, что такая страна, как
Венгрия ежедневно подвергается стихиному бедствию, типа землетрясения. И в
этой ситуации пора подумат, а не Hаздратенко у них генерал-губернатор?
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: Solver Ltd. site #2 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
