John Artur La Diff,

Молодой человек. Представьте, что железо вытягивает любые массивные селекты из БД. Представьте, что база выросла до 1 Тбайт. И представьте, что бэкап делается за приемлимые X часов. И у Вас все кошерно, несколько свежих бэкапов.
А теперь представьте, что база умерла. Глюк в железе - и где-то записался кривой chunk на RAID массиве. Ошибка в драйвере VMware. Такое бывает. И не так редко, как думается.

А теперь бизнес говорит Вам - мы без этой базы жить не можем. Простой не допустим. Восстановить базу из полного бэкапа (просто представим, что бэкапы журнала тоже повреждены, для рестора придется читать весь забэкапленный 1 Тбайт). Чтение быстрое. А вот записывать нужно на RAID-6. За какое время Вы сможете записать этот терабайт на массив? Например, кривые драйвера, кривая прошивка RAID-контроллера, скорость записи какие-нибудь 50 Мбайт/сек, нужно записать 1024*1024 Мбайт, получаем 20970 секунд, это 6 часов. Бизнес сможет остановиться и не работать с этой базой в течение 6 часов , причем обязательно в послеобеденное время, когда нужно продавать покупателям, вносить данные приехавшего товара от поставщиков и так далее?

Если нет - Вы идете к бизнесу и говорите "Нужно брать самые дорогие PCI-X SSD диски емкостью по 1 Тбайт, собирать из них RAID-1 массив из 2 дисков и третий hot-spare и еще рядом такой же массив для бэкапа". Считаете стоимость остановки бизнеса, считаете стоимость железа - и бизнес пусть сам решает.

John Artur La DiffAndy_OLAP, а если мы оставим эти же диски, но соберём RAID-10 будет выигрыш в производительности?
Это большой секрет. И даже коммерческая тайна. Но если Вы воспользуетесь гуглом и наберете "RAID-6 vs RAID-10 performance", то первой же ссылкой будет обсуждение на reddit, где указывается калькулятор производительности RAID-массивов .

А дальше можно поступить двумя способами.

Способ первый - узнать у бизнеса максимальное время простоя базы на момент рестора. И таки плясать от этой информации.

Способ второй - так как шекели уже потрачены, и купленное железо считается кошерным - придется готовить то, что есть. Берете два диска, делаете RAID-0, на массиве записываете oracle базу в 1 Тбайт (100 таблиц по 10 Гбайт, таблицы по 3 столбца - int/float/varchar, если применять терминологию MSSQL, записываете рандомно сгенерированные данные, можно простым скриптом на каком-нибудь python, если на PL/SQL сложно, вставлять порциями по 10 тысяч строк и по 100 тысяч строк, увидите просадки).
Сначала на голом железе, потом на виртуальной машине VMware поверх этого железа.

Далее делаете бэкап куда-то, где он будет в боевых условиях, затем ресторите на массив RAID-10. Записываете время рестора. Затем разваливаете массив, делаете RAID-6 (на томе для данных, не на томе для ОС!) из тех же самых дисков, скармливает точно так же в виртуальную машину, делаете рестор. Записываете время рестора.

Идете к бизнесу, озвучиваете условные 2 часа и 3 часа, бизнес удивляется, рвет одежду и посыпает голову пеплом и кричит "Ой-вей, продавцы железа обещали рестор за 10 минут". И приводите выкладки, что 10 минут - это вот такая скорость и вот такие примерно SSD диски вместо того, что куплено. Ну а дальше по обстоятельствам.

John Artur La DiffSeagate ST4000NM023
John Artur La DiffИнтерфейс
Подключение SATA 3

Seagate ST4000NM023 4TB SAS - это таки не SATA. Это SAS. А Вы вообще в ту корзину/RAID-контроллер собираетесь эти диски запихнуть?

Andy_OLAP,

Нет, оказывается, бывают диски SATA из серии Constellation ES.3, хотя модель в перечне SAS дисков на официальном сайте производителя в документации .

Автор темы, я бы на Вашем месте проверил еще раз - Вы собираетесь использовать SATA или все же купили SAS диски?

John Artur La DiffПланируется, что БД будет работать на виртуальной машине VMWare.
Читайте внимательно вот эту статью на русском языке . Удачи.

AlionaДля усиления эффекта я бы порекомендовала всё это разместить на облаке общего пользования.
Гарантированно незабываемое удовольствие.

Оля, это же чистый садомазохизм. Вдруг автор темы не поймет, что это сарказм, и что так делать не нужно.