 |
|
|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Andrey 2:5083/13.5 27 Feb 2001 17:36:58 To : Tolik Tentser Subject : MS SQL 2000 -------------------------------------------------------------------------------- Hi! Tolik > Hормальный SQL сервер должен работать безглючно как при криворуком > сисадмине так и на кривом железе. > Hа то он и SQL сервер, я допускаю сбой в системе по > причине криворукости сисадмина только в том случае если же сбой произошол > по причине удаления базы данных или же таблицы из интерпрайзера,во всех > остальных случаях кривым является сервер. TT> Hу тогда отведи ему памяти меньше чем надо Hормальный SQL сервер сам должен рассчитывать минимальный объем требуемой памяти это как минимум, а как максимум использовать всю свободную,и уж во всяком случае и игнорировать ошибочно введенные значения способные привести к сбою. И уж во всяком случае с параметрами устанавливаемыми по умолчанию сабж никак не должен падать. TT> Или не выдели места в БД для данных Hормальный сервер при возникновении такой ситуатции должен просто откатывать транзакцию по ошибке недостатка дисковой памяти и все,ни к какому сбою подобная ситуатция приводить не должна. В лучшем случае база перейдет в режим только чтения и все. TT> Это не к сбою приведет ? Hет это должно приводить всего лишь к выдаче сообщения о невозможности выполнения данной операции,но ни к каким сбоям данная ситуатция приводить не должна. > А кривость железа должна локализовыватся на уровне > операционной системы,причем так же без особого участия > систадмина. TT> =8-() TT> Каким образом на уровне ОС предлагается локализовывать TT> перегрев процессора на дрянной китайской плате без TT> термометра ? Дрянные китайские платы как правило не используют под сервера,а нормальная операционнная система должна выполнять как минимум два одинаковых процесса в памяти и постоянно сверять результаты их работы, это немножко дольше зато в 1000 раз надежнее, тут даже перегрев китайской плата может быть успешно отловлен. Более того уважающие себя операционные системы должны на этот случай иметь встроенные тестовые программы способные локализовывать сбо вплоть до машинной команды. То есть в результате должна выдатся ошибка типа "рассогласование синхронных процессов в памяти по причине нерпавильного расчета смещения условного перехода замените чип N 1 центрального процессора". Только вот сабж на MSSQL 2000 на таких операционных системах не работает, а WIN 2000 до подобного уровня обеспечения надежности и безопастности еще пилить и пилить. >Так как даже у самого прямого железа есть вероятность > в один прикрасный момент стать кривым. Поэтому в расчете относительной > глючности MS SQL 2000 криворукость сисадмина и кривость железа учитывать > не будем вообще. Так как эти величины весьма постоянны для всех SQL > серверов и для всех операционных систем. TT> Ты в этом правда так уверен ? В среднем да. > Поэтому,что бы получить результаты в чистом > виде будем просто считать количество потерянных гигабайт, и количество > фатальных сбоев на фиксированном промежутке времени. Хотя утерянные TT> гигабайты > считать то же как то не очень справедливо,потому как падение одного > терабайтного сервера под Oracle 8i запросто может заменить ежедневное TT> падение > 10000 бухгалтерских базенок под MS SQL 2000. TT> Я одного не понял - ты к чему это все ? Статистикас-с-с-с. Андрей --- * Origin: (2:5083/13.5) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/2764a9c23830.html, оценка из 5, голосов 10
|
|
|