Как обычно повышают производительность базы


Как обычно повышают производительность базы



Решил публично ответить одному из подписчиков.

Дело в следующем.

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

Как вам, например, такой:

Как повысить производительность базы?


Обалденный вопрос!

Причём задают его регулярно.

Скорее всего, буду прав, сказав, что половина сотрудников в компании Оракл ломают над этим вопросом голову каждый день с утра до вечера. Куда уж нам...

Хотя на самом-то деле, для рядового программиста повышение производительности сводится в первую очередь к созданию индексов.

Конечно, нужно индексы создать не абы как, а правильно. Чтобы помогали ораклу быстро выполнять запросы, не мешали добавлять данные и поменьше занимали места на диске.

Нужно создать хорошо работающий набор индексов.

При наличии хорошего набора индексов и производительность подрастёт. Заметно.

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

Стратегия такова: сначала создайте базу данных без индексов, затем дайте пользователям возможность её наполнить и после этого создайте индексы только на рабочие таблицы.

Теперь подробнее.

Когда вы создаёте базу данных, точно вычислить узкие места и медленные запросы вам вряд ли удастся. Каждая база живёт своей жизнью, часто не предсказуемой и порой очень удивительной. Не стоит на этапе создания тратить много времени на оптимизацию ради производительности.

Тем более, что создать базу без единого индекса у вас, скорее всего, не получиться, поскольку оракл автоматически создаёт индексы для некоторых правил ссылочной целостности. И у вас даже не спросит на это разрешения. Например, для первичных ключей. Знайте это.

Разверните чистую базу у заказчика. Приступайте к её эксплуатации.

Когда база только начинает эксплуатироваться, то сначала происходит её интенсивное наполнение, а затем начинается период размеренного роста.

На этапе интенсивного наполнения данные вводятся, как правило, в таблицы с нормативно-справочной информацией. Это всевозможные справочники товаров, клиентов, сотрудников, подразделений и т.д.

Заниматься производительностью на этом этапе тоже особо не стоит. Главное – чтобы работала. Пусть даже некоторые операции притормаживают. Это допустимо. Можно и потерпеть. Ведь через некоторое время эти таблицы, так или иначе, будут наполнены и медленные запросы уйдут в небытиё.

После наполнения справочников начнут расти, так называемые, рабочие таблицы (основные массивы данных). Это те таблицы, которые содержат результаты операционной деятельности. Например, таблицы счетов, заказов, накладных и прочие таблицы, хранящие данные оперативного учета.

Темпы роста рабочих таблиц зависят от интенсивности операционной деятельности. Вот сейчас у нас стоит убийственная жара и в большинстве своём народ стал вялый, работает в полсилы, соответственно рабочие таблицы растут медленно (хотя, например, в системе учета у производителя мороженного всё наоборот – бешеными темпами). И на этапе создания вы эти темпы никак точно не смоделируете.

Нужно дать возможность рабочим таблицам подрасти до каких-нибудь значительных размеров. Проявить себя. В идеале надо дождаться момента, когда таблицы разрастутся до такого размера, что клиентское приложение начнёт заметно притормаживать (тогда ваша роль спасителя будет всеми замечена и отмечена). Конечно, можете не доводить ситуацию до таких крайностей.

Когда у вас есть список рабочих таблиц и вы можете про каждую сказать, как быстро она растёт, приступайте к созданию индексов.

Первый шаг...

Делайте индексы на foreign key
между рабочими таблицами.


Берите наиболее быстро растущие таблицы из списка. Для каждой из них определите, на какую другую рабочую таблицу она ссылается. Как правило, в базе вы сможете найти ограничение ссылочной целостности между этими таблицами – foreign key (FK). Сделайте индекс. Включите в него все колонки, входящие в FK.

Но ссылочного ключа в базе может и не быть (ну, забыли объявить, бывает). Проявите смекалку. Поищите тщательнее.

Чаще всего это таблицы, образующие связку master-detail. И, между прочим, колонки от master в detail могут иметь другие имена – учтите это «пионерское» безобразие.

Если рабочая таблица растёт медленно, по сравнению с другими таблицами, то создавать индексы не спешите.

Второй шаг...

Создавайте индексы на foreign key
между рабочими таблицами и справочниками.


Запустите клиентское приложение и выпишите названия параметров, использующихся в отчётах, реестрах документов и т.д. Оставьте в списке только часто используемые параметры. Как правило, параметрами будут значения из справочных таблиц.

Исключите из списка параметры с датами, периодами, кварталами и всё, что имеет отношение ко времени. Эти параметры вас сейчас не должны интересовать, поскольку это особые случаи оптимизации. С наскоку их не возьмёте.

Теперь опять посмотрите на рабочие таблицы. Если в какой-нибудь из них есть колонка, которая ссылается на справочную таблицу из списка с параметрами, то создайте для неё индекс.

Вот и вся оптимизация.

После создания индексов:

  1. Посмотрите на работу клиентского приложения: "Быстрее стало работать?"
  2. Поговорите с пользователями: "Отчёты быстрее стали формироваться?"

Если вы поспешили и не стали ждать, когда таблицы значительно подрастут, то, скорее всего, никто ничего не заметит.

Можно было бы сразу создать индексы на все FK. Но! Во-первых, это чересчур расточительно. Большинство из этих индексов не будут задействованы в работе, но место в базе занимать будут. И могут замедлить операции массового добавления данных в таблицы. Во-вторых, внимательно прочитайте предыдущий параграф.

Конечно, эта стратегия подходит в первую очередь для баз данных транзакционного типа.

И ещё. Эта стратегия создания индексов хороша в случаях:

  1. Когда чувствуете, что базу делали «пионеры», а переделывать нет возможности и желания.
  2. Когда вы мало знаете о базе, например, только устроились на работу и не хотите шибко напрягаться, а что-то всё-таки делать надо.

Кстати, посмотреть список индексов можно с помощью такого запроса:

SELECT * FROM user_indexes;

Перед его запуском посмотрите структуру user_indexes и вместо звездочки впишите только понятные вам колонки.

В следующем письме постараюсь разобрать ещё один обалденный вопрос.





Опубликован: 13 августа 2010, 13:18


Похожие статьи:

  1. Как и чем создать Backup в Oracle

    Чтобы после сбоя в системе (например, отказа жесткого диска) восстановить базу нужно иметь под рукой резервную копию. (Нет резервной копии — прощай работа )) Чем свежее копия, тем лучше. Более того: резервная копия базы должна быть полной и непротиворечивой.

  2. Сколько стоит сделать резервную копию оракловой базы?

    Сколько стоит сделать резервную копию оракловой базы? Умеете делать резервную копию оракловой базы? Вопрос далеко-далеко не праздный (если вы уже знаете, как делать копию, то, наверное, догадываетесь, о чём пойдёт речь, правильно — о времени). Тема резервного копирования для администраторов оракла — одна из ключевых.

  3. Ответ на извечный оракловый вопрос

    Ответ на извечный оракловый вопрос Большинство считает, что в мире Oracle есть два основных направления: администрирование и программирование. Человек становится либо специалистом в администрировании оракла - умеет правильно ставить базы, повышать производительнось и восстанавливать то, что восстановлению не подлежит.


Ваш комментарий:



cod

Все поля обязательны для заполнения.
Ваш email не публикуется.