SSD с Oracle

19

Мы пытались использовать SSD с Oracle для ускорения наших тестовых миграций. В настоящее время выполнение миграции занимает 12-18 часов, в зависимости от объема данных (очевидно, мы также вносим изменения в производительность). У нас есть несколько дешевых коробок Linux, которые мы используем для различных прогонов и анализа.

Стоимость SSD напрямую от Dell непомерно высока. Мне было интересно, есть ли у кого-нибудь опыт использования потребительских твердотельных накопителей (таких как Crucial / Micron).

Я понимаю, что поддержка TRIM будет проблемой для Linux (с использованием Centos). Кто-нибудь использовал их на Windows 7, чтобы противостоять этому?

Стюарт Брок
источник
1
Мы закончили тем, что добавили твердотельные накопители для индексов и табличных пространств и распределили их между собой. Мы не получили большой скачок скорости, на который мы надеялись. Скорее, на 10-15% быстрее для наших миграций, но при отсутствии каких-либо других опций, которые позволили бы сэкономить время (наш эксперт по настройке Oracle уже был освобожден от работы с БД). Спасибо за все комментарии. Мы использовали твердотельные накопители Crucial, которые предлагали довольно хорошую производительность за хорошую цену, и у нас все еще не было никаких проблем. Мы также приняли, что они изнашиваются и следят за ними (и обильными резервными копиями)! Спасибо за все комментарии. Стюарт.
Стюарт Брок

Ответы:

6

Вот самые большие проблемы, которые я вижу с твердотельными накопителями и базами данных:

  • Отказ SSD
    • Это случается чаще, чем мне бы хотелось; часто в течение одного-двух лет при нормальном использовании, и быстрее, если читать / записывать в большой степени. Что происходит, когда вы отправляете свои повторы, журналы и файлы данных на SSD? Много читает и много пишет. Плохая комбинация, ИМО.
  • SSD "лекарство от всех болезней"
    • Да, твердотельные накопители хороши, когда дело касается скорости чтения. Они отлично подходят для загрузки с ОС или запуска программ. Но нельзя допускать, чтобы твердотельные накопители стали исправлением для полной оптимизации. Я уверен, что нет, поскольку вы, вероятно, пытаетесь сделать все возможное, чтобы миграция происходила быстрее, но иногда твердотельные накопители могут показаться святым Граалем, чтобы избежать некоторых более сложных проблем, когда речь идет об оптимизации. (Во многих отношениях то же самое можно сказать и об использовании большего количества оборудования или памяти при решении проблемы. Иногда лучше оптимизировать проблему, а не выбрасывать больше оборудования).
  • Несоответствие R / W
    • Читает молниеносно.
    • Пишет не так быстро, как читает (хотя обычно лучше, чем жесткие диски)
      http://en.wikipedia.org/wiki/Solid-state_drive
    • Таким образом, твердотельные накопители имеют смысл только для загрузочных носителей (таких как ОС, исполняемые файлы БД и т. Д.).
  • Выравнивание износа и безопасность
    • Если безопасность вызывает какое-либо беспокойство, выравнивание износа вашего SSD сделает почти невозможным стирание диска и уверенность в том, что он обнулен. Два, три и более проходов даже не сделают этого, и всегда будет шанс, что некоторая часть ваших данных все еще будет доступна.
Керри Шоттс
источник
Вы все еще придерживаетесь того же мнения в 2019 году?
TrojanName
7

Я пока не вижу ответов на ваш вопрос, и, хотя у меня нет опыта использования SSD-накопителей потребительского уровня с базой данных, я подумал, что следующий вопрос о ServerFault может оказаться полезным:

/server/69037/configuring-sql-for-optimal-performance-ssd-or-hdd

редактировать: я недавно нашел следующую статью и думал, что добавлю ее в свой ответ. В нем говорится об использовании SSD с SQL Server, но я подумал, что некоторые из обсуждаемых факторов могут быть полезны и для администраторов баз данных Oracle.

http://technet.microsoft.com/en-us/magazine/hh334997.aspx (уменьшить ввод-вывод, повысить производительность)

Джефф
источник
5

SSD могут сделать чтение данных быстрее.

Написание не будет быстрее. Даже не думайте о размещении повторов на SSD, так как они только записаны. Чтобы ускорить запись в повтор: добавьте больше дисков и разделите их. Повторные операции записываются последовательно, поэтому добавление большего количества шпинделей улучшает пропускную способность записи до тех пор, пока не будет достигнут предел контроллера.

Что делает эта тестовая миграция? Использует ли он процедурный код или наборы?

При использовании процедурного кода обязательно выполняйте массовые операции. Наборы всегда быстрее.

ik_zelf
источник
1
Есть ли у вас источник для эталона, показывающего низкую скорость записи на твердотельных накопителях, особенно с таким же количеством чередования? Насколько я понимаю, твердотельные накопители быстрее записывают, но разница не такая существенная, как для чтения.
Ли Риффель
@Leigh - это правда, но суть в том, что преимущество значительно больше для случайного ввода, чем для последовательного . Я думаю, что было бы справедливо сказать, что твердотельные накопители все еще предназначены только для высоких случайных потребностей.
Джек Дуглас
1
Мы провели некоторое тестирование с картами f5100 в системе M5000, где мы попытались использовать флэш-диски в качестве вторичного кэша для zfs, выделенного для файлов и расширенного sga. Чтение было быстрым, запись - медленной, по сравнению с тем, что мы делали с SAN. (какая-то коробка ЭМС). Как уже отмечалось, журналы пишутся последовательно. Диски сделаны для такого типа, когда полосатые.
ik_zelf
2

Я сменил свой старый жесткий диск на твердотельный накопитель Crucial M4 512 МБ, чтобы выполнить тестирование на большой базе данных Oracle.

Я запускаю Oracle 10.2 под Windows 7 в VMWare.

Изменения производительности действительно впечатляют. Импорт и экспорт баз данных и SQL-запросов намного быстрее.

Тем не менее, время от времени появляется странная ошибка:

ОШИБКА 2012-06-18 18: 18: 14,177: Ошибка при выполнении запроса
java.sql.SQLException: ORA-01578: поврежден блок данных ORACLE (файл № 6, блок № 1646317)
ORA-01110: файл данных 6: 'C: \ ORACLE \ ПРОДУКТ \ 10.2.0 \ ORADATA \ DUNE \ WEBDATA02.DBF»

У меня никогда не было этой проблемы с той же виртуальной машиной на одной машине с жестким диском.

После запуска DBV в файле ничего не помечается как поврежденное.

Я не нашел ничего об этой проблеме.

svett
источник
Не признаю эту ошибку, но я забыл упомянуть, что SSD сильно ускорил импорт. Это были только миграционные прогоны, которые прыгали только на 10-15% в скорости. Так что спасибо за это.
Стюарт Брок