Как настроить Raid контроллер Dell Perc H965i front?

Ava256, пробовал, также переключал режим с ACHI на Raid, там подключается второй встроенный контроллер и на нем диски видны и нормально настраиваются, почему не работает интегрированный не пойму...

В чем может быть ошибка в логах по ОЗУ на сервере?

Коллеги, спасибо всем за участие! Проблему решили, не было времени отписаться, в общем это был умиравший RAID контроллер.. ошибок по IDRACK, что самое странное не было, а при включении было уведомление UEFI о некорректно установленном драйвере. Менялв слепую, исключив уже все перебранные варианты) попал так сказать в точку. Надеюсь, что кому-нибудь пригодится

В чем может быть ошибка в логах по ОЗУ на сервере?

hint000, мем тест - да) 8гб за 2:40 откатал.. будем ставить по 64гб за одно тестирование, посмотрим, что нагоняет, если все тщетно будет и тесты пройдут успешно, то в эту русскую рулетку я проиграл :D

В чем может быть ошибка в логах по ОЗУ на сервере?

hint000, ну вот на выходных каждые 1.5-2 часа он улетал ребут, ночью перенесли базу на резервный - с 23:00 работает без отключений.. как объяснить не знаю.. Причем народ на выхах также активно работал, как и сейчас.. Программисты тестовые базы максимально грузят, 8 хугалтерских и 8 зуповский конфигураций активно используются, ошибок никакх нет..

Как только вернем основнуб БД обратно, сразу же через 2 часа улетает

В чем может быть ошибка в логах по ОЗУ на сервере?

Zettabyte, парадокс, что я убираю основную базу на резервный сервак - и это чудо живет по нескольку дней (хотя тестовые базы, с такой же конфигурацией, что и основная, причем их 4 штуки работают стабильно с такой же нагрузкой), не могу зависимость уловить, но возможно простое совпадение, поэтому аппаратную часть не беру в расчет, тем более тесты внутренней утилитой проходили и ничего не было выявлено. Последняя софтовая история запланирована на полный снос оси и разворачиванием новых виртуалок. Если после нее будет вылетать, то почетно назову его

Гагарин

и отдам железячникам на полную диагностику, пусть исследуют плату, контроллер и сопутствующие устройства..

В чем может быть ошибка в логах по ОЗУ на сервере?

Zettabyte, накатили боевую бд обратно, сервер был включен, но резко перестал реагировать на команды - через rdp не впускал пользователей, просто черный экран. Через idrack на команду ctrl alt del пытался открыть окно авторизации, но не смог... Пришлось ребутать, ошибок никаких по логам не было, спустя 20 минут работы ребутнулся сам с 41 ошибкой, с тех пор работает 3 часа. Аномалия на аномалии... напрашивается снос всей системы и установка заново, чтобы ее исключить... sfc /scannow ошибок не обнаружила, но что-то подсказывает, что они есть

В чем может быть ошибка в логах по ОЗУ на сервере?

Правильно я понимаю, что нагрузка не сервер закончилась, и в нерабочие часы снова ошибка?

На основную БД с наибольшим объемом - закончилась, но БД 1С конфигураций Бухгалтерия и ЗУП (общее количество 16 БД) в данное время как раз очень активно использовались.
Питание стоит по схеме a/b, режимов энергосбережения ни в биосе, ни в windows включено не было. Просто до удаления базы с диска и его форматирования ошибка сыпалась с периодичностью 5-15 минут, а сейчас 1 раз за сутки работы

В чем может быть ошибка в логах по ОЗУ на сервере?

Zettabyte, собственно, пока был неработоспособен боевой сервер, раскидали всех на резервы и тестили разными способами, ошибка сыпалась, сервер уходил в ребут, пока основная база данных не ушла в режим подозрительная, далее сервер 4 дня работал без ребутов, но ошибка все равно отстреливала в логах, я начал искать другие теории, потому что, если бы память была битой - он бы уже ушел в себя, нагрузку с него не снимали, дополнительные БД так и продолжали крутиться.

И тут я на 4й день думаю, а не нагрузить ли его основной БД и восстановить ее из бекапа. На 20% восстановления все рухнуло, после 4 суток работы. Я полностью удалил эту БД из SQL, форматировал диск, создал новую БД и накатил на нее бекап, все это время не было ни одной ошибки из первого поста.. В ночь запустил тестирование и исправление БД, тоже прошло, в 8:25 утра выскочила

A corrected hardware error has occurred.

Component: Memory
Error Source: Corrected Machine Check
Error Type: Single-Bit ECC

The details view of this entry contains further information.

И пока не появлялось.. я думаю, ребут вызывается либо из-за ошибок по диску, хотя тестирование не выявило ничего, либо некорректной работой самой виртуалки, но пока все работает как часы. Планирую ночью с резервов перевести все на боевую машину и еще раз запуститься.

В чем может быть ошибка в логах по ОЗУ на сервере?

Zettabyte,

А с накопителями-то всё нормально?
Если что, для проверки у нас есть вот такая программа. Но она для запуска в host OS, откуда видны физические диски.

А она работает в обход рейд контроллера? По-моему, там так не выйдет... запустил прогу проверить - вместо дисков отображается котроллер

В чем может быть ошибка в логах по ОЗУ на сервере?

Игорь, не работает( даже поддержка на связь не выходит, как ранее можно было удаленно проконсультироваться со знанием ломанного английского и диктофоном. Сегодня стартуем ночью тестировать с другой памятью, а эту на другой машине запускать по одной-две планки мем тестом.. Я еще думал в сторону софта, виртуалка с Hyper-V же отправляла в ребут всю машину, может еще где-то что-то поврежденное из папок, но она должна активно использоваться для записи - либо темпы, либо кеши, либо скулевские файлы, может сталкивался кто - какие на какие папки попадали?) если нет, то делюсь опытом

В чем может быть ошибка в логах по ОЗУ на сервере?

Память установлена с поддержкой ECC одного производителя - маркировка Dell, но сам завод как понимаем не Dell, сторонних производителей не рассатривали при сборке. С сервером ничего не делали, кроме физического обслуживания, но накануне сбоев никаких работ не проводилось, поэтому ошибки конфига маловероятны, на всякий случай проверим, будем гонять память memtest'ом на другой машине.. Уже просто варианты закончились, если честно... До этого были похожие симптомы, тоже уходил в ребут непредсказуемо, но тогда на одной из машин Hyper-V была повреждена папка Temp пользователя, под которым запущен сервер 1С предприятия и он при попытке записать в эту папку угонял в ребут весь Host.. сейчас все папки целые, проверяли, думали может в этой проблема повторилась..