Основы работы с ORACLE для начинающих
Решил публично ответить одному из подписчиков.
Дело в следующем.
У меня на сайте есть форма, через которую подписчики могут задавать вопросы, но форма анонимная и, даже если захочу, приватно ответить не смогу. А вопросы иногда задают интересные.
Как вам, например, такой:
Обалденный вопрос!
Причём задают его регулярно.
Скорее всего, буду прав, сказав, что половина сотрудников в компании Оракл ломают над этим вопросом голову каждый день с утра до вечера. Куда уж нам...
Хотя на самом-то деле, для рядового программиста повышение производительности сводится в первую очередь к созданию индексов.
Конечно, нужно индексы создать не абы как, а правильно. Чтобы помогали ораклу быстро выполнять запросы, не мешали добавлять данные и поменьше занимали места на диске.
Нужно создать хорошо работающий набор индексов.
При наличии хорошего набора индексов и производительность подрастёт. Заметно.
В этом посте расскажу вам стратегию создания индексов, которой пользуюсь сам, и которая меня пока ещё не подводила.
Стратегия такова: сначала создайте базу данных без индексов, затем дайте пользователям возможность её наполнить и после этого создайте индексы только на рабочие таблицы.
Теперь подробнее.
Когда вы создаёте базу данных, точно вычислить узкие места и медленные запросы вам вряд ли удастся. Каждая база живёт своей жизнью, часто не предсказуемой и порой очень удивительной. Не стоит на этапе создания тратить много времени на оптимизацию ради производительности.
Тем более, что создать базу без единого индекса у вас, скорее всего, не получиться, поскольку оракл автоматически создаёт индексы для некоторых правил ссылочной целостности. И у вас даже не спросит на это разрешения. Например, для первичных ключей. Знайте это.
Разверните чистую базу у заказчика. Приступайте к её эксплуатации.
Когда база только начинает эксплуатироваться, то сначала происходит её интенсивное наполнение, а затем начинается период размеренного роста.
На этапе интенсивного наполнения данные вводятся, как правило, в таблицы с нормативно-справочной информацией. Это всевозможные справочники товаров, клиентов, сотрудников, подразделений и т.д.
Заниматься производительностью на этом этапе тоже особо не стоит. Главное – чтобы работала. Пусть даже некоторые операции притормаживают. Это допустимо. Можно и потерпеть. Ведь через некоторое время эти таблицы, так или иначе, будут наполнены и медленные запросы уйдут в небытиё.
После наполнения справочников начнут расти, так называемые, рабочие таблицы (основные массивы данных). Это те таблицы, которые содержат результаты операционной деятельности. Например, таблицы счетов, заказов, накладных и прочие таблицы, хранящие данные оперативного учета.
Темпы роста рабочих таблиц зависят от интенсивности операционной деятельности. Вот сейчас у нас стоит убийственная жара и в большинстве своём народ стал вялый, работает в полсилы, соответственно рабочие таблицы растут медленно (хотя, например, в системе учета у производителя мороженного всё наоборот – бешеными темпами). И на этапе создания вы эти темпы никак точно не смоделируете.
Нужно дать возможность рабочим таблицам подрасти до каких-нибудь значительных размеров. Проявить себя. В идеале надо дождаться момента, когда таблицы разрастутся до такого размера, что клиентское приложение начнёт заметно притормаживать (тогда ваша роль спасителя будет всеми замечена и отмечена). Конечно, можете не доводить ситуацию до таких крайностей.
Когда у вас есть список рабочих таблиц и вы можете про каждую сказать, как быстро она растёт, приступайте к созданию индексов.
Первый шаг...
Берите наиболее быстро растущие таблицы из списка. Для каждой из них определите, на какую другую рабочую таблицу она ссылается. Как правило, в базе вы сможете найти ограничение ссылочной целостности между этими таблицами – foreign key (FK). Сделайте индекс. Включите в него все колонки, входящие в FK.
Но ссылочного ключа в базе может и не быть (ну, забыли объявить, бывает). Проявите смекалку. Поищите тщательнее.
Чаще всего это таблицы, образующие связку master-detail. И, между прочим, колонки от master в detail могут иметь другие имена – учтите это «пионерское» безобразие.
Если рабочая таблица растёт медленно, по сравнению с другими таблицами, то создавать индексы не спешите.
Второй шаг...
Запустите клиентское приложение и выпишите названия параметров, использующихся в отчётах, реестрах документов и т.д. Оставьте в списке только часто используемые параметры. Как правило, параметрами будут значения из справочных таблиц.
Исключите из списка параметры с датами, периодами, кварталами и всё, что имеет отношение ко времени. Эти параметры вас сейчас не должны интересовать, поскольку это особые случаи оптимизации. С наскоку их не возьмёте.
Теперь опять посмотрите на рабочие таблицы. Если в какой-нибудь из них есть колонка, которая ссылается на справочную таблицу из списка с параметрами, то создайте для неё индекс.
Вот и вся оптимизация.
После создания индексов:
Если вы поспешили и не стали ждать, когда таблицы значительно подрастут, то, скорее всего, никто ничего не заметит.
Можно было бы сразу создать индексы на все FK. Но! Во-первых, это чересчур расточительно. Большинство из этих индексов не будут задействованы в работе, но место в базе занимать будут. И могут замедлить операции массового добавления данных в таблицы. Во-вторых, внимательно прочитайте предыдущий параграф.
Конечно, эта стратегия подходит в первую очередь для баз данных транзакционного типа.
И ещё. Эта стратегия создания индексов хороша в случаях:
Кстати, посмотреть список индексов можно с помощью такого запроса:
SELECT * FROM user_indexes;
Перед его запуском посмотрите структуру user_indexes и вместо звездочки впишите только понятные вам колонки.
В следующем письме постараюсь разобрать ещё один обалденный вопрос.
Чтобы после сбоя в системе (например, отказа жесткого диска) восстановить базу нужно иметь под рукой резервную копию. (Нет резервной копии — прощай работа )) Чем свежее копия, тем лучше. Более того: резервная копия базы должна быть полной и непротиворечивой.
Умеете делать резервную копию оракловой базы? Вопрос далеко-далеко не праздный (если вы уже знаете, как делать копию, то, наверное, догадываетесь, о чём пойдёт речь, правильно — о времени). Тема резервного копирования для администраторов оракла — одна из ключевых.
Большинство считает, что в мире Oracle есть два основных направления: администрирование и программирование. Человек становится либо специалистом в администрировании оракла - умеет правильно ставить базы, повышать производительнось и восстанавливать то, что восстановлению не подлежит.