(Возврат на основную страницу)
Стив Каллан
Использование Oracle в качестве источника данных
Ричард Динг
Узнайте размер базы данных SQL Server и ее журнала с помощью этой хранимой процедуры
Грегори А. Ларсен
Цикл разработки системы индексов базы данных... Простите, что? Часть 1
Использование Oracle в качестве источника данных
СУБД Oracle, очевидно, является источником данных сама по себе, и когда пользователю требуется извлечь информацию из базы данных, ему есть из чего выбирать — в его распоряжении находится внушительный арсенал функциональных возможностей и опций. Обычно используются разрешения, роли, предоставление привилегий, таблицы, представления, синонимы и ссылки. Пожалуй, менее очевидными являются другие источники данных, в частности материализованные представления (или использовавшиеся в старых версиях моментальные снимки). В этой статье мы коротко остановимся на материализованных представлениях (materialized view) и расширим их концепцию, чтобы охватить случаи, когда Oracle используется в качестве источника данных для другой системы управления реляционными базами данных. Затем мы продолжим настройку Oracle в качестве источника данных для SQL Server.
Узнайте размер базы данных SQL Server и ее журнала с помощью этой хранимой процедуры
Ричард Динг
Знать размер базы данных SQL Server — одна из многочисленных обязанностей администратора, легко исполнимая с помощью хранимой процедуры sp_SDS. Но она не только определяет, как используется дисковое пространство — эта процедура также может быть использована для слежения за ростом базы данных, предупреждения администратора об увеличении размера файлов данных и файлов журнала, выполнения резервного копирования журнала транзакций и даже для получения сведений об использовании дискового пространства отдельными файлами с тем, чтобы администратор базы данных мог произвести сжатие файлов, наименее эффективно использующих выделенное им пространство (для промышленной системы сжимать файлы настоятельно не рекомендуется. — Прим. ред.).
В этом руководстве подробно рассказывается о sp_SDS и ее вычислительном алгоритме. Она станет для вас следующим шагом после процедуры sp_SOS, которая находит размер объектов — в том числе, таблиц — базы данных SQL Server. Листинг 1 (Определение SP_SDS на языке TSQL ) см. на сайте журнала http://newsletter.narod.ru/sqlmainadm.htm).
Цикл разработки системы индексов базы данных... Простите, что? Часть 1
Грегори А. Ларсен
Эта первая статья в серии, в которой я попробую осветить основные принципы и рекомендации по работе с индексами. Правильно составленные индексы приобретают первостепенную значимость, когда требуется максимально быстрое извлечение записей вашим приложением. Однако, если индексов слишком много, они могут замедлить работу вашего приложения. В этой серии статей я постараюсь дать вам понимание того, какие именно столбцы следует использовать для составления индексов и каким образом нужно это делать для получения выигрыша в производительности. В этой статье я расскажу о цикле разработки системы индексов.
Как это обычно бывает
Основываясь на собственном опыте, могу утверждать, что проектирование индексов для базы данных считается, как правило, чемто второстепенным. Конечно, не со всеми индексами дело обстоит именно так. Как известно, уже на этапе составления схемы базы данных определяются, как минимум, первичные ключи и отношения по внешним ключам. Но это вовсе не означает, что на основе этих схем создаются настоящие индексы. Разработчики, работая над приложениями, конечно, добавляют индексы, но делают они это только по необходимости. Обнаружив, что некий запрос выполняется медленно, они просматривают план выполнения и пытаются понять, что получится, если составить какойнибудь индекс для ускорения запроса.
Они могут даже добавить индексдругой после ввода приложения в эксплуатацию, но опять же — обычно это случается только после того, как ктонибудь пожалуется на низкую производительность.
Можно ли назвать вышеописанное эффективным подходом к разработке системы индексов базы данных? В большинстве случаев, думаю, нет. Разработчикам и администраторам баз данных следует больше думать наперед, когда дело доходит до разработки системы индексов.
Более того, процесс разработки не должен останавливаться с моментом ввода приложения в эксплуатацию. Разработчики и администраторы баз данных должны продолжать дополнять и улучшать индексы в течение долгого времени после выпуска приложения в эксплуатацию. Мне кажется, что индексы должны разрабатываться в рамках особого цикла — так же, как и обычные программы.
Цикл разработки системы индексов
Работая с индексами базы данных, не следует руководствоваться принципом «создал и забыл». Индексы должны быть хорошо продуманы, с течением времени в них следует вносить дополнения и улучшения. Для надлежащего составления и последующего управления индексами вам потребуется особый цикл разработки. Я подкину вам пару идей о том, какие формы может принять этот цикл в вашей рабочей среде.
Большинство ИТкомпаний использует как минимум три различных рабочих среды: производственную среду, среду для контроля качества продукции или тестирования и среду разработки. Ваш код на TSQL перемещается из одной среды в другую по мере того, как процесс разработки идет от этапа к этапу — то же самое должно происходить и с вашими индексами. Так почему бы не оформить процесс разработки и сопровождения системы индексов в следующие этапы: проектирование, разработку, входной контроль, эксплуатацию и сопровождение? Итак, я собираюсь один за другим разобрать все эти этапы, попутно объясняя, какие задачи вам следует определить в рамках каждого из них.
(Возврат на основную страницу)