Как я могу максимизировать производительность записи, не влияя на чтение?
Из точки зрения «не хочу прикасаться к конфигурации» - проверьте свои индексы. Если вы пишете в таблицы, которые сильно индексируются, помните, что каждый раз, когда вы пишете строку, индексы меняются. Меньше индексов, меньше физических операций ввода-вывода.
Это - очевидно - повлияет на чтение.
Если у вас есть время и емкость, я обнаружил, что обычно записываемые таблицы разделяются на определенные табличные пространства и что / эти табличные пространства хранятся на отдельном канале RAID, также помогает, но это зависит от используемого вами оборудования и добавляет кучу других соображения.
Если у вас действительно есть время поразмыслить над этим, то купите и прочтите книгу Кэри Миллсапса «Оптимизация производительности Oracle» - она устарела (все зависит от того, какую версию Oracle вы используете), но является классической.
Хорошее начало - следовать той же методологии Oracle - Stripe and Mirror Everything. Это дает вам хорошую основу, на основе которой вы можете добавлять более конкретные улучшения.
ЖЕ методология находится в следующем PDF-файле:
http://www.oracle.com/technology/deploy/availability/pdf/oow2000_sane.pdf
Есть хорошее обсуждение Спроси Тома:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4433784236146
Одним из основных факторов, влияющих на ТО ЖЕ, является простота администрирования. Он передает многие аспекты производительности ОС и нижележащему уровню хранения. Идея состоит в том, что ваши файлы табличных пространств уже распределены по миллиону дисков в массиве хранения, поэтому любые возни, которые вы делаете поверх этого, мало помогают. Однако, как всегда, дьявол кроется в деталях. Заманчиво рассматривать уровень хранения как черный ящик, но вам действительно нужно понимать, что происходит, и знать, что находится под каждым из ваших файлов табличного пространства.
Настройте его в кластере и пусть ваши приложения указывают на определенный узел для записи; затем читать из самого кластера.
Внедрение ЖЕ - чередование и зеркальное отображение всего, как было предложено в предыдущем ответе, - хорошая стратегия по умолчанию. В частности, если вас беспокоит производительность записи, избегайте RAID5 любой ценой - он создает 4-кратные накладные расходы на запись при сохранении информации о четности. Массив RAID5 с большим объемом кеш-памяти может на время скрывать эти накладные расходы, но при длительной записи в конечном итоге будет ощущаться штраф RAID 5.
При оптимизации ввода-вывода записи следует учитывать множество вещей, но вот еще несколько вещей, которые следует учитывать:
Убедитесь, что в полосе достаточно дисковых устройств для поддержки скорости ввода-вывода. Вам необходимо разместить в полосе достаточное количество дисков, чтобы поддерживать общее необходимое количество операций ввода-вывода в секунду, а не только количество ГБ для хранения. Диск обеспечивает лучшее время отклика, когда данные только частично заполнены - внешние части диска могут доставлять данные быстрее, чем внутренние. В общем, вы хотите, чтобы в вашей полосе были малонаселенные диски.
Лучше избегать ввода-вывода, чем оптимизировать ввод-вывод. Самый большой источник ввода-вывода записи, которого можно избежать, - это временный сегментный ввод-вывод для операций сортировки и хеширования. Правильный выбор размера агрегатной цели PGA - лучший способ избежать этого.
Убедитесь, что все ваши индексы служат допустимой цели - для ускорения запроса или для принудительного применения первичных или внешних ключей. Обслуживание индексов часто является основным источником операций ввода-вывода при записи, поэтому не создавайте лишних индексов.
Создавайте большие и многочисленные журналы повторного выполнения. Это помогает избежать накладных расходов на переключение журналов и остановок базы данных, которые могут произойти, когда журналы циклически повторяются до завершения контрольных точек файла данных. Вы также можете разместить свои журналы повторов на выделенных устройствах или на выделенной мелкозернистой полосе.
Используйте асинхронный ввод-вывод. Если ваши файлы данных находятся в файловых системах (например, не в RAW или ASM), установите для FILESYSTEMIO_OPTIONS значение AYNCH или SETALL. SETALL реализует прямой ввод-вывод, а также асинхронный ввод-вывод, который обычно помогает при записи, но может замедлять чтение.
Если вы готовы рискнуть со своими COMMIT, вы можете изменить COMMIT_WRITE (10g) или COMMIT_WAIT и COMMIT_LOGGING, чтобы отложить или пакетировать ввод-вывод, который происходит при выполнении фиксации. Однако убедитесь, что вы понимаете последствия; вы можете потерять некоторые транзакции в случае сбоя базы данных, если сделаете это.
Если у вас есть доступ к коду приложения, убедитесь, что используются вставки массива и, возможно, используйте вставки прямого пути с помощью подсказки APPEND.