Interface Ltd.
Отправить E-Mail
http://www.interface.ru
| СТАТЬЯ |
19.09.00
|
СОДЕРЖАНИЕ:
Десять лет назад разработка приложений для работы с базами данных нередко длилась месяцами или даже годами. Все планировалось заранее: размер, схема, количество пользователей и т.д. Теперь подобные приложения создаются в течение нескольких недель или месяцев, развиваясь непосредственно в процессе разработки, и запускаются в эксплуатацию еще до того, как все аспекты окончательно проработаны.
Оперативная разработка важных приложений выдвигает строгие требования
к механизмам хранения данных, которые должны быть легко доступны, комплектоваться
системой для быстрого восстановления данных и утилитами для автоматического
администрирования. Microsoft® SQL Server™ версии 7.0 — это масштабируемый,
надежный и простой в использовании продукт, представляющий собой прекрасную
основу для разработки приложений следующего столетия.
При разработке механизмов хранения данных SQL Server 7.0 преследовалось
несколько важных целей. Определяющим фактором стратегии явилась тенденция
к упрощению использования, которая позволила бы обеспечить широкое внедрение
приложений, использующих технологии СУБД. В идеале СУБД должны стать абсолютно
“прозрачными” для конечных пользователей и почти “прозрачными” для администраторов.
Клиенты ищут решения проблем своего бизнеса. Большинство решений на основе баз данных дороги и сложны. SQL Server версий 6.0 и 6.5 открыл возможность простого использования средств реляционных СУБД (РСУБД). SQL Server 7.0 поднял эту концепцию на новый уровень, что сделало его одной из наименее сложных СУБД для создания, администрирования и внедрения деловых приложений.
Простота и удобство использования SQL Server 7.0 обеспечивается его многочисленными передовыми возможностями, включая:
Клиенты стремятся защитить свои инвестиции в бизнес-приложения и, по мере роста организации, базы данных должны развиваться, чтобы обеспечить обработку большего объема данных, увеличенного количества транзакций и обслуживания растущего числа пользователей. SQL Server 7.0 предоставляет единое ядро СУБД, масштабируемое от портативных компьютеров под управлением операционной системы Microsoft Windows® 95 или Windows 98 до кластеров с симметричной мультипроцессорной архитектурой, работающих в среде Microsoft Windows NT® Server, Enterprise Edition. Все эти системы должны удовлетворять требованиям высокой безопасности и надежности, которые выдвигаются со стороны критических бизнес-приложений.
Следующие особенности служат основой высокой масштабируемости:
SQL Server 7.0 устраняет множество проблем параллельного доступа, масштабируемости и надежности путем замены сложных структур данных и алгоритмов простыми. Новые структуры лучше масштабируются, порождают меньше проблем при параллельной обработке, менее сложны, а, следовательно, и более надежны.
В SQL Server 7.0 устранена необходимость проверки целостности базы данных
перед каждой операцией резервного копирования. Проверка наиболее важных
структур данных "на лету" обеспечивает большую устойчивость. За счет этого
проверка целостности происходит теперь значительно быстрее.
В следующей таблице перечислены основные особенности механизмов хранения
данных в SQL Server 7.0.
| Особенность | Описание и достоинства |
| Размеры типов данных | Предельные размеры типов данных значительно увеличены. |
| Базы данных и файлы | Упрощено создание баз данных. Теперь они размещаются в файлах операционной системы, а не на логических устройствах. |
| Динамическое управление памятью | За счет оптимизации распределения и использования памяти повышена производительность. Упрощенная структура сводит к минимуму конкуренцию с другими менеджерами ресурсов. |
| Динамическая блокировка на уровне строк | Полноценная реализация блокировки на уровне строк, как для данных, так и для индексов. Динамическая блокировка обеспечивает автоматический выбор оптимального уровня (строки, страницы, диапазона страниц или всей таблицы) для всех операций с базой данных. Благодаря этому, достигается повышение производительности без дополнительной настройки. Допускается и явное указание конкретного уровня блокировки. |
| Динамическое управление пространством | Автоматическое изменение размеров допустимо в регулируемых пределах, что сводит к минимуму потребность во вмешательстве администратора. Отсутствует необходимость предварительного распределения пространства и управления структурой данных. |
| Развитие | Новая архитектура разработана с учетом возможности развития и обеспечивает основу для реализации объектно-реляционных свойств. |
| Поддержка оперативной памяти большого объема | В сочетании с Windows NT Server 2000 обеспечивается адресация более 4 ГБ оперативной памяти, системы на базе процессоров Alpha и другие технологии. |
| Управление журналом | Упрощенная архитектура обеспечивает повышение производительности при выполнении операций усечения, копирования и восстановления. |
| Упреждающее чтение | Для повышения производительности и исключения ручной настройки реализованы интеллектуальные алгоритмы упреждающего чтения. |
| Текст и изображения | Текстовые и графические данные хранятся отдельно в оптимизированном формате |
| Unicode | Встроенная поддержка Unicode в сочетании с интерфейсами ODBC и OLE DB для создания многоязычных Unicode-приложений. |
Архитектура механизма хранения данных
Microsoft SQL Server 7.0 масштабируется в широких пределах от корпоративных приложений до приложений для портативных компьютеров. Это возможно благодаря абсолютно новой структуре организации дискового пространства, призванной удовлетворить нужды приложений, которые появятся в будущем.
Первоначальный код был унаследован от Sybase и ориентирован на 8Мб UNIX-системы. Microsoft переработала этот код, но на будущее SQL Server нуждался в лучшей основе. Использование новых форматов повышает управляемость, производительность и масштабируемость, обеспечивая возможность масштабирования сервера в широких пределах.
Среди многих преимуществ новой организации дискового пространства в SQL Server 7.0:
Большинство реляционных СУБД состоят из реляционного ядра и механизмов хранения данных. В данном документе основное внимание уделено механизмам хранения данных, которые включают различные подсистемы, реализующие:
Физическая организация базы данных
Microsoft SQL Server 7.0 лучше интегрирован с Windows NT Server, чем предыдущие версии SQL Server. Теперь базы данных размещаются непосредственно в файлах Windows NT Server. Унаследованные от UNIX логические устройства базы данных и сегменты были заменены простой системой, которая "проецирует" каждую базу данных в индивидуальный набор файлов.
SQL Server более приспособлен к требованиям как крупных, так и небольших
приложений. Некоторые разработчики СУБД начинают с середины и двигаются
в сторону крупномасштабных приложений. Они представили различные продукты,
использующие разные форматы данных, языки и интерфейсы программирования
для создания объемных и сложных приложений. Поскольку многие пользователи
Microsoft Access переходят на SQL Server, Microsoft заботится и о них,
уделяя внимание тем свойствам, которые необходимы для создания компактных
недорогих приложений.
Основная единица хранения данных в SQL Server — страница. В SQL Server 7.0 размер страницы вырос с 2 до 8 КБ. В начале каждой страницы расположен заголовок (header) длиной 96 байт, используемый для хранения системной информации, такой как тип страницы, количество свободного пространства на странице и идентификатора объекта-владельца страницы.
В файлах данных СУБД SQL Server 7.0 определено 7 типов страниц.
| Тип страницы | Содержимое |
| Data | Строки с данными всех типов, кроме text, ntext и image |
| Index | Индексы |
| Log | Записи журнала с информацией об изменении данных для использования при восстановлении |
| Text/Image | Данные типов text, ntext и image |
| Global Allocation Map | Информация о распределенных экстентах |
| Page Free Space | Информация о доступном на страницах свободном пространстве |
| Index Allocation Map | Информация об экстентах, используемых для таблиц или индексов |
Страницы данных содержат данные всех типов, за исключением text, ntext и image, которые хранятся на отдельных страницах. Строки данных располагаются последовательно одна за другой сразу после заголовка страницы. Таблица смещений строк начинается с конца страницы.
Эта таблица содержит один элемент для каждой строки на странице. Каждый элемент указывает, на каком расстоянии от начала страницы расположен первый байт строки. Элементы таблицы смещений строк имеют обратный по сравнению с расположением на странице самих строк порядок. В SQL Server 7.0 строки не могут переходить со страницы на страницу, и максимальный объем данных в одной строке составляет 8060 байт, не включая данные типов text, ntext и image.
Экстент — основная единица распределения пространства для таблиц и индексов. Один экстент состоит из 8 смежных страниц и имеет размер 64 КБ. Для обеспечения эффективного использования пространства SQL Server 7.0 может не распределять всего экстента целиком для таблицы, которая содержит небольшой объем данных.
В SQL Server 7.0 существует два типа экстентов: однородные и смешанные. Однородный экстент имеет единственный объект-владелец, и все страницы экстента могут использоваться только этим объектом-владельцем.
Смешанные экстенты, впервые появившиеся в SQL Server 7.0, прекрасно
подходят для использования в небольших приложениях. В SQL Server пространство
добавляется к таблице по одному экстенту. В SQL Server 7.0 это может привести
к большому перерасходу пространства для маленьких таблиц, поскольку размер
страницы увеличился до 8 Кб. Смешанные экстенты позволяют распределять
для маленьких таблиц или индексов по одной странице. Только в том случае,
если таблица или индекс занимают более восьми страниц, для них начинается
распределение однородных экстентов. Смешанные экстенты разделяются между
несколькими (до 8) объектами. Для новой таблицы или индекса выделяются
страницы из смешанных экстентов. Когда размер таблицы или индекса достигает
8 страниц, он "переключается" на однородные экстенты.
Выявление "рваных" страниц гарантирует поддержание целостности базы данных. Хотя размер страницы в SQL Server 7.0 равен 8 КБ, Windows NT Server осуществляет операции ввода-вывода сегментами по 512 байт. Такое несоответствие порождает возможность того, что страница будет записана лишь частично — это может произойти при сбое электропитания или возникновении каких-либо других проблем в промежутке времени от того момента, когда записан первый 512-байтовый сегмент, до того, когда будет завершена запись всех 8 КБ.
После того, как записан первый сегмент из 512 байт, может показаться, что страница уже обновлена, хотя на самом деле этого не произошло. (Временная отметка для страницы расположена в заголовке, который занимает первые 96 байт.) Существует несколько способов решения этой проблемы. Вы можете использовать устройства ввода-вывода с резервным питанием от батарей. Если у вас одна из таких систем — выявление "рваных" страниц необязательно.
SQL Server выявляет незавершенные операции ввода-вывода путем формирования битовой маски, по одному биту для каждого сегмента страницы. Каждый раз при записи страницы этот бит изменяет свое состояние из первоначального (как он был записан на диске) на противоположное и записывается в заголовок страницы. Если при чтении страницы обнаруживается неверное состояние бита — это свидетельствует о том, что операция ввода-вывода не была завершена и страница "рваная". Такой механизм требует меньших затрат, чем подсчет контрольной суммы.
Вы можете включить или отключить выявление "рваных" страниц, т.к. заголовок
страницы помечается при изменении состояния битов. При включении и отключении
выявления "рваных" страниц, состояние битов, которые были "переключены",
проверяется и корректируется во время последующего чтения страниц.
SQL Server 7.0 использует для хранения баз данных набор файлов операционной системы, при этом для каждой из них создается собственный файл. Несколько баз данных больше не могут находиться в одном файле. Существует несколько важных преимуществ такого упрощения: файлы могут разрастаться и сокращаться, управление пространством также стало проще.
Все данные и объекты базы данных, такие как таблицы, хранимые процедуры,
триггеры и представления, хранятся в следующих файлах.
| Файл | Описание |
| Первичный файл данных (Primary data file) | Этот файл — отправная точка базы данных. Всякая база данных имеет только один первичный файл данных. Рекомендуемое расширение — .mdf. |
| Вторичные файлы данных (Secondary data files) | Эти файлы являются необязательными и могут хранить все данные и объекты, не вошедшие в первичный файл данных. Некоторые базы данных могут вообще не иметь вторичных файлов данных, а другие иметь множество таких файлов. Рекомендуемое расширение — .ndf. |
| Файлы журнала (Log files) | В этих файлах фиксируется вся информация о транзакциях, которая используется для восстановления базы данных. Каждая база данных имеет, по крайней мере, один файл журнала. Рекомендуемое расширение — .ldf. |
При создании базы данных все входящие в ее состав файлы "обнуляются" (заполняются нулями), чтобы стереть все данные, которые остались на диске от ранее удаленных файлов. Хотя это приводит к увеличению продолжительности создания БД, это избавляет Windows NT от необходимости очистки файлов при записи данных в них (поскольку они уже "обнулены") во время нормальной работы с базой данных, что повышает производительность системы.
База данных состоит из одного или более файлов данных и одного или более файлов журнала. Файлы данных могут быть сгруппированы в определенные пользователем группы. Таблицы и индексы могут быть поставлены в соответствие различным группам файлов для управления размещением данных на физических дисках.
Группа файлов — удобная единица администрирования, использование которой повышает его гибкость. При обслуживании больших баз данных, объемом в несколько терабайт резервное копирование всей базы невозможно произвести в приемлемые сроки независимо от скорости копирования. SQL Server 7.0 позволяет производить резервирование различных частей базы данных в ночное время по циклическому графику.
"Продвинутые" пользователи могут с успехом использовать группы файлов для того, чтобы разместить индексы и таблицы определенным образом. SQL Server 7.0 может эффективно работать и без группировки файлов, и в большинстве систем нет необходимости определять пользовательские группы файлов. В этом случае по умолчанию в группу включаются все файлы, и SQL Server 7.0 может самостоятельно планировать эффективное распределение в пределах базы данных.
Файлы журнала никогда не входят в группы, управление распределением
пространства для них осуществляется отдельно от распределения пространства
для данных.
Использование файлов и групп файлов
Использование файлов и групп файлов позволяет повысить производительность базы данных за счет распределения по различным дискам, контроллерам или RAID-массивам. Например, если в вашем компьютере установлено 4 диска, вы можете создать базу данных, состоящую из трех файлов данных и одного файла журнала, и каждый из них разместить на отдельном диске. При доступе к данным 4 магнитных головки смогут осуществлять чтение или запись одновременно, что повысит скорость выполнения этих операций.
Кроме того, использование файлов и групп файлов позволяет лучше разместить данные, благодаря тому, что конкретная таблица может быть создана в определенной группе. Производительность в данном случае повышается за счет того, что все операции ввода-вывода для этой таблицы осуществляются с указанным диском. Например, интенсивно используемая таблица может находиться в определенном файле, который принадлежит к определенной группе, расположенной на определенном диске, а другая таблица, используемая реже — в другом файле, принадлежащем к другой группе, расположенной на втором диске.
Вот несколько общих рекомендаций по использованию файлов и групп файлов:
Средства SQL Server 7.0 во многом усовершенствованы в аспекте управления и распределения пространства. Например, структуры данных для управления отношениями страница-объект были спроектированы заново. Вместо связанных списков страниц теперь используются битовые карты, что является более "чистым" и простым решением, допускающим параллельное сканирование. Теперь каждый из файлов более "автономен", он содержит больше сведений о самом себе. Это очень полезно при копировании файлов базы данных или их пересылке по электронной почте.
SQL Server 7.0 также оснащен более эффективной системой отслеживания пространства в таблицах. Произведенные усовершенствования позволяют:
SQL Server 7.0 быстро распределяет страницы для объектов и повторно использует пространство, освободившееся при удалении строк. Эти операции являются внутрисистемными и используют структуры данных, невидимые для пользователя. Тем не менее, эти процессы и структуры иногда упоминаются в сообщениях SQL Server. Это обсуждение алгоритмов распределения пространства и структур данных ставит своей целью предоставить пользователям и администраторам информацию, необходимую для понимания сообщений, генерируемых SQL Server.
В SQL Server 7.0 произведены значительные изменения в структуре внутренних данных, управляющих распределением и повторным использованием страниц. Эти структуры данных остаются невидимыми для конечного пользователя, и, таким образом, никак не влияют на его работу, за исключением повышения скорости.
Портативные и настольные компьютеры могут обладать ограниченным дисковым пространством, поэтому вы можете автоматически сокращать размер файлов, если включена соответствующая возможность. Сервер периодически проверяет использование пространства в каждой базе данных. Если обнаружено большое количество свободного пространства, размер файла базы данных будет уменьшен. И файлы данных, и файлы журнала могут быть сокращены. Эти операции происходят в фоновом режиме и не влияют на работу пользователя с базой данных. Вы можете также использовать средства SQL Server Enterprise Manager или DBCC для индивидуального или группового сокращения размеров файлов.
При сокращении файла строки из страниц, расположенных в конце файла, перемещаются в страницы, распределенные ранее. В индексах узлы также перемещаются из конца файла на страницы, лежащие ближе к началу. В обоих случаях страницы, расположенные в конце файлов, освобождаются и возвращаются в файловую систему. Базы данных могут сокращаться только до того момента, пока в них не останется свободного пространства. Компрессия данных не используется.
Автоматическое увеличение файлов сокращает потребность в управлении базой данных и устраняет множество проблем, возникающих при выходе базы данных или журнала за пределы отведенного пространства. При создании базы данных должен быть задан первоначальный размер файлов. SQL Server создает файлы данных, размер которых указывается создателем базы. Добавляемые данные постепенно заполняют эти файлы. По умолчанию файлы данных могут, по мере необходимости, увеличиваться в размере, пока не будет исчерпано все дисковое пространство. Альтернативная настройка предусматривает автоматическое увеличение размеров файлов при их заполнении данными, однако до определенного предела. Это предотвращает переполнение дисков.
Рассматриваемая возможность полезна в тех случаях, когда SQL Server используется в качестве встроенной в приложение СУБД или когда пользователь не имеет доступа к услугам системного администратора. При необходимости пользователь может разрешить автоматическое увеличение файлов, чтобы сократить накладные расходы на администрирование, избежать слежения за свободным пространством в базе данных и ручного распределения дополнительного пространства.
При создании базы данных файлы данных должны быть велики, как только возможно, с учетом максимального ожидаемого объема данных. Вы можете разрешить автоматическое увеличение размеров файлов, но указать при этом ограничения. Если первоначально указанный размер превышен и файл начал автоматически увеличиваться, произведите повторную оценку максимального размера базы данных и добавьте соответствующее количество дискового пространства или создайте и добавьте к базе данных дополнительные файлы или группы файлов.
Увеличение размера базы данных свыше первоначально указанного может быть запрещено. Тогда при заполнении файлов новые данные не могут быть добавлены, пока не будут добавлены новые файлы данных. Автоматическое увеличение файлов может привести к фрагментации пространства, если на одном диске расположено большое количество файлов. Поэтому рекомендуется создавать файлы или группы файлов на возможно большем количестве локальных физических дисков. Объекты, интенсивно конкурирующие за дисковое пространство, следует размещать в разных группах файлов.
Расширенные средства блокировки
Средства блокировки в Microsoft SQL Server 7.0 получили развитие в нескольких направлениях.
В SQL Server 6.5 впервые появилась блокировка на уровне строк при выполнении операций вставки. SQL Server 7.0 поддерживает полноценную блокировку на уровне строк, как для строк данных, так и для элементов индекса. В процессе выполнения транзакций отдельные записи могут быть обновлены без блокировки страниц. Многие OLTP-приложения вступают в интенсивную конкуренцию, особенно при добавлении строк в таблицы или индексы. Менеджер блокировок динамически регулирует использование ресурсов в крупных базах данных, устраняя необходимость в ручной настройке параметров блокировки на сервере. Он автоматически осуществляет выбор между блокировкой страницы (предпочтительной при просмотре таблиц) и блокировкой на уровне строк (предпочтительной при вставке, обновлении или удалении данных).
SQL Server 7.0 оснащен превосходным механизмом блокировки, который редко используется в промышленных СУБД: динамической блокировкой. Во время работы механизмы хранения данных динамически взаимодействуют с процессором обработки запросов для выбора, исходя из параметров схемы и запроса, стратегии блокировки, требующей наименьших затрат.
Динамическая блокировка обладает следующими преимуществами:
SQL Server может динамически блокировать следующие ресурсы (по мере
повышения уровня).
| Ресурс | Описание |
| RID | Идентификатор строки. Используется для блокировки отдельной строки в таблице. |
| Key | Блокировка строки индекса. Используется для защиты диапазона ключей в транзакциях обрабатывающих последовательности. |
| Page | Страница данных или индекса размером 8 КБ. |
| Extent | Непрерывная группа из 8 смежных страниц данных или индекса. |
| Table | Вся таблица, включая все данные и индексы. |
| DB | Вся база данных. |
В SQL Server блокировка ресурсов производится в различных режимах, определяющих возможность доступа к ним со стороны конкурирующих транзакций. Используются следующие режимы:
При блокировке в режиме совместного использования конкурирующие транзакции могут осуществлять чтение. Никакие другие транзакции не могут модифицировать данные, пока для ресурса установлена блокировка в режиме общего использования. Такие блокировки снимаются, как только чтение ресурса завершено, кроме тех случаев, когда уровень изоляции транзакции установлен для многократного чтения или выше, либо использовано явное указание на сохранение блокировки в течение всей транзакции.
Блокировка в режиме обновления используется для ресурсов, которые могут подвергаться изменениям. Использование такого режима предотвращает возникновение традиционных форм тупиковых ситуаций. Если две транзакции, запросившие блокировку ресурсов в режиме общего использования, затем одновременно попытаются модифицировать данные, происходит неудачная попытка перевода блокировок в режим исключительного использования. Обе транзакции ожидают, пока для одной из них не будет снята блокировка в режиме совместного использования — таким образом, возникает тупиковая ситуация. Блокировка в режиме обновления устраняет эту опасность, т.к. только одна транзакция в каждый момент времени может установить для ресурса блокировку в режиме обновления.
Блокировка в режиме исключительного (монопольного) использования применяется при операциях модификации, таких как UPDATE, INSERT или DELETE (обновление, вставка или удаление). Таким образом, гарантируется, что несколько изменений не могут быть внесены в один ресурс одновременно (т.е. конкурирующими транзакциями). Никакая другая транзакция не может осуществлять чтение или модификацию данных, для которых установлена блокировка в режиме исключительного использования.
Предупредительная блокировка свидетельствует о том, что SQL Server произвел попытку установить блокировку в режиме совместного или исключительного использования для нижележащих в иерархии ресурсов. Применение предупредительной блокировки повышает производительность, Когда какая-либо транзакция запрашивает блокировку на уровне целой таблицы для выяснения того, может ли она быть корректно осуществлена, SQL Server достаточно проверить наличие предупредительной блокировки для этой таблицы вместо того, чтобы проверять, не заблокированы ли отдельные строки или страницы этой таблицы.
Существует два типа блокировки схемы. Блокировка Sch-M устанавливается при выполнении операций языка описания данных (data definition language — DDL), таких как добавление столбца или удаление таблицы. Блокировка Sch-S применяется при компиляции запросов и не влияет на блокировки со стороны транзакций, в том числе и в режиме исключительного использования. Таким образом, во время компиляции запроса могут выполняться другие транзакции, даже те, которые требуют монопольного использования всей таблицы. При этом выполнение DDL-операций над таблицей запрещено.
Архитектура базисных таблиц и индексов
Серьезные изменения, которые были внесены в организацию базисных таблиц Microsoft SQL Server 7.0, позволяют процессору обработки запросов использовать большее количество вторичных индексов, что значительно увеличивает производительность работы приложений для принятия решений. Оптимизатор запросов использует богатый набор стратегий исполнения, а большинство ограничений оптимизации, присущих более ранним версиям SQL Server, устранены. В частности, SQL Server 7.0 менее чувствителен к проблемам выбора индекса, благодаря чему затраты на настройку сокращаются.
Данные таблиц теперь хранятся в наборе страниц данных, которые имеют размер 8 КБ. Каждая страница имеет заголовок длиной 96 байт, который содержит такую системную информацию, как идентификатор владеющей данной страницей таблицы и указатели на следующую и предыдущую страницы в связанном списке. В конце страницы расположена таблица смещений строк; остальное пространство страницы занято строками данных.
В SQL Server 7.0 для таблиц применяется один из двух методов организации страниц данных:
Индекс (кластеризованный или нет) ускоряет поиск строк в таблице. Индекс содержит значения ключей, построенных на основании значений одного или более столбцов таблицы. Эти ключи хранятся таким образом, что SQL Server может быстро и эффективно осуществлять поиск строк, связанных с тем или иным значением ключа. Если таблица не имеет индексов, данные хранятся в ней без всякого порядка.
В кластеризованном индексе порядок значений в индексе соответствует порядку данных в таблице (в некотором смысле, индекс сам является местом хранения данных). Кластеризованный индекс похож на телефонный справочник, где данные упорядочены по фамилиям абонентов.
Поскольку кластеризованный индекс определяет порядок хранения данных, каждая таблица может иметь только один кластеризованный индекс; однако он может быть создан на основании значений из нескольких столбцов. Например, телефонный справочник упорядочен по фамилиям, а внутри фамилий — по именам.
Кластеризованные индексы содержат иерархическое дерево с указанием диапазонов значений, хранящихся в определенной области индекса. Если поиск производится по значению кластеризованного индекса, SQL Server быстро выявляет страницу, содержащую нужное значение, а затем осуществляет на ней поиск записей с этим значением. Самый нижний уровень дерева индекса (листья) — страницы, содержащие данные.
Некластеризованные индексы похожи на предметный указатель в книге, когда данные расположены в одном месте, а указатель — в другом. Ссылки указывают на то, где находится информация, перечисленная в индексе. Листом дерева в некластеризованном индексе является адрес данных (номер страницы и смещение). Таким образом, в некластеризованном индексе существует промежуточный уровень между его внутренней структурой и собственно данными.
При поиске с использованием некластеризованного индекса SQL Server находит в индексе заданное значение, определяет месторасположение строки данных, а затем извлекает их прямо оттуда. Таким образом, некластеризованные индексы — оптимальный выбор при выполнении запросов с указанием точного соответствия.
Может существовать несколько некластеризованных индексов. Вы можете определить некластеризованный индекс для каждого из столбцов, которые обычно используются при поиске данных в таблице.
Поскольку некластеризованные индексы хранят ключи кластеризованного индекса для указания на строки данных, важно, чтобы ключи кластеризованного индекса были как можно меньше. Избегайте выбора столбцов, с большим объемом информации в качестве ключей для кластеризованного индекса, если для таблицы используются также и некластеризованные индексы.
SQL Server 7.0 поддерживает до 249 некластеризованных индексов для каждой таблицы. В некластеризованных и кластеризованных индексах используются схожие структуры двоичного дерева. Разница в том, что некластеризованные индексы не оказывают влияния на расположение строк данных. Набор страниц, используемых для хранения неупорядоченного массива данных, не зависит от того, определен ли для этой таблицы некластеризованный индекс.
Статистика распределения индекса
Для всех индексов ведется сбор статистической информации о селективности и распределении значений ключа. Селективность — это характеристика, показывающая, сколько строк обычно идентифицируется одним значением ключа. Когда ключ имеет уникальные значения, селективность высока; часто встречающиеся значения ключа (например, в 1000 строк) приводят к низкой селективности.
Селективность и статистика распределения используются SQL Server для оптимизации поиска в таблицах при обработке операторов Transact-SQL. Статистическая информация не сосредоточена на какой-либо одной странице, а хранится в виде длинной битовой строки, переходящей со страницы на страницу, подобно тому, как хранятся изображения.
В Microsoft SQL Server 7.0 дополнен новыми возможностями хранения данных и обработки текста и изображений.
SQL Server 7.0 поддерживает типы данных с использованием Unicode, что облегчает хранение информации на различных языках в одной базе данных и устраняет необходимость преобразования символов или установки нескольких кодовых страниц. При использовании Unicode для хранения каждого символа отводится не 1, а 2 байта. Поскольку для 2 байт существует 65536 различных битовых комбинаций, Unicode может использовать одну стандартную кодировку для представления всех символов во всех языках, включая такие, как китайский, в котором очень много символов. Типы данных, использующих Unicode, поддерживаются и со стороны языков программирования.
Тот факт, что данные Unicode требуют для хранения вдвое большего пространства, компенсируется устранением необходимости преобразования символов из различных кодовых страниц. Новые типы данных, использующие Unicode, это ntext, nchar и nvarchar. Они полностью аналогичны типам text, char и varchar за исключением того, что поддерживают большее количество символов и требуют для хранения большего пространства.
В обычных типах данных, не использующих Unicode, допускается употребление символов, определенных в некотором стандартном наборе символов, который указывается при установке SQL Server и остается неизменным на протяжении всей его “жизни”. При использовании типов данных, поддерживающих Unicode, в столбце могут содержаться любые символы, определенные в стандарте Unicode, который включает в себя все символы из всех наборов.
Хранение данных различных типов
Гибкость хранения данных была повышена за счет увеличения максимальной длины данных таких типов как char, varchar, binary и varbinary с 255 байт до 8000. Теперь не приходится использовать типы text и image ни для чего, кроме данных очень большого объема. Строковые функции Transact-SQL поддерживают обработку длинных строк данных типа char и varchar, а функция SUBSTRING может применяться для обработки столбцов с данными типа text и image.
Кроме того, улучшена обработка “нулевых” и пустых строк. Новый тип данных uniqueidentifier предоставляет возможность использования уникальных глобальных идентификаторов GUID.
Типы данных text, ntext и image
SQL Server обеспечивает надежную основу для развития объектно-реляционных возможностей. Одно из усовершенствований в SQL Server 7.0 затрагивает хранение текста и изображений, для чего используются новые эффективные структуры данных.
Типы данных ntext, text и image в SQL Server 7.0 могут хранить значения, объем которых достигает 2 ГБ. При этом даже одно значение превышает тот объем, который обычно обрабатывается приложением за один шаг; объем некоторых величин может даже превысить размер виртуальной памяти клиентского компьютера. Это означает, что для передачи таких данных в приложение необходимо предпринять специальные меры. Если значение не превышает по объему обычной символьной, двоичной или Unicode-строки (8000 символов, 8000 байт или 4000 символов, соответственно), то оно может быть обработано с помощью операторов SELECT, UPDATE и INSERT точно так же, как и данные других, более компактных типов.
Значения данных типов text, ntext и image хранятся не как часть строк, а на отдельных страницах. Для каждого значения в строке запоминается лишь указатель на расположение данных, который имеет длину 16-байт. Строка, содержащая несколько столбцов с данными типа text, ntext или image, имеет в каждом из них по одному указателю.
Данные, хранимые в наборе 8-килобайтных страниц, не обязательно располагаются одно за другим. В SQL Server 7.0 страницы организованы в логическую структуру двоичного дерева. В более ранних версиях они были связаны в последовательность. Преимущества двоичного дерева заключаются в том, что операция, начавшаяся с середины строки, выполняется более эффективно, поскольку позиционирование осуществляется быстрее. В случае использования простой последовательности страниц это чаще всего приводило бы к" беспорядочному метанию” по файлам базы данных. Структура двоичного дерева слегка изменяется в зависимости от того, превышает ли объем данных 32 КБ.
Журнал Microsoft SQL Server 7.0 состоит из нескольких физических файлов с записями. Ранее журнал представлял собой системную таблицу, расположенную на обычных страницах базы данных. Эти страницы с журналом распределялись точно так же, как страницы с другими таблицами и конкурировали со страницами данных за дисковое пространство и память кэша.
Каждый из файлов журнала логически поделен на небольшие сегменты, которые называются виртуальными файлами журнала и являются функциональными единицами протоколирования транзакций. Когда виртуальный файл журнала перестает быть актуальным — т.е. более не содержит записей, относящихся к активным транзакциям, он может быть усечен, и занимаемое им пространство становится доступным для протоколирования новых транзакций.
В SQL Server 7.0 предприняты меры для предотвращения использования чрезмерно большого количества маленьких виртуальных файлов журнала. Их количество растет медленнее, чем размер. Если размер файлов увеличивается с малым инкрементом, это обычно приводит к появлению множества небольших виртуальных файлов. Если инкремент увеличен, SQL Server будет создавать меньшее число более крупных виртуальных файлов журнала.
По мере добавления записей в журнал, логический конец журнала перемещается из одного виртуального файла в другой. Если в базе данных существует более одного физического файла журнала, логический конец журнала перемещается по всем виртуальным файлам во всех физических файлах, прежде чем вернуться в первый виртуальный файл первого физического файла.
Наименьший размер виртуального файла журнала составляет 256 КБ. Минимальный размер журнала транзакций — 512 КБ, что соответствует двум виртуальным файлам по 256 КБ. При увеличении размеров журнала растет как количество, так и размер виртуальных файлов. Небольшой журнал может содержать несколько маленьких виртуальных файлов. Очень большой журнал состоит из большего количества крупных виртуальных файлов.
Увеличение и уменьшение размеров журнала может происходить автоматически. Если отсутствует пространство, которое может быть использовано повторно, журнал увеличивается за счет добавления новых логических фрагментов. Если необходимо больше пространства, будет добавлено больше логических файлов. Менеджер журнала подразделяет физические файлы журнала на логические. Логический файл может быть активен или доступен для повторного использования. Резервная копия логического файла может быть создана, если он не содержит записей активного журнала. После создания резервной копии журнал может быть использован повторно.
Управление протоколированием транзакций
Журнал транзакций помогает восстановить целостность базы данных в случае сбоя системы. Записи журнала для одной базы данных содержатся в одном или нескольких файлах операционной системы, называемых файлами журнала, они хранят протокол последовательности всех изменений, вносимых в базу данных, и информацию о том, в рамках какой транзакции они были произведены.
Журнал непрерывно растет по мере выполнения протоколируемых операций. Для некоторых крупномасштабных операций фиксируется лишь тот факт, что они имели место. В журнале фиксируется успешное завершение или откат каждой транзакции. Это позволяет SQL Server отменять транзакции или “воспроизводить” их.
Откат транзакции происходит при отказе от выполнения незавершенной транзакции. SQL Server восстанавливает базу данных в состояние, предшествующее началу транзакции, производя обратные изменения.
Воспроизведение транзакций происходит при восстановлении транзакций по журналу. Изменения вносятся в базу данных в той же последовательности, что и при выполнении самих транзакций. В результате этого база данных приводится в состояние, которое существовало на момент создания резервной копии журнала.
В менеджер журнала транзакций SQL Server 7.0 внесены следующие усовершенствования:
По мере необходимости Microsoft SQL Server 7.0 динамически запрашивает и освобождает память. Теперь администратору не надо указывать, как много памяти должно быть выделено SQL Server, хотя такая возможность сохранилась.
В SQL Server существует несколько конкурирующих подсистем, совместно использующих доступную память: журнал и система восстановления нуждаются в памяти для чтения страниц и отмены внесенных изменений, а обработчику запросов она необходима для кэширования и сортировки. Среди других подсистем — кэш процедур, буферный пул, менеджер блокировок и структуры данных. В SQL Server 7.0 все эти системы динамически распределяют необходимую им память и могут возвратить обратно, когда потребность в ней исчезнет.
Операционные системы Microsoft Windows NT, Microsoft Windows 95 и Windows 98 поддерживают виртуальную память, метод расширения установленной на компьютере физической памяти. При использовании виртуальной памяти операционная система создает страничный файл (файл подкачки) и разбивает память на фрагменты, называемые страницами. Страницы, обращение к которым происходило недавно, расположены в физической памяти (ОЗУ). Если в течение некоторого времени к странице не происходит обращений, она записывается (вытесняется) в страничный файл. Если позднее приложение обращается к этому фрагменту памяти, операционная система считывает страницу обратно из страничного файла в физическую память (это и называется подкачкой). Общий объем памяти, которая становится доступна приложениям, складывается из объема установленной физической памяти и размера страничного файла.
Одна из первостепенных задач при проектировании СУБД — сокращение операций дискового ввода-вывода, поскольку чтение и запись являются одними из наиболее ресурсоемких операций. Для хранения страниц, считанных из базы данных, SQL Server создает в памяти буферный кэш. Значительная часть кода SQL Server предназначена для сокращения количества операций обмена данными между буферным кэшем и физическим диском. Чем больше размер буферного кэша, тем меньше операций ввода-вывода с файлами базы данных приходится выполнять SQL Server. Однако, если буферный кэш потребует памяти, которая превышает объем установленной на сервере физической памяти, операционная система начнет активное вытеснение и подкачку из страничного файла. Это приведет к тому, что физический обмен с файлами базы данных будет просто заменен обращениями к файлу подкачки.
Большой объем операций ввода-вывода — характерная черта всех СУБД. По умолчанию SQL Server пытается установить баланс между следующими двумя целями:
Управление буфером и вводом-выводом
Вместо списка давности использования в SQL Server 7.0 для управления буфером ввода-вывода применяется механизм, зависящий от таймера. Это повышает производительность, т.к. требует меньших затрат на синхронизацию. При этом увеличивается масштабируемость в больших системах с мультипроцессированием, а в малых системах эффект остается незначительным. Производительность обработки запросов улучшается за счет использования, как параллельного ввода-вывода, так и обмена большими объемами данных с файлами, содержащими объекты базы данных.
Объект Buffer Manager поддерживает счетчики для слежения за тем, как SQL Server использует память для хранения страниц данных, внутренних структур данных и кэша процедур. Операции физического ввода-вывода учитываются по мере того, как SQL Server считывает с диска и записывает страницы базы данных на диск.
Слежение за использованием памяти в SQL Server может помочь, например, в выявлении существующих узких мест из-за нехватки доступной физической памяти для хранения наиболее часто используемых данных в кэше, когда SQL Server вынужден считывать их с диска. Осуществляя слежение, вы можете определить, может ли быть повышена производительность обработки запросов путем установки дополнительной памяти либо освобождением существующей памяти для кэша данных или внутренних структур SQL Server. Мониторинг операций физического ввода-вывода особенно важен для определения того, как часто SQL Server вынужден читать данные с диска.
По сравнению с другими операциями, такими как доступ к оперативной памяти, физический ввод-вывод потребляет гораздо больше времени. Сокращение физического ввода-вывода может значительно повысить производительность обработки запросов.
Вырабатываемые системой запросы на чтение контролируются реляционным ядром, а затем оптимизируются механизмами хранения. Метод доступа, используемый для чтения страниц, определяет общий характер операций чтения, которые будут произведены. Реляционное ядро определяет наиболее эффективный метод доступа, например, просмотр таблицы, просмотр индекса или чтение по ключу. Затем запрос передается механизму хранения данных, который оптимизирует операции чтения, требующиеся для реализации метода доступа. Операции чтения инициируются потоком (thread), который выполняет пакет.
Механизм упреждающего чтения в SQL Server 7.0 усовершенствован и значительно упрощен. Благодаря размещению соответствующих инструкций, как в обработчике запросов, так и в механизме хранения данных, было сокращено более тысячи строк исходного текста программы, а также устранены ставшие лишними параметры настройки.
Просмотр страниц в SQL Server 7.0 усовершенствован за счет использования новых структур данных. Механизм хранения может формировать последовательные списки адресов данных на диске, которые должны быть считаны. Это позволяет SQL Server оптимизировать операции ввода-вывода и выполнять их за один шаг, как одну операцию чтения большой порции данных. SQL Server запрашивает множество последовательных операций немедленного упреждающего чтения для каждого просматриваемого файла. Таким образом эффективно используются преимущества дисковых массивов с чередованием.
Механизм параллельного упреждающего чтения позволяет дисковой подсистеме достичь максимальной скорости работы. Механизм распределяет страницы между доступными процессорами. Операции ввода-вывода выполняются одновременно для нескольких файлов.
В SQL Server 7.0 устранено разделение потоков упреждающего чтения и сведены к минимуму переключения контекста. Новые структуры размещения данных позволяют осуществлять упреждающее чтение без следования по цепочке страниц. Обработчик запросов помогает оптимизировать упреждающее чтение за счет использования промежуточного индекса для предсказания следующей страницы при просмотре индексов (включая просмотр кластеризованных таблиц).
SQL Server 7.0 также осуществляет упреждающее чтение последовательно расположенных на диске страниц индекса для повышения скорости его просмотра. Дополнительно обработка индекса ускорена за счет заблаговременного выполнения операций, что позволило организовать последовательное упреждающее чтение некластеризованных индексов.
Microsoft SQL Server 7.0 представляет собой совершенную реализацию СУБД Microsoft, созданную на прочной основе SQL Server 6.5. Для SQL Server 7.0 было заявлено более десятка новых патентов в области технологий СУБД. Среди аспектов, которых затронули передовые нововведения:
За дополнительной информацией обращайтесь в Interface Ltd.
Interface Ltd.Отправить E-Mail http://www.interface.ru |
|
| Ваши замечания и предложения отправляйте вебмастеру |