IDE hdd vs SCSI RAID

Конфигурирование, планирование RAID систем, возможности, технологии, теория. Qlogic, LSI Logic, Adaptec ...

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
alex_z
Junior member
Сообщения: 4
Зарегистрирован: 06 дек 2004, 21:02
Откуда: Саратов

IDE hdd vs SCSI RAID

Сообщение alex_z » 08 дек 2004, 09:45

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

Аватара пользователя
exLH
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 5061
Зарегистрирован: 11 фев 2004, 15:49
Откуда: Москва
Контактная информация:

Сообщение exLH » 08 дек 2004, 10:09

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

Аватара пользователя
Stranger03
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 12979
Зарегистрирован: 14 ноя 2003, 16:25
Откуда: СПб, Екатеринбург
Контактная информация:

Re: IDE hdd vs SCSI RAID

Сообщение Stranger03 » 08 дек 2004, 10:31

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

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 08 дек 2004, 12:01

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

Аватара пользователя
Stranger03
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 12979
Зарегистрирован: 14 ноя 2003, 16:25
Откуда: СПб, Екатеринбург
Контактная информация:

Сообщение Stranger03 » 08 дек 2004, 15:25

gs писал(а):Я немного общался с тем контроллером. Но сколько общался - столько матюгался. УЖАСНО медленный и капризный (как раз массив у меня не раз разваливался).
У меня как-то тоже с этим контроллером был бурный и продолжительный секс. Хорошо всю базу ексченжа сохранил перед манипуляциями, :twisted:. Часа в два ночи все восстановил, а контроллер на полку положил, :twisted:.

alex_z
Junior member
Сообщения: 4
Зарегистрирован: 06 дек 2004, 21:02
Откуда: Саратов

Сообщение alex_z » 09 дек 2004, 12:32

Спасибо всем за помощь.
Обнаружилось что история не закончилась.
После переноса базы на 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
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 09 дек 2004, 12:50

Битая страница - стандартная проблема большинства SQL. И лечится, afaik, стандартно же.
SQL Server Books Online, Backup and Recovery of Related Databases писал(а): 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
Advanced member
Сообщения: 81
Зарегистрирован: 16 фев 2004, 22:49
Откуда: Moscow
Контактная информация:

Сообщение Vadik » 11 дек 2004, 00:59

a_shats писал(а):Битая страница - стандартная проблема большинства 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
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 14 дек 2004, 12:08

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

Vadik
Advanced member
Сообщения: 81
Зарегистрирован: 16 фев 2004, 22:49
Откуда: Moscow
Контактная информация:

Сообщение Vadik » 14 дек 2004, 12:47

a_shats писал(а): Ага. Т.е. Вы считаете, что битые страницы бывают исключительно по вине железа ?
"Исключительно" - не мои слова. Я бы сказал - "в основном".
a_shats писал(а):Я Вас разочарую - отнюдь нет.
Ну, не то чтобы я сильно по этому поводу расстраивался :)
a_shats писал(а):Причем, как я уже и писал выше, эта проблема бывает не только на MSSQL - и на Oracle, и на IB, и т.д. и т.п. Решается везде - или имеющимися средствами типа тех, что вы привели, или - надежнее всего (имхо) - именно тем методом, что привел я ;)
Честно говоря, либо я в Вашей цитате метода не разглядел, либо чего-то не понимаю. Как Full recovery поможет исправить существующие ошибки или предотвратить возникновение новых?

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 14 дек 2004, 13:13

Будем цитировать ? ОК:
Стандартная проблема сиквела на битом (глючном) оборудовании
Чье ? ;)
Как Full recovery поможет исправить существующие ошибки или предотвратить возникновение новых?
"Правильный" бэкап попросту не может читать битые страницы и  ссылки на них, в файл бэкапа в итоге оне и не попадут. В результате восстановления базы "с нуля" из такого бэкапа битых страниц и ссылок на них попросту не будет. Это - в общем - наипростейшем- случае, понятно ;)

Vadik
Advanced member
Сообщения: 81
Зарегистрирован: 16 фев 2004, 22:49
Откуда: Moscow
Контактная информация:

Сообщение Vadik » 14 дек 2004, 14:12

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

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

:beer:

Ответить

Вернуться в «Массивы - RAID технологии.»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 26 гостей