Волк В.К. Базы данных. Практикум по проектированию, программированию и администрированию баз данных, включающий примеры и практические задания для самостоятельного выполнения
 Скачать 3.17 Mb.
|
|
ГЛАВА 11. ПОДДЕРЖКА ФИЗИЧЕСКОЙ МОДЕЛИ ДАННЫХ Модель, или структура данных, — одно из основополагающих понятий технологий хранения и обработки информации, хорошо знакомое каждому про- граммисту. В теории и технологии разработки реляционных баз данных рас- сматриваются три уровня представления модели данных: – концептуальный уровень — так называемая ER-модель, описывающая объектную структуру предметной области в понятиях «сущность — атрибут — связь»; – логический уровень, представляющий реляционную схему базы данных в «табличной» терминологии и обеспечивающий SQL-взаимодействие про- граммных приложений с сервером баз данных; – физический уровень, на котором объекты логической модели данных отображаются в элементы файловой структуры вычислительной системы. MS SQL-Server поддерживает двухуровневую структуру физической мо- дели данных: – верхний уровень физической модели обеспечивает взаимосвязь с фай- ловой системой и представлен объектами «файл» и «группа файлов»; – нижний уровень обеспечивает взаимосвязь с логической моделью дан- ных, определяет внутреннюю структуру файла базы данных и представлен объ- ектами «страница» и «экстент» (группа страниц). 11.1. Файловая модель базы данных Файловая структура базы данных представляет верхний уровень физиче- ской модели данных, на котором сервер баз данных обеспечивает взаимодей- ствие с файловой системой. Структура базы данных MS SQL-Server представ- лена объектами двух категорий: файлы и группы файлов. 11.1.1. Файлы и группы файлов MS SQL-Server поддерживает файлы двух типов: – единственный(в базе данных) файл журнала транзакций (log-file), в котором сервер сохраняет информацию обо всех активных операциях доступа к базе данных, то есть о тех операциях, которые изменили ее состояние (напри- мер, об операциях Update, Delete или Insert). Имена файлов этого типа имеют стандартное расширение .ldf (log data file); – множество файлов данных (data-files), в которых хранятся экземпляры всех логических объектов базы данных — пользовательских и системных таб- лиц, хранимых представлений, процедур, функций, ограничений целостности данных и т. д., а также служебных структур данных, например индексов. Имена файлов этого типа могут иметь одно из двух стандартных расширений: .mdf (master data file) или .ndf (secondary data file). Если в базе данных всего один файл типа data, он имеет статус первично- го (primary file — .mdf). Администратор может создавать и другие файлы этого 10 / 19 144 типа — все они будут иметь статус вторичных файлов (secondary file — .ndf), при этом в базе данных может быть только один первичный файл. Все данные системного каталога базы данных хранятся в первичном фай- ле, а пользовательские данные могут храниться как в первичном, так и во вто- ричных файлах. Файл типа data — это, по существу, сегмент дискового пространства определенного размера, зарезервированный сервером баз данных у файловой системы. Начальный размер файла либо явно указывается в момент создания базы данных SQL-инструкцией CREATE DATABASE, как это показано в листин- ге 1.1, либо определяется по умолчанию в соответствии с параметрами систем- ной базы данных Model. При этом предполагается, что файл имеет объем свободного простран- ства, достаточный для функционирования базы данных в течение некоторого периода времени, а когда свободного места в файле не остается, сервер запра- шивает у файловой системы дополнительный сегмент дискового пространства и файл увеличивается в размере. Каждый файл базы данных характеризуется рядом параметров, значения которых хранятся в системной таблице SysFiles этой базы данных: • File_ID — внутренний идентификатор файла, уникальный в пределах базы данных; автоматически присваивается сервером файлу при его создании, используется как элемент адресной ссылки на страницу данных и/или на строку таблицы; выполняет роль первичного ключа таблицы SysFiles; • File_name — имя файла в файловой системе, задается в стандартном формате (том:\путь\имя.расширение); • Name — логическое имя файла (синоним File_name); • Size — текущий размер файла (объем дисковой памяти, зарезервиро- ванной сервером баз данных у файловой системы), может автоматически изме- няться в процессе эксплуатации базы данных; • MaxSize — максимально допустимый размер файла, может иметь зна- чение unlimited, в этом случае размер файла ограничивается ресурсами фай- ловой системы; • Growth increment — шаг приращения размера файла — дополнитель- ная «порция» дискового пространства, запрашиваемая сервером у файловой си- стемы, когда текущий размер файла становится недостаточным для хранения данных, может задаваться в абсолютных размерных единицах или в процентах от текущего размера файла; • Group_ID — внутренний идентификатор файловой группы, к которой принадлежит этот файл, выполняет роль внешнего ключа, обеспечивающего связь (M:1) между системными таблицами SysFiles и SysFileGroups. Группы файлов Для удобства администрирования и повышения эффективности хранения данных файлы типа data могут быть (логически!) распределены по файловым группам. В каждой базе данных по умолчанию создается единственная файло- 11 / 19 145 вая группа, имеющая статус первичной (primary file group), при этом админи- стратор может создавать дополнительныефайловые группы, каждая из которых получает статус вторичной (secondary file group). Формируются вторичные файловые группы с помощью ключевого слова FILEGROUP в SQL-инструкциях CREATE DATABASE и ALTER DATABASE. Первичный файл всегда принадлежит первичной файловой группе, вто- ричный файл может принадлежать как первичной, так любой из вторичных файловых групп. Файл не может одновременно входить в состав нескольких файловых групп. Примечание 1. Файловая группа является логической надстройкой над файловой структурой базы данных: принадлежность файла определенной файловой группе не накладывает никаких ограничений на его физическое раз- мещение в дисковом пространстве вычислительной системы. Примечание 2. Файл журнала транзакций (.ldf) не принадлежит ни одной из файловых групп базы данных. Каждая файловая группа характеризуется рядом параметров, значения которых хранятся в системной таблице SysFileGroups базы данных: • Group_ID — внутренний идентификатор файловой группы, уникаль- ный в пределах БД, автоматически присваивается сервером при создании груп- пы, выполняет роль первичного ключа системной таблицы SysFileGroups; • Group_name — имя файловой группы, используется в операторах Create Table и Create Index для явного указания файловой группы, в файлах которой должны сохраняться данные таблицы или индекса. Первичная файло- вая группа всегда имеет имя PRIMARY; • Default — присваивает группе статус «группа по умолчанию»: – из множества групп только одна группа может иметь такой статус; – если этот параметр явно не указан ни для одной из групп, группой по умолчанию будет назначена первичная группа; – при создании нового файла в базе данных он будет ассоциирован с группой по умолчанию, если иное явно не указано; – при создании новой таблицы в базе данных она будет ассоциирована с группой по умолчанию, если иное явно не указано, и все данные этой таблицы будут физически размещены в файлах этой группы; • Read Only — присваивает группе статус «только для чтения»; если таблица базы данных ассоциирована с такой группой, для этой таблицы будет заблокирована возможность модификации данных. Приведенный ниже листинг 4.10 иллюстрирует языковые средства (TransactSQL) управления файловой структурой баз данных и содержит пакет из 4 последовательных SQL-инструкций. Инструкция CREATE DATABASE создает пользовательскую базу данных MyDB, содержащую первичный файл данных в первичной файловой группе, пользовательскую файловую группу FG1, содержащую два вторичных файла, и файл журнала (вне файловых групп). Инструкция не устанавливает свойство 12 / 19 146 DEFAULT ни одной из файловых групп, в результате чего статус «группа по умолчанию» получает первичная файловая группа. Инструкция CREATE TABLE создает в базе данных таблицу MyTable, явно ассоциированную с пользовательской файловой группой FG1 (а не с первичной группой, имеющей к этому моменту статус «группа по умолчанию»). Инструкция ALTER DATABASE модифицирует структуру базы данных MyDB и придает файловой группе FG1 статус «группа по умолчанию». Последняя инструкция CREATE TABLE создает в базе данных еще одну таблицу MyTable1, также (неявно) ассоциированную с пользовательской фай- ловой группой FG1, имеющей к этому моменту статус «группа по умолчанию». USE master; CREATE DATABASE MyDB ON PRIMARY (NAME='Primary_F',FILENAME='C:\data\Prm.mdf', SIZE=4MB, MAXSIZE=10MB,FILEGROWTH=1MB), FILEGROUP FG1 (NAME = 'Dat1',FILENAME = 'D:\data\FG1_1.ndf', SIZE = 1MB, MAXSIZE=5MB, FILEGROWTH=1MB), (NAME = 'Dat2',FILENAME = 'E:\data\FG1_2.ndf', SIZE = 15MB, MAXSIZE=50MB, FILEGROWTH=1MB) LOG ON (NAME='MyDB_log',FILENAME = 'C:\data\MyDB.ldf', SIZE=1MB,MAXSIZE=10MB, FILEGROWTH=1MB); USE MyDB; CREATE TABLE MyTable(ID int PRIMARY KEY, Data char(8)) ON FG1; ALTER DATABASE MyDB MODIFY FILEGROUP FG1 DEFAULT; CREATE TABLE MyTable1 (ID int, Name char(16)); Листинг 4.10 Создание и модификация файловой структуры базы данных 11.1.2. Файловые страницы и экстенты Основным объектом файловой модели базы данных является файл типа DATA, ассоциированный с некоторой файловой группой. База данных может со- держать несколько таких файлов, главное назначение которых — хранение экзем- пляров объектов логической модели данных (например, строк таблиц) для их по- следующего извлечения в соответствии с поступившими серверу SQL-запросами. При создании новой таблицы она будет связана с одной из файловых групп: или явной ссылкой на имя файловой группы в SQL-инструкции CREATE TABLE, или неявно — с группой, имеющей в этот момент статус «группа по умолчанию». В любом случае при вставке строк в таблицу серверу баз данных потребуется решать задачу поиска свободного пространства в файлах, вклю- ченных в соответствующую файловую группу, и задачу эффективного распре- 13 / 19 147 деления строк таблицы между этими файлами с сохранением соответствующей адресной информации, необходимой для последующего поиска строк таблицы. Листинг 4.11 иллюстрирует задачу поиска свободного пространства в файлах базы данных и задачу поиска строк заданной таблицы, удовлетво- ряющих определенному условию. USE Master CREATE DATABASE MyDB ON PRIMARY (NAME='MyDB_Primary',FILENAME='C:\Prm.mdf'), FILEGROUP FG1 (NAME = 'MyDB_Dat1',FILENAME='D:\F1.ndf', SIZE = 2MB, MAXSIZE=5MB, FILEGROWTH=1MB), (NAME = 'Dat2',FILENAME='E:\F2.ndf', SIZE = 15MB, MAXSIZE=50MB, FILEGROWTH=5MB); USE MyDB CREATE TABLE MyTable (Key_0 INT IDENTITY,Key_1 INT,Key_2 INT, FullName CHAR(60)) ON FG1; DECLARE @key0 INT, @key1 INT, @key2 INT, @name CHAR(60) SET @key1=1000*RAND(),@key2=1000*RAND() SET @name=STR(@key1)+STR(@key2) INSERT INTO MyTable values(@key1,@key2,@name) Go 10000 SELECT key_1, FullName INTO NewTable FROM MyTable WHERE Key_2>500; Листинг 4.11 Пример выборки и вставки строк в таблицы Пакет содержит четыре последовательных SQL-инструкции. Инструкция CREATE DATABASE создает пользовательскую базу данных, содержащую три файла: один файл в первичной файловой группе и два фай- ла — во вторичной группе FG1. Инструкция не содержит явного указания на группу со статусом DEFAULT, следовательно, группой по умолчанию будет счи- таться первичная файловая группа. Инструкция CREATE TABLE создает таблицу MyTable, явно ассоциирован- ную со вторичной группой FG1. Следующая инструкция INSERT INTO вставляет в таблицу MyTable 10 000 строк, заполняя их случайными данными. Последняя инструкция SELECT … INTO производит выборку из таблицы MyTable тех ее строк, которые удовлетворяют заданному условию, и вставку выбранных строк в новую таблицу NewTable. Вставка строк в таблицу MyTable потребует поиска свободного простран- ства в двух вторичных файлах группы FG1, а строки таблицы NewTable будут 14 / 19 148 записаны в единственный первичный файл первичной файловой группы, так как именно эта группа имеет статус DEFAULT. Очевидно, что для реализации алгоритмов поиска свободного простран- ства в файле и алгоритмов поиска строк таблиц, сохраненных в файле, необхо- димо определить информационную структуру самого файла и предусмотреть наличие служебных структур данных, обеспечивающих хранение адресной ин- формации. Файловые страницы Базовым элементом файла типа DATA является файловая страница. Сервер баз данных представляет файл типа DATA как линейный список из страниц фиксированного размера (по 8 Кб), которые последовательно (позици- онно) пронумерованы, начиная с нулевой страницы 6 Таким образом, номер страницы PageNum однозначно определяет ее по- зицию внутри файла: смещение (в килобайтах) от начала файла до начала стра- ницы вычисляется как 8*PageNum. Учитывая тот факт, что файлы базы данных тоже пронумерованы и каж- дый из них при регистрации получил свой уникальный идентификатор FileID, сохраненный в системной таблице SysFiles, агрегат SysFiles.PageNum однознач- но определяет адрес страницы в файловой структуре базы данных. Страница является минимальным объектом физической модели данных, который может быть выделен сервером логическому объекту, при этом один логический объект (например, таблица) может быть владельцем одной или не- скольких страниц одного или нескольких файлов, а одна страница не может иметь более чем одного владельца. Из сказанного, в частности, следует, что номера страниц, владельцем ко- торых является таблица базы данных, могут использоваться в качестве адрес- ных ссылок, используемых для поиска и выборки всех строк этой таблицы. Экстенты Если страница является «единицей занятости» файла данными логиче- ских объектов, то для хранения информации о свободном пространстве файлов используется другая, более крупная единица, называемая экстентом. Экстент имеет фиксированный размер 64 Кб и представляет собой блок из восьми со- седних страниц одного файла. Экстенты, так же как и страницы, последовательно пронумерованы в пре- делах файла, начиная с нулевого экстента. При этом номер экстента ExtNum и номера входящих в него страниц PageNum связаны простой арифметической зависимостью. Например, страница 18 принадлежит экстенту № 2, а экстент № 5 включает страницы с 40-й по 47-ю. Сервер баз данных может присвоить экстенту статус однородного (uniform) или смешанного (mixed, shared): смешанный экстент может совмест- 6 На уровне файловой системы файл может быть фрагментирован, однако на уровне файло- вой модели этот факт игнорируется, и с точки зрения сервера баз данных файл — это нераз- рывная цепочка последовательно расположенных и позиционно пронумерованных страниц. 15 / 19 149 но использоваться разными владельцами страниц, а владельцем всех восьми страниц однородного экстента является какой-либо один логический объект ба- зы данных (рис. 4.3). Рис. 4.3 Схема размещения файловых страниц в смешанных и однородных экстентах Очевидно, что для небольших таблиц эффективнее оперировать смешан- ными экстентами, иначе некоторые страницы однородных экстентов всегда бу- дут оставаться незанятыми. С другой стороны, что также очевидно, наличие однородных экстентов ускоряет работу алгоритмов поиска данных в таблицах большого объема (от 64 Кб), так как в этом случае адрес (порядковый номер) какой-либо одной страницы, принадлежащей логическому объекту, фактически определяет и адреса еще семи страниц этого же объекта. Совсем не очевидна логика сервера баз данных, принимающего решение о выделении логическому объекту экстентов того или иного типа — исследова- нию этого вопроса посвящено одно из заданий практикума по администрирова- нию (п. 14.2.2). Типы файловых страниц Перечень типов страниц, поддерживаемых MS SQL-Server, приведен в таблице 4.6. Страницы типа Data/Index — основной тип файловых страниц, предна- значенных для хранения экземпляров логических объектов — строк таблиц ба- зы данных, а также строк индексных таблиц, подобных по своей структуре классическим реляционным таблицам. Упрощенная схема хранения данных в странице типа Data/Index иллюстрируется рисунком 4.4. Все пространство страницы (8 Кб) разделено на три области: – заголовок страницы — начальная область страницы, имеет фиксиро- ванный размер 96 байтов, содержит служебную информацию, специфическую для страниц различных типов; – тело страницы — основная область страницы (максимум 8060 байт), содержит множество контейнеров («слотов»), каждый из которых предназначен для хранения одной строки таблицы; – хвостовик страницы — конечная область страницы переменной длины (минимум 36 байт), содержит массив указателей на слоты тела страницы (т. е., по существу, на строки таблицы). 16 / 19 150 Таблица 4.6 Типы файловых страниц Тип страницы Тип хранимой информации Data Данные логических объектов, кроме данных типов LOB (LargeOBjects) Index Данные индексов Text/Image • Данные «длинных» типов, экземпляры которых превышают размер файло- вой страницы: text, ntext, image, xml, nvarchar(max), varchar(max), varbinary(max). • Данные типов переменной длины varchar(), nvarchar(), varbinary(), sql_variant в условиях, когда размер строки на основной странице типа Data превышает размер 8060 байт IAM Index Allocation Map — битовая карта размещения страниц логического объ- екта по экстентам файла GAM, SGAM Global Allocation Map, Shared Global Allocation Map — глобальные битовые карты, содержащие информацию о свободных экстентах, их типах и степени заполнения PFS Page Free Space — информация о степени заполнения страниц BCM Bulk Changed Map (карта массовых изменений) — глобальная битовая карта, содержащая информацию об экстентах, измененных с момента последнего выполнения операции резервного копирования журнала транзакций DCM Differential Changed Map (карта разностных изменений) — глобальная битовая карта, содержащая информацию об экстентах, измененных с момента послед- него выполнения операции резервного копирования базы данных Рис. 4.4 Структура страницы типа DATA/INDEX Согласно канонам реляционной модели данных, все кортежи одного отно- шения (т. е. все строки одной таблицы) имеют одинаковую арность (количество атрибутов/столбцов), при этом соответствующие атрибуты кортежей содержат данные одного типа. Именно в этом смысле верно утверждение о «прямоуголь- ности» реляционных таблиц: действительно, все строки таблицы имеют (логиче- ски) одинаковую длину, равную сумме длин типов данных всех ее столбцов. Например, все строки таблицы MyTable (листинг 4.3) имеют одинаковую длину, равную 72 байтам (3*4 + 60), и эта таблица действительно является «пря- 17 / 19 151 моугольной» как на логическом уровне, так и на уровне физической модели дан- ных, так как для описания всех ее атрибутов были использованы типы данных по- стоянной длины, в том числе и строковый тип CHAR(60) для атрибута FullName. Скорее всего, использование типа CHAR(60) в данном случае было ошибочным, так как независимо от реальной длины текста атрибут FullName будет занимать ровно 60 байт в каждой строке таблицы. Было бы эффективнее (с точки зрения экономии памяти) использовать вместо CHAR(60) тип данных переменной длины VARCHAR(60), тогда затраты памяти на хранение экземпля- ров атрибута FullName будут минимальными, но таблица при этом потеряет свою «прямоугольность», что явно усложнит систему хранения адресов ее строк в файловых страницах типа DATA. Приведенная на рисунке 4.4 структура файловой страницы обеспечивает эффективную адресацию строк переменной длины. Массив указателей на слоты, расположенный в хвостовике страницы, со- держит целые числа, трактуемые как смещения от начала страницы до начала соответствующего слота. Первый элемент массива указателей всегда содержит число 96 — это указатель на первый слот, начинающийся по смещению 96 байт от начала страницы (сразу после ее заголовка). Когда страница пуста, все остальные указатели в этом массиве отсутствуют. При записи на страницу первой строки (длина которой, естественно, из- вестна) она помещается в первый слот, а в массив указателей заносится ссылка на начало второго слота (равное сумме длины записанной строки и числа 96). При записи второй и всех последующих строк сканируется (справа нале- во) массив указателей, определяется номер очередного еще не заполненного слота, этот слот заполняется, а в массив указателей заносится ссылка на начало следующего слота. Процесс заполнения страницы может продолжаться до тех пор, пока обе эти структуры (массив слотов и массив указателей на них) не «встретятся» — в этот момент страница получит статус заполненной на 100%. Если задан номер слота SlotNum, в котором размещена искомая строка таблицы, то адрес этого слота легко определяется прямым доступом к соответ- ствующему элементу массива указателей. Таким образом, адрес строки таблицы (RID — Row IDentifier) — это агре- гат SysFiles.PageNum, используемый для адресации страницы в файловой струк- туре базы данных, дополненный номером соответствующего слота страницы: RID = SysFiles.PageNum.SlotNum. Именно такие RID-адреса используются в ин- дексах для обеспечения прямого доступа к строкам таблиц, содержащих иско- мые значения ключевых полей таблицы. Страницы типа Text/Image используются для хранения «больших объек- тов» (LOB — Large Object) — значений столбцов таблиц, превышающих объем файловой страницы (длинных текстов, графических объектов с хорошим разре- шением и пр.). Если, например, столбец таблицы имеет один из таких типов дан- ных и при этом в какой-либо строке таблицы экземпляр данных этого типа имеет действительно большой объем, для хранения этого экземпляра выделяется от- дельная страница типа Text/Image, а в соответствующем слоте основной страницы 18 / 19 152 типа Data сохраняется указатель на эту страницу. Если для хранения экземпляра оказывается недостаточно одной страницы типа Text/Image, сервер дополни- тельно выделяет необходимое количество таких страниц, связывая их в линейный список специальными указателями (NextPage и PrevPage в заголовках страниц). Страницы типа Text/Image используются также для хранения данных типов переменной длины в условиях, когда размер строки на основной страни- це типа Data превышает максимально допустимый размер 8060 байт. Если в ре- зультате вставки или обновления данных в таблице размер строки выходит за указанный предел, происходит перемещение данных столбца на страницу типа Text/Image с сохранением указателя на эту страницу в соответствующем слоте основной страницы типа Data. Если в дальнейшем размер строки уменьшается, данные перемещаются обратно на исходную страницу типа Data. Страницы типа IAM (Index Allocation Map) формируются для каждого логического объекта базы данных (таблицы или индекса) в момент вставки в этот объект первого экземпляра данных. IAM-страница содержит информацию о номерах всех экстентов, содержащих страницы логического объекта, и пред- ставляет собой битовую карту размером около 8 Кб, в которой номер позиции каждого бита ассоциируется с номером экстента: если i-й экстент файла со- держит хотя бы одну страницу, владельцем которой является логический объ- ект, то в IAM-странице этого объекта IAM[i] = 1. Нетрудно подсчитать, что одной IAM-страницы будет достаточно для представления таблицы объемом около 4 Гб. Если таблица имеет больший раз- мер, она получит дополнительные IAM-страницы, связанные в линейный спи- сок указателями NextPage и PrevPage в заголовках этих страниц. Если известен номер первой IAM-страницы, владельцем которой является таблица базы данных, легко определить номера всех используемых таблицей экстентов и получить доступ к страницам и строкам этой таблицы — именно такой подход и реализуется в низкоуровневом методе TableScan(), используе- мом для выборки строк из некластеризованных таблиц. Страницы типов GAM (Global Allocation Map)и SGAM (Shared Global Allocation Map) содержат глобальные битовые карты (объемом около 8000 байт), в которых каждый бит несет определенную информацию о соответству- ющем экстенте файла. Битовая карта GAM содержит информацию о свободных или занятых экс- тентах: если GAM[i] = 1, то i-й экстент свободен, в противном случае хотя бы одна страница этого экстента занята. Битовая карта SGAM содержит информацию о типах экстентов и степени их заполнения: если SGAM[i] = 1, то i-й экстент используется как смешанный и при этом имеет хотя бы одну свободную страницу; в противном случае этот экстент либо является однородным, либо смешанным, но полностью занятым. Таким образом, двухбитовый код i-го экстента (GAM[i],SGAM[i]) несет информацию о его типе и степени заполнения (табл. 4.7), что позволяет серверу реализовывать несложные алгоритмы поиска свободного пространства при вставке строк в таблицы базы данных: 19 / 19 153 – если GAM[i] = 1, то i-й экстент свободен, его тип еще не определен и значение бита SGAM[i] может быть любым; – если серверу требуется свободный однородный экстент (например, для массового заполнения строк большой таблицы), производится поиск GAM[i] = 1 и после заполнения этого экстента для него устанавливается GAM[i] = 0 и SGAM[i] = 0; – для поиска смешанного экстента со свободными страницами сканиру- ются обе битовые карты, и выбирается экстент с кодом (0;1). После 100%-ного заполнения выбранного экстента для него устанавливается SGAM[i] = 0; – при отсутствии смешанного экстента со свободными страницами выби- рается свободный экстент (GAM[i] = 1), после его частичного заполнения уста- навливаются GAM[i] = 0 и SGAM[i] = 1. В результате этот экстент получит ста- тус смешанного экстента, имеющего свободные страницы; – при освобождении i-го экстента (например, в результате массового уда- ления строк соответствующих таблиц) для него устанавливается GAM[i] = 0, и он получает статус свободного экстента. Пара страниц GAM/SGAM описывает файл размером около 4 Гб. Для файлов большего размера формируются дополнительные пары GAM/SGAM- страниц, связанные в линейные списки указателями NextPage и PrevPage в заго- ловках соответствующих страниц. Таблица 4.7 Кодирование состояний экстентов Состояние i-го экстента GAM [i] SGAM [i] Свободен, в текущий момент не используется 1 0 Однородный или заполненный смешанный 0 0 Смешанный со свободными страницами 0 1 Страницы типа PFS (Page Free Space) предназначены для хранения ин- формации о степени заполнения страниц файла базы данных. Тело PFS-страницы состоит из единственного слота размером 8092 байта, содержимое которого трактуется как числовой массив байтового типа, каждый элемент которого PFS[i] представляет 8-битовый код i-й страницы файла. Младшие 4 бита этого кода определяют степень заполнения соответствующей страницы (табл. 4.8), а стар- шие биты кода несут дополнительную информацию о странице (например, о ее типе и принадлежности смешанному или однородному экстенту). Таблица 4.8 Кодирование степени заполнения страниц Состояние i-й страницы PFS[i] Страница не занята 0 Страница заполнена от 1 до 50% 1 Страница заполнена от 51 до 80% 2 Страница заполнена от 81 до 95% 3 Страница заполнена от 96 до 100% 4 1 / 19 154 Одна PFS-страница описывает файл размером чуть меньше 64 Мб. Для файлов большего размера выделяется необходимое количество дополнитель- ных PFS-страниц, образующих линейный список с помощью указателей NextPage и PrevPage в заголовках этих страниц. На рисунке 4.5 представлена типовая структура нулевого экстента файла: нулевая страница — это заголовок файла, первая из PFS-страниц файла всегда имеет порядковый номер «1», затем расположены другие служебные страницы, и далее — все остальные страницы файла. Рис. 4.5 Стандартное расположение служебных страниц в начальной области файла 11.2. Средства управления физической моделью данных Информация о принадлежности файловых страниц логическим объектам базы данных и об адресах этих страниц содержится в системной таблице SysIndexes, входящей в состав системного каталога базы данных. Каждая строка этой таблицы представляет один логический объект (таблицу или индекс), поля First, Root и FirstIAM содержат идентификаторы («адреса») соответственно первой страницы типа Data (для объектов-таблиц), корневой индексной страницы (для объектов-индексов) и первой IAM-страницы (для любых логических объектов). Идентификатор страницы ID_Page хранится в формате BINARY(6) и пред- ставляет собой агрегат из двух чисел, в котором младшие два байта представ- ляют идентификатор файла (ID_File), а старшие четыре байта — порядковый номер страницы (PageNum) в этом файле: ID_Page = ID_File.PageNum. Хранимая процедура sp_spaceused принимает имя таблицы и возвращает пять ее параметров: количество строк (rows), общий объем (в килобайтах) заре- зервированного дискового пространства (reserved), в том числе занятого стра- ницами данных (data), индексными (включая IAM) страницами (index_size) и неиспользуемыми (unused) страницами, расположенными в однородных ча- стично заполненных экстентах. Команда EXTENTINFO системной утилиты DBCC позволяет получить более детальную информацию о страницах, занятых данными таблицы и всеми ее ин- дексами: номера страниц, степень их заполнения и количество страниц в экс- тентах. Команда DBCC PAGE позволяет получить информацию о содержимом страницы и отображает данные ее заголовка, содержимое всех слотов и массив указателей на строки таблицы (рис. 4.4). 2 / 19 155 Листинг 4.12 содержит пакет SQL-инструкций, иллюстрирующих исполь- зование средств анализа структуры файла базы данных, а на рисунке 4.6 приве- ден результат выполнения первых трех инструкций этого пакета. USE MyDB_2 SELECT ID,IndID,root,first,firstiam FROM sysindexes WHERE ID=Object_ID('MyTable_6') GO EXEC sp_spaceused MyTable_6 GO DBCC EXTENTINFO(MyDB_2,MyTable_6,-1) GO DBCC TRACEON (3604) DBCC PAGE ('MyDB_2'1,1,2) GO Листинг 4.12 Пример использования средств анализа структуры файла базы данных Рис. 4.6 Результат выполнения листинга 4.12 11.3. Алгоритм доступа к неупорядоченным данным Вспомним, что реляционная модель данных не гарантирует упорядочен- ности расположения строк в таблице, и если пользователю необходимо пред- ставить выборку данных, отсортированную по значениям ее столбцов, то про- граммист должен явно указать на это в разделе Order By соответствующего SQL-запроса. 3 / 19 156 На уровне физической модели данных строки реляционной таблицы хра- нятся в файловых страницах типа DATA, объединенных (по умолчанию) в структуры типа куча (heap), при этом файловые страницы, принадлежащие од- ной таблице, могут располагаться в произвольных местах файла (или несколь- ких файлов) базы данных. Информация о принадлежности групп файловых страниц (экстентов) определенной таблице хранится в специальной IAM-странице, также принад- лежащей таблице, а номер IAM-страницы хранится в системном каталоге базы данных (рис. 4.7). Рис. 4.7 Упрощенная схема доступа к данным типа куча методом последовательного сканирования В условиях отсутствия дополнительной информации адресного характера единственным методом поиска в куче строк таблицы, удовлетворяющих задан- ному критерию отбора (диапазону значений указанных в запросе столбцов), яв- ляется метод последовательного сканирования кучи (TableScan), работающий по следующему алгоритму: – чтение системного каталога, определение номера IAM-страницы; – загрузка IAM-страницы, определение номеров экстентов, включающих файловые страницы, принадлежащие таблице; – последовательная загрузка каждой страницы выбранных экстентов в оперативную память; – выполнение циклической процедуры сравнения значений столбцов с критерием отбора в каждой загруженной странице; – формирование результирующей выборки. Стоимость такого метода весьма высока, она пропорциональна количе- ству занятых таблицей страниц и не зависит от степени селективности предика- та выборки. Например, единственная строка таблицы, удовлетворяющая крите- рию поиска, может оказаться как в первой, так и в последней странице, но в любом случае придется просканировать все страницы, принадлежащие таблице. 4 / 19 |