Архитектура баз данных
Оценить
(0 голоса)
Если параллелизм не был определен ни на уровне таблицы, ни через подсказку, то Oracle выбирает степень параллелизма, основываясь на таких показателях, как количество центральных процессоров сервера, размер таблицы, а также количество файлов базы данных, используемых табличной областью, в которой активизируется таблица. В тех случаях, когда при запросе происходит обращение к нескольким таблицам, степень параллелизма определяется для каждой из них, а самое высокое значение впоследствии используется для запроса. Обратите внимание, что внутри разделов (описываются ранее в этой главе в разделе под названием "Разделы") Огас1е8 поддерживает ограниченный параллелизм запросов. Для вставок, обновлений и удалений, если запрос обращается к единственному разделу данных, будет…
Оценить
(0 голоса)
Если оптимизатор СУБД Oracle принимает решение сканировать таблицу, то количество подчиненных запросов, используемых для получения данных, будет принимать значение п+1, где п - действительная степень параллелизма, которая, впрочем, может отличаться от затребованной степени параллелизма по причинам, указанным в предыдущем разделе, а единица добавляется с учетом процесса самого координатора запросов. Если за сканированием таблицы следует сортировка, то количество процессов для используемых подчиненных запросов составит 2л+1. Рассмотрим, к примеру, следующий оператор SQL: select * from CUSTOMER order by CUST_NAME; В результате будет выполнено полное сканирование таблицы CUSTOMER, за которым последует сортировка. На рисунке 9.5 показана модель процессов, используемая PQO для табличного сканирования…
Оценить
(0 голоса)
Запросы являются не единственными операциями БД, извлекающими преимущества параллелизма. Загрузки данных, создание индекса, а также выполнение таких операторов DML (Data Manipulation Language - языка манипулирования данными), как update и delete, являются примерами операций, которые могут получить преимущества при их разбивке на множество выполняемых одновременно единиц работы. Преимущество проявляется в виде сокращения времени выполнения, особенно если наборы данных оказываются слишком большими. Создание таблицы Создание таблицы также можно распараллелить, когда координатор запроса делегирует задачу создания множеству подчиненных процессов. Заметьте, что если предложение по сохранению таблицы определяет значение minextents, равное 2, то обычно таблицей будет создано два экстента. При параллельном создании таблицы каждый…
Оценить
(0 голоса)
Oracle распараллеливает процедуру создания индекса, предоставляя фазу сканирования таблицы множеству подчиненных запросов, а фазу сортировки - второму набору подчиненных запросов. В результате произойдет слияние, и координатором запроса будет записан индекс. Следующая команда иллюстрирует синтаксис, необходимый для параллельного создания индекса: create index CUST0MER_INDEX1 on CUSTOMER (CUST_ID, REGION) parallel(degree 12); Заметьте, что пока не будет завершено создание индекса, ограничители UNIQUE и PRIMARY KEY должны быть отключены. Операторы DML Параллелизм DML может быть организован следующей командой: alter session enable parallel dml; После этого могут быть применены контекстные подсказки (комментарии), как показано в следующем примере: insert /* parallel(customer, 12) */ into customer select *…
Оценить
(0 голоса)
Наконец вы можете использовать множество процессов при восстановлении БД путем установки параметра recovery_parallelism в файле init.ora, И хотя единственный системный процесс Oracle считывает файлы журналов отката, информация передается многочисленным процессам восстановления.
Оценить
(0 голоса)
ASE (Adaptive Server Enterprise - сервер масштаба предприятия) фирмы Sybase наиболее широко используется в системах Sun и особенно в средах OLTP. В этой главе мы рассмотрим модель процессов, управление памятью, а также характеристики хранения данных ASE. Мы рассмотрим также системные базы данных и прогрессивные возможности параллельных запросов Sybase ASE 11.5. В завершение мы рассмотрим архитектуру Sybase Adaptive Server IQ with Multiplex. Для эффективного использования ресурсов ЦП и памяти, Sybase ASE использует многопотоковую архитектуру. Обрабатывая планирование и диспетчеризацию пользовательских потоков и внутренних потоков СУБД, многопотоковое ядро Sybase вместо потоков Solaris использует собственную потоковую модель. Смотрите раздел "Многопотоковые архитектуры" в главе 5…
Оценить
(0 голоса)
В Sybase ASE управление памятью осуществляется посредством Buffer Manager (менеджера буферов). ASE применяет память совместного использования, или разделяемую память, для содержания кэша данных, процедурного кэша, а также таких структур данных ядра Sybase, как Очереди выполнения и ожидания и цепочки блокировок. До выхода ASE 12.5 изменения в параметрах, влияющих на размер памяти совместного использования, не проявлялись до перезагрузки Sybase. Но ASE 12.5 уже предоставляет возможность динамического изменения этих параметров.
Оценить
(0 голоса)
Эффективные алгоритмы кэширования данных существенно влияют на производительность в том случае, если данные обнаруживаются в кэше и физическое считывание не осуществляется. Задача менеджера буферов заключается в минимизации количества операций физического ввода/вывода, необходимых для выполнения любой задачи. Эффективная стратегия менеджера буферов в сочетании с адекватной памятью приведет к максимальным попаданиям в кэш при нахождении данных и индексных страниц, необходимых задачам пользователей. Одна из особенностей менеджера буферов ASE состоит в поддержке многочисленных именованных кэшей (named caches), эффективных стратегий очистки страниц, а также многочисленных буферных пулов внутри именованных кэшей.
Оценить
(0 голоса)
Менеджер логической памяти способен поддерживать множество кэшей, называемых именованными. Каждый именованный кэш может быть зарезервирован для специфических баз данных или объектов баз данных, например, таблиц и индексов. Такая организация позволяет содержать в памяти объекты с наиболее частыми к ним обращениями, такие как индексы, направляя в различные кэши страницы для других объектов. Для объектов, требующих большого объема памяти, например, изображений и таблиц с низкими уровнями повторного использования данных, могут быть введены ограничения при использовании разделяемых кэшей, что позволит предотвратить заполнение всего кэша данных. И хотя сами кэши могут быть изменены только при перезагрузке СУБД, назначения кэшей могут изменяться динамически. Принятый по…
Оценить
(0 голоса)
Каждый кэш содержит данные в буферах, которые связываются в цепочку MRU-LRU (most recently used-least recently used - наиболее-наименее часто используемые), как показано на 10.2. Рисунок 10.2. Стратегия очистки страниц в Sybase A SE В цепочке представлен маркер очистки - точка в цепочке, за пределами которой "грязныеЪ! буферы автоматически опорожняются на диск. Каждый буферный пул имеет свою собственную цепочку MRU-LRU. Размер области очистки составляет 20% от буферов в пуле памяти для пулов размером менее 300 Мбайт и 20% от 300 Мбайт для больших пулов. Чем больше установлен размер области очистки, тем с большей интенсивностью будет производиться очистка грязных буферов, что в…