IDE hdd vs SCSI RAID

[alex_z]

Хочу задать вопрос. Унас есть база (система начисления платежей) на SQL 6.5. Сама база и лог лежат на RAID 5 (Adaptec 2100s), все остальное на 1 IDE HDD. В последнее время замучили проблемы с RAID (3 раза за два месяца  вылетали диски и все чаще и чаще). Разработчик ПО говорит: "выкинте все рейды и скази поставте два IDE винта под базу и под лог и все будет в 4 раза быстрее". Мы с начала не поверили, но вчера кончились SCSI пришлось перенести и лог и базу на второй IDE HDD в разные разделы (на MB только 1 IDE канал). И что самое интересное никаких тормозов не наблюдается, вроде бы даже быстрее.
КАК ЭТО ОБЬЯСНИТЬ.
И Зачем тогда RAID.

[exLH]

Болел зуб, не смогли определить какой именно, поэтому вырвали все. Теперь ем протертую кашку и пью молоко через трубочку. Никаких проблем, вроде даже вкуснее и нет затрат на зубную пасту. Почему все так не делают?
А если по сути: что будете делать, если диск помрет? "Привет" клиентам и их платежам?
Вы ошибались, если Вам казалось, что RAID5 на таком старом контроллере будет супер быстрым. RAID всегда служит для обеспечения отказоустойчивости  (кроме RAID0, но это отдельная история), а уже потом и иногда для увеличения скорости. Вот если бы у Вас там был RAID10, а не RAID5, тогда скорость была бы повыше. А если у Вас проблемы с RAID (разваливается, диски выпадают), то это не просто так и надо их решать, потому как проблемы (например со SCSI шиной) могут и на производительность дисковой подсистемы влиять неслабо.
Разработчики могут советовать что угодно - у них все базы тестовые. Умер диск - поменяли на другой, сгенерировали тестовые данные и вперед, на баррикады.

[Stranger03]

Разработчик ПО говорит: "выкинте все рейды и скази поставте два IDE винта под базу и под лог и все будет в 4 раза быстрее".

Мда, а что вы будете делать, если один из винтов умрет? Бежать к разработчикам и молить их о пощаде? Или крыть матом и заново набивать базу?
То, что у вас Раид5 SCSI оказался медленнее чем одиночный IDE лишь следствие каких-то проблем с контроллером, шиной или жесткими дисками. Ни один даже самый навороченный IDE диск на сервере не в состоянии обеспечить нужной производительности при интенсивных операциях чтения и записи, когда сетевых клиентов больше 10-ка. Ну а про надежность и говорить не приходится.

[gs]

Я немного общался с тем контроллером. Но сколько общался - столько матюгался. УЖАСНО медленный и капризный (как раз массив у меня не раз разваливался).
А с теми, кто советует, Вы заключите договор о мат ответственности при сбоях - они сразу передумают

[Stranger03]

Я немного общался с тем контроллером. Но сколько общался - столько матюгался. УЖАСНО медленный и капризный (как раз массив у меня не раз разваливался).

У меня как-то тоже с этим контроллером был бурный и продолжительный секс. Хорошо всю базу ексченжа сохранил перед манипуляциями, . Часа в два ночи все восстановил, а контроллер на полку положил, .

[alex_z]

Спасибо всем за помощь.
Обнаружилось что история не закончилась.
После переноса базы на IDE диск (через пол дня) в логе приложений ОС появилось следующее:
Error : 605, Severity: 21, State: 1
Attempt to fetch logical page 15904 in database '*****' belongs to object  '0', not to object 'sysprocedures'.
До переноса аналогичные сообщения были о пользовательских таблицах, их удалили и создали заново.
Меня интересует такой вопрос могла ли эта ошибка остаться в базе после глюков с RAID или база продолжает разваливаться.
И вообще связаны эти ошибки с глюками или нет. Появились они после очередного вылета диска.

[a_shats]

Битая страница - стандартная проблема большинства SQL. И лечится, afaik, стандартно же.

Three potential related database scenarios are:

You experience media failure that affects one or more of the databases, but the transaction log(s) are not damaged. You want to recover to current time.


One or more transaction logs are destroyed. You need to restore the set of databases to a consistent state at the time of your last log backup.


You need to restore the entire set of databases to a mutually consistent state at some earlier point in time.
In all three of these cases, you must be using the Full Recovery model for these databases. For more information, see Full Recovery.

И вот чем быстрее Вы это сделаете, тем меньше будет "битых" ссылок на битые страницы.

[Vadik]

Битая страница - стандартная проблема большинства SQL. И лечится, afaik, стандартно же.

Стандартная проблема сиквела на битом (глючном) оборудовании Проблема в железе, и никакая Recovery model тут не поможет. Если уж отсылать к BOL, то лучше например сделать поиск по torn page, хотя и torn page detection при регулярно разваливающемся массиве не спасет, а лишь раньше укажет наличие проблем

Начинайте с полного бэкапа, далее

dbcc checkdb with physical_only

если ошибки найдутся (а даже если и не найдутся)

dbcc checkdb

при наличии ошибок -

dbcc checkdb repair_fast
dbcc checkdb repair_rebuild,
dbcc checkdb repair_allow_data_loss

(опции отсортированы по степени "запущенности" ситуации)

И либо почините массив, либо выкиньте его на помойку

[a_shats]

Vadik
Ага. Т.е. Вы считаете, что битые страницы бывают исключительно по вине железа ? Я Вас разочарую - отнюдь нет. Причем, как я уже и писал выше, эта проблема бывает не только на MSSQL - и на Oracle, и на IB, и т.д. и т.п. Решается везде - или имеющимися средствами типа тех, что вы привели, или - надежнее всего (имхо) - именно тем методом, что привел я

[Vadik]

Ага. Т.е. Вы считаете, что битые страницы бывают исключительно по вине железа ?

"Исключительно" - не мои слова. Я бы сказал - "в основном".

Я Вас разочарую - отнюдь нет.

Ну, не то чтобы я сильно по этому поводу расстраивался

Причем, как я уже и писал выше, эта проблема бывает не только на MSSQL - и на Oracle, и на IB, и т.д. и т.п. Решается везде - или имеющимися средствами типа тех, что вы привели, или - надежнее всего (имхо) - именно тем методом, что привел я

Честно говоря, либо я в Вашей цитате метода не разглядел, либо чего-то не понимаю. Как Full recovery поможет исправить существующие ошибки или предотвратить возникновение новых?

[a_shats]

Будем цитировать ? ОК:

Стандартная проблема сиквела на битом (глючном) оборудовании

Чье ?

Как Full recovery поможет исправить существующие ошибки или предотвратить возникновение новых?

"Правильный" бэкап попросту не может читать битые страницы и  ссылки на них, в файл бэкапа в итоге оне и не попадут. В результате восстановления базы "с нуля" из такого бэкапа битых страниц и ссылок на них попросту не будет. Это - в общем - наипростейшем- случае, понятно

[Vadik]

Чье ?

Мое

Вы считаете, что битые страницы бывают исключительно по вине железа ?

Я этого никогда не говорил. Да, я по-прежнему утверждаю, что добиться того, что было описано пострадавшим, не в пример легче на битом оборудовании (в данном случае - массив), чем манипуляциями с софтом или ошибками в нем.

По поводу правильного бэкапа - попробуйте уже что ли