Одной из привлекательных черт реляционных баз данных является то, что разработчику приложения абсолютно ничего не нужно знать о маршруте доступа к данным. Поиск по SQL-запросу наилучшего маршрута к необходимым данным, например, прямой путь или по индексу, предоставляется оптимизатору базы данных. Современные оптимизаторы запросов становятся все более изощренными; в главе 8 описываются роль и функционирование оптимизаторов запросов.
Память совместного использования базы данных
Каждая СУБД отводит значительную область памяти для совместного использования и делает ее доступной для всех процессов, связанных с базой данных. Память совместного использования (разделяемая память) включает следующие компоненты;
• Буферный кэш для хранения часто используемых страниц базы данных, или блоков. Последующие запросы к тем же самым страницам могут быть удовлетворены из кэша, поэтому нет необходимости производить повторные считывания данных с дисков. Буферный кэш хранит как страницы данных системного каталога, так и табличные данные пользователя.
Модифицированные страницы данных также могут содержаться в кэше до тех пор, пока они не будут отправлены на диск в подходящий момент. Страница данных может быть модифицирована более одного раза до того, как будет выгружена, сохраняя при этом дисковые записи в процессе.
• Кэш для хранения подготовленных операторов SQL. Осуществляется синтаксический анализ каждого оператора SQL, и может быть выполнен план запроса, сгенерированный перед выполнением оператора. Если идентичный оператор SQL используется позднее и обнаруживается в кэше, то нет необходимости вновь подвергать его синтаксическому анализу и генерировать новый план.
• Буфер журнала для хранения деталей модификации данных (журнализация изменений). При полном заполнении журнального буфера или в случае запуска других событий, буфер записывается в файл журнала.
• Области сообщений, используемые в IPC (Interprocess Communication - во взаимодействии между процессами) в базе данных.
• Другие внутренние кэши, специфичные для системы базы данных.
Все системные процессы базы данных присоединяются к памяти совместного использования, как это происходит со всеми процессами пользовательского агента или теневыми процессами.
Для 32-разрядных баз данных (все базы данных, реализованные на платформе Solaris 2.6 или ранее, а также все еще наиболее актуальные для Solaris 7 и позднее) память совместного использования ограничена примерно 3.75 Гбайт, поскольку адресное пространство процессов ограничено 4 Гбайт. Только для очень больших баз данных требуется, вероятно, больше памяти, когда 64-разрядные базы данных на платформе Solaris 7, Solaris 8 или Solaris 9 допускают огромные сегменты памяти совместного использования.