Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 15

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 9 10 11 12 13 14 < 15 > 16 17 18 19 20 21 .. 161 >> Следующая


¦ Строки таблицы и записи индекса, находящиеся в одном блоке с другими данными, к которым часто производятся обращения, получают преимущество от своего соседства с горячими данными. Чем более эффективно вы организуете горячие данные в таблицах и индексах, то есть чем ближе они будут находиться друг к другу, тем более эффективным можно считать кэш.

¦ Конечные пользователи получают преимущество, если другие пользователи недавно обращались к горячим данным, так как кэш базы данных используется совместно и большая часть требуемых данных (обычно 99 % или больше) возвращается без выполнения операций физического ввода-вывода.

¦ Для блоков, к которым производятся повторные обращения в пределах одного запроса, потребуется немного операций физического ввода-вывода, даже если эти блоки считаются холодными, так как ваш запрос сам сделает нужные данные горячими и, следовательно, кэшированными, для остальной части запроса.

¦ Небольшие таблицы и индексы (таблицы, в которых меньше 10 ООО строк, и индексы с менее чем 90 000 записей) обычно становятся идеально кэшированными. В реальной жизни нечасто возникает такая ситуация, что к небольшой таблице или индексу обращаются очень редко, из-за чего они не могут стать хорошо кэшированными. Однако следствием таких редких обращений становится то, что низкая результирующая производительность не создаст большой проблемы. Даже если запрос к небольшому объекту потребует физического ввода-вы-вода, операций физического ввода-вывода будет выполнено немного, гак как первые несколько из них поместят весь объект в кэш на время, достаточное для выполнения запроса. Для описания процесса, в ходе которого запрос к обычно холодным блокам делает эти блоки горячими на время выполнения запроса, я использую термин самокэширование. Самокэширование позволяет вам спокойно игнорировать потенциальные операции физического ввода-вывода для небольших таблиц и индексов даже в таких редких случаях, когда небольшие объекты являются холодными.
Таблицы

33

¦ Даже большие индексы обычно становятся хорошо кэшированными, так как индексы занимают намного меньше места, чем таблицы, а планы доступа, включающие эти индексы, обычно работают на самых горячих областях индексов.

¦ Только большие таблицы (таблицы с более чем 1 ООО ООО строк) обычно бывают плохо кэшированными, если только вы систематически не обращаетесь к горячему подмножеству таблицы. Минимизация количества различных блоков, к которым производится обращение в больших таблицах, в целях уменьшения излишнего физического ввода-вывода, действительно является важным фактором для улучшения производительности.

¦ Все остальные эквивалентные варианты (например, варианты, требующие одинакового количества операций логического ввода-вывода) относятся к случаю использования самых горячих блоков. Часто встречается вариант, когда осуществляется проход по индексу, так как блоки индекса и таблицы, к которым производилось индексированное обращение, чаще становятся горячими, чем случайные блоки таблицы.

Таблицы

Таблицы представляют собой основу реляционной базы данных. Реляционная теория описывает таблицы как абстрактные объекты, не придавая значения порядку составляющих их строк и столбцов. Однако таблицы также существуют в физической форме на диске сервера баз данных, причем здесь порядок следования элементов уже ощутимо влияет на производительность. Если приложение запрашивает байты, физически хранящиеся на диске или в кэше в памяти, серверные процессы должны уметь обращаться к ним.

Физическое размещение строк таблиц влияет на производительность считывания этих строк, поэтому важно знать различные типы таблиц и понимать, как размещение зависит от типа. На рис. 2.2 показаны четыре различные физические таблицы, иллюстрирующие основные схемы роста и старения таблицы, и показано, как такие схемы влияют на расположение данных.

Таблицы занимают одну или несколько непрерывных областей дискового пространства (называемых в Oracle экстентами'), которые сервер может считывать с минимальным количеством перемещений считывающей головки и максимальной эффективностью. База данных объединяет строки таблицы в блоки, размер которых слишком мал, чтобы показать их здесь, — обычно 2-16 Кбайт. Размер этих блоков остается неизменным в большинстве или всех базах данных (в зависимости от поставщика). Блоки — это элементы наименьшего размера, которые база данных считывает с диска или из кэша, как мы уже увидели ранее. Когда в ранее пустовавшие блоки экстента записываются данные, отметка заполнения — то есть наивысшая точка таблицы, в которой база данных должна производить поиск —

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

2. Основы доступа к данным
Предыдущая << 1 .. 9 10 11 12 13 14 < 15 > 16 17 18 19 20 21 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100