СОДЕРЖАНИЕ

1.	СОВЕТЫ
1.1.	Резервное копирование баз данных SQL Server 2000
1.2.	Распределенные секционированные представления MS SQL Server
2.	ССЫЛКИ НА СТАТЬИ
2.1.	Статьи на русском языке
2.2.	Англоязычные статьи
3.	ПОЛЕЗНОСТИ
3.3.	Оптимизация баз данных: принципы, практика, решение проблем
3.3.	Анализ данных. Генератор отчетов Crystal Reports

СОВЕТЫ

Резервное копирование баз данных SQL Server 2000.
Автор: Ирина Наумова

Порядок создания резервной копии.

Создание полной резервной копии файла данных происходит следующим образом:

• Производится копирование данных из базы на устройство резервного копирования. При этом пользователи могут работать с базой, исключая операции ALTER DATABASE с опциями ADD FILE и REMOVE FILE, операции сжатия базы данных либо отдельных ее файлов такие как SHRINKFILE, SHRINKDATABASE, в том числе и автоматическое сжатие. Все изменеия, вносимые в процессе резервного копирования сохраняются в журнале.
• Копируется часть журнала транзакций, необходимая (roll forward), включая и записи об операциях, выполнявшихся в ходе резервного копирования.

При создании дифференциальной копии на устройство копируются только изменения в базе, произошедшие с момента создания последней полной резервной копии, для того, чтобы установить эти изменения используется Differential Changed Map (DCM). Это битовая карта, каждый бит которой, установленный в 1, говорит о том, что в данном экстенте были изменения с момента последней полной копии, соответственно при значении 0 – изменений не было.
Также, в модели Bulk-Logged, добавляется еще страница Bulk Changed Map (BCM), это тоже битовая карта, которая определяет те экстенты, в которых массовые операции произвели изменения с момента последнего резервного копирования журнала транзакций. Когда выполняется операция BACKUP LOG (резервирование журнала транзакций), сканируются страницы BCM. В моделях Full и Simple BCM не используются, поскольку при Full в журнале ведется полное протоколирование массовых операций, а при Simple они не протоколируются вовсе.
Страницы DCM и BCM определяют по 64000 экстентов, и в файле они физически расположены за страницами GAM(Global Allocation Map) и SGAM(Shared Global Allocation Map).
Таким образом время выполнения дифференциального бэкапа прямо пропорционально количеству измененных экстентов с момента последней полной копии и не зависит от размера базы данных.
При копировании файлов или файловых групп, копируются только данные, журнал не копируется. Дифференциальную копию отдельных файлов или файловых групп возможно делать только в случае если модель резервирования Full или Bulk-Logged.
При создание копии журнала транзакций выполняется копирование лишь той части журнала, которая еще не была скопирована на устройство резервного копирования.

[В начало]

Media set и media family.

При создании резервной копии SQL Server позволяет использовать несколько устройств резервного копирования одновременно. При этом резервная копия распределяется среди нескольких носителей. Необходимо, чтобы все устройства относились к одному типу носителей. Например нельзя использовать ленту и диск одновременно для создания резервной копии.
Распараллеливание процесса копирования позволяет увеличить скорость копирования и тем самым уменьшить время на создание резервных копий.
Результат выполнения одной операции резервного копирования – резервный набор.
Совокупность носителей (лент/файлов), которые используются для создания резервной копии, называется набором (media set).
Совокупность резервных копий, которые при создании резервной копии записывались одним устройством резервного копирования (при использовании НМЛ), называются семейством лент (Media family). В случае, если используется дисковый накопитель, семейством является отдельный файл.
Например, если для создания резервной копии используются четыре ленточных устройства (стриммера), каждый из которых содержит по пять лент, то набор содержит 20 лент. А набор лент, содержащих бэкап на отдельном устройстве, является семейством, т.е. для данного примера семейство будет состоять из пяти лент.
Теперь рассмотрим пример, где для создания резервной копии используется несколько файлов.
Создадим полную резервную копию базы данных test, состоящей из 4-х файлов:

test.mdf,
test1.ndf,
test_log, ldf,
test_log1.ldf

todisk='c:\1.bak',disk='d:\2.bak',disk='e:\3.bak'  with init

Для данного примера:

1.bak - family 1, media 1
2.bak - family 2, media 1
3.bak - family 3, media 1

т.е. все эти три файла представляют собой один набор носителей (media) и каждый из файлов представляет отдельное семейство носителей (family).
При записи резервных копий на ленточный накопитель, первая лента в семействе называется инициализирующей (Initial media). В случае если создаваемая резервная копия не помещается на инициализирующую ленту, используются дополнительные ленты (Continuation media).
Носители из набора (конктретный файл или ленту, если их несколько в семействе) нельзя использовать для создания резервной копии по отдельности. Т.е. например, если рассмотреть пример выше, то резервную копию нельзя поместить только в один из файлов 1.bak, 2.bak, 3.bak, теперь для этих целей можно использовать только весь набор из трех файлов, либо удалить файлы и создать новый набор.
Также информацию об использовании наборов устройств резервного копирования можно получить в статье BOL "Using Media Sets and Families"
Перед тем, как поместить данные на устройство резервного копирования, оно инициализируется и форматируется если создается впервые, на устройство помещается заголовок. При повторном использование этого же устройства при выборе опции INIT происходит перезапись всех уже существующих копий, содержащихся на этом устройстве, при выполнении следующих условий:

• резервный набор устарел (истекла дата, которая была задана в параметре EXPIREDATA или RETAINDAYS при создании копии)
• указанное в параметре MEDIANAME имя носителя (если оно указано), совпадает с именем, записанным в заголовке носителя.
• не задан параметр SKIP, который отменяет проверку выполнения предыдущих пунктов.

Заголовок носителя сохраняется, но все имеющиеся на нем резервные наборы перезаписываются. Новый резервный набор помещается в начало носителя.

При выборе опции FORMAT происходит перезапись заголовков на каждом носителе, на который записывается резервный набор. Весь набор резервных копий, записанный на этом носителе, становится недоступным. Если резервный набор записывался на несколько носителей, то после перезаписи заголовка на одном из них, резервный набор также становится недоступным.

Системные таблицы

Вся хронология создания резервных копий хранится в базе данных msdb, в следующих таблицах:

backupfile
backupset
backupmediafamily
backupmediaset

[В начало]

backupfile

Содержит по одной строке для каждого файла данных и файла журнала транзакций.
Т.е. если например база данных состоит из двух файлов данных и двух файлов журнала транзакций (test.mdf, test1.ndf, test_log, ldf, test_log1.ldf), то заполнение строк таблицы будет выглядеть следующим образом:

Полная копия	Дифференциальная копия	Копия отдельных файлов или файловых групп	Копия журнала транзакций
4 строчки для каждого из файлов: test.mdf, test1.ndf, test_log, ldf, test_log1.ldf	2 строчки для файлов данных: test.mdf, test1.ndf	по одной строчке для каждого копируемого файла	2 строчки для файлов журнала: test_log, ldf, test_log1.ldf

Теперь рассмотрим поля таблицы и их значения.

Поле	Тип данных	Описание
backup_set_id	int NOT NULL REFERENCES backupset(backup_set_id)	Идентификатор резервной копии в наборе всех резервных копий. Ссылка на backupset.backup_set_id
first_family_number	tinyint NULL	Номер первого файла/ленты в семействе носителей, на которых содержится резервная копия.
first_media_number	smallint NULL	Номер первого файла/ленты в наборе носителей, на которых содержится эта резервная копия.
filegroup_name	nvarchar(128) NULL	Для резервной копии файла данных - имя файловой группы, к которой принадлежит файл данных. Для резервной копии журнала транзакций - NULL.
page_size	int NULL	Размер страницы в байтах. Для резервной копии файла данных - 8 192 (страница данных 8 кб * 1024), для копии файла журнала транзакций - NULL.
file_number	numeric(10,0) NOT NULL	Уникальный идентификатор резервируемого файла (FILE_ID), его можно посмотреть в таблице sysfiles базы данных.
backed_up_page_count	numeric(10,0) NULL	Общее число страниц, участвовавших в создании резервной копии.
file_type	char(1) NULL	'D' - для файла базы данных 'L' - для файла журнала транзакций
source_file_block_size	numeric(10,0) NULL	Размер блока при считывании данных из источника, где содержатся резервируемые данные.
file_size	numeric(20,0) NULL	Размер резервируемого файла в байтах. Можно узнать так: select size*8*1024,name from test..sysfiles
logical_name	nvarchar(128) NULL	Логическое имя файла, для которого создается резервная копия. Определяется полем name таблицы sysfiles текущей БД.
physical_drive	varchar(260) NULL	Имя устройства или раздела диска, на котором содержатся резервируемые данные. Например C:\
physical_name	varchar(260) NULL	Физическое имя резервируемого файла, например C:\Data\Test_data.mdf

[В начало]

backupset

Содержит по ожной строке для каждого файла резервного набора.

Название поля	Тип данных	Описание
backup_set_id	int NOT NULL IDENTITY PRIMARY KEY	Уникальный идентификатор резервной копии в наборе всех копий.
backup_set_uuid	uniqueidentifier NOT NULL	Уникальный идентификатор резервной копии, определяющий набор резервных копий на носителе. Это будет значение поля MediaFamilyId в результирующем наборе, полученном при помощи RESTORE LABELONLY
media_set_id	int NOT NULL REFERENCES backupmediaset (media_set_id)	Ссылка на поле media_set_id таблицы backupmediaset
first_family_number	tinyint NULL	Номер первого файла / ленты в семействе, на котором содержится начало резервной копии.
first_media_number	smallint NULL	Номер носителя в наборе носителей, на котором содержится начало резервной копии.
last_family_number	tinyint NULL
last_media_number	smallint NULL	Номер носителя в наборе носителей, на котором содержится окончание резервной копии.
catalog_family_number	tinyint NULL	Номер семейства, содержащего указатель на начало резервного набора
catalog_media_number	smallint NULL	Номер носителя, содержащего указатель на начало резервного набора
position	int NULL	Если резервные копии не перезаписываются, а добавляются в файл (опция NOINIT в операторе Backup), это значение показывает порядковый номер текущей копии в общем файле, содержащем несколько копий. Напимер, если мы сделали сначала резервную копию файла данных базы test в файл c:\test.bak, а затем копию журнала транзакций базы test в тот же файл c:\test.bak c опцией NOINIT, то для копии файла данных значение position будет =1, а для журнала =2 Это значение используется при восстановлении данных.
expiration_date	datetime NULL	Это значение заполняется в случае использования опции EXPIREDATE или RETAINDAYS оператора BACKUP и указывает дату и время, по прошествии которого резервную копию можно перезаписать.
software_vendor_id	int NULL	Идентификационный номер поставщика программного обеспечения, с помощью которого осуществляется запись заголовков на носитель. Для MS SQL Server это значение равно 4 608 в десятичной или 0х1200 в шестнадцатеричной системе счисления.
name	nvarchar(128) NULL	Имя резервной копии, задается параметром NAME оператора BACKUP, если не задано, присваивается значение NULL
description	nvarchar(255) NULL	Описание резервного набора, задается параметром DESCRIPTION оператора BACKUP, если не задано, присваивается NULL
user_name	nvarchar(128) NULL	Имя пользователя, производившего эту операцию резервного копирования.
software_major_version	tinyint NULL	select serverproperty('ProductVersion') Дает следующий результат: 'major.minor.build'
software_minor_version	tinyint NULL	см. software_major_version. SQL Server minor version number.
software_build_version	smallint NULL	см. software_major_version. SQL Server build number.
time_zone	smallint NULL	Часовой пояс. Разница между локальным временем на машине где производилась операция резервного копирования, и мировым стандартом координатного времени (Universal Coordinated Time) в 15-минутных интервалах. Значение может находиться в диапазоне -48 .. +48. 127 соответствует неопределенному значению. Например, для русского стандарта времени это значение будет 12, получается оно следующим образом: 3*4=12, где 4 - количество 15-минутных интервалов в одном часе, 3 - разница между UDT и Russian Standard Time. Эту разницу можно увидеть если дважды щелкнуть мышью по часам в трее или в панели управления в виде: (GMT +03:00) Москва,Санкт-Перербург,Волгоград.
mtf_minor_version	tinyint NULL	Номер первой версии Microsoft Tape Format.
first_lsn	numeric(25,0) NULL	LSN& первой или самой "старой" записи журнала транзакций в резервном наборе.
last_lsn	numeric(25,0) NULL	LSN последней или "новейшей" записи в резервном наборе.
checkpoint_lsn	numeric(25,0) NULL	LSN записи , где хранится информация о запуске процесса восстановления(recovery).
database_backup_lsn	numeric(25,0) NULL	LSN записи, в которой хранится информация о последней операции полного резервного копирования.
database_creation_date	datetime NULL	Дата и время создания базы данных. Можно посмотреть так: select crdate from master..sysdatabases where name='test'
backup_start_date	datetime NULL	Дата и время начала операции резервного копирования
backup_finish_date	datetime NULL	Дата и время окончания операции резервного копирования
type	char(1) NULL	Тип резервной копии: D = полная резервная копия I = дифферинциальная резервная копия. L = копия журнала транзакций F = копия отдельных файлов или файловых групп
sort_order	smallint NULL	Порядок сортировки, определяется текущей коллацией.
code_page	smallint NULL	Кодовая страница. Можно посмотреть так: select collationproperty(cast(databasepropertyex('test','collation') as nvarchar(20)),'Codepage') если коллация для базы данных установлена по умолчанию, то нужно смотреть так: select collationproperty(cast(serverproperty('collation') as nvarchar(50)),'CodePage')
compatibility_level	tinyint NULL	Уровень совместимости для базы данных: 60 = SQL Server version 6.0. 65 = SQL Server 6.5. 70 = SQL Server 7.0 80 = SQL Server 8.0 (2000) Для более подробной информации смотрите sp_dbcmptlevel
database_version	int NULL	Версия базы данных. select databasepropertyex('test','version')
backup_size	numeric(20,0) NULL	Размер резервной копии в байтах.
database_name	nvarchar(128) NULL	Имя базы данных, для которой производилась операция резервного копирования.
server_name	nvarchar(128) NULL	Имя сервера SQL Server на котором выполнялась операция резервного копирования. SELECT CONVERT(char(20), SERVERPROPERTY('servername'))
machine_name	nvarchar(128) NULL	Имя компьютера.
flags	int NULL	Flag bits: 1 = Резервная копия содержит минимально протоколированные данные. Backup contains minimally logged data. 2 =  использовалась опция WITH SNAPSHOT. 4 = База данных доступна только для чтения при выполнении резервного копирования. 8 = База данных находится в режиме 'single user' при выполнении резервного копирования
unicode_locale	int NULL	Идентификатор страны для символов Юникода. select collationproperty(cast(serverproperty('collation') as nvarchar(10)),'LCID') Null для коллаций SQL Server.
unicode_compare_style	int NULL	Стиль сравнения для символов Юникода. select collationproperty(cast(serverproperty('collation') as nvarchar(10)),'ComparisonStyle')
collation_name	nvarchar(128) NULL	Имя коллации select cast(databasepropertyex('test','collation') as nvarchar(20))

[В начало]

backupmediafamily

Содержит по одной строке для каждого семейства носителей.

Название поля	Тип данных	Описание
media_set_id	int NOT NULL REFERENCES backupmediaset (media_set_id)	Ссылка на поле media_set_id таблицы backupmediaset
family_sequence_number	tinyint NOT NULL	Порядковый номер семейства в наборе носителей.
media_family_id	uniqueidentifier NULL	Уникальный идентификатор семейства носителей.
media_count	int NULL
logical_device_name	nvarchar(128) NULL	Имя устройства резервного копирования из таблицы master..sysdevices (поле logical_device_name), либо NULL для временного устройства. На значение этого поля влияет значение параметра TO < backup_device > [ ,...n] Если полный путь к файлу не проставлен в опции To < backup_device >, он проставляется по умолчанию Узнать путь по умолчанию для создания резервной копии можно так: xp_regread N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'BackupDirectory'
physical_device_name	nvarchar(260) NULL	Физическое имя устройства резервного копирования.
device_type	tinyint NULL	Тип устройства резервного копирования: Диск: 2 - временное. 102 - постоянное. Лента: 5 - временное. 105 - постоянное. Именованный канал: 6 - временное. 106 - постоянное.
physical_block_size	int NULL	Размер блока данных для записи на устройство резервного копирования, задается параметром BLOCKSIZE. Информация о допустимых размерах блока данных для конкретного устройства должна быть приведена в его документации. По умолчанию: Для дисковых устройств - 512 Для лент - 65536 Для именованного канала 65536

[В начало]

backupmediaset

Содержит по одной строке для каждого набора носителей.

Название поля	Тип данных	Описание
media_set_id	int IDENTITY PRIMARY KEY	Уникальный идентификатор набора устройств резервного копирования.
media_uuid	uniqueidentifier NULL	Номер устройства в наборе. При создании резервной копии на диске, это значение = NULL
media_family_count	tinyint NULL	Число семейств в наборе.
name	nvarchar(128) NULL	Название набора. Заполняется при использовании опции MEDIANAME.
description	nvarchar(255) NULL	Текстовый комментарий к набору устройств. Заполняется при использовании опции MEDIADESCRIPTION
software_name	nvarchar(128) NULL	Наименование программы, создавшей заголовок на носителе.
software_vendor_id	int NULL	Идентификационный номер поставщика программного обеспечения, с помощью которого осуществляется запись заголовков на носитель. Для MS SQL Server это значение равно 4 608 в десятичной или 0х1200 в шестнадцатеричной системе счисления.
MTF_major_version	tinyint NULL	Номер версии Microsoft Tape Format, использовавшийся для создания этого набора.

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

Пример вызова:

exec msdb..sp_delete_backuphistory '4-mar-2004 13:00:00'

удалит всю хронологию резервных копий, сделанных до 13:00:00 4 марта.
Если же Вам необходимо удалить историю за период, либо информацию о конкретной резервной копии, можно сделать следующее:

Получаем текст процедуры sp_delete_backuphistory следующим образом:

sp_helptext 'sp_delete_backuphistory'

Затем нетрудно догадаться как нужно изменить текст, чтобы его можно было использовать для получения нужного результата.

[В начало]

Оптимизация выполнения операции резервного копирования

Все файлы, выбранные для операции резервного копирования, ассоциированы с дисковыми устройствами, список которых можно посмотреть следующим образом: Select filename from sysfiles в текущей базе данных, с каждым дисковым устройством связывается свой процесс чтения, и для каждого устройства резервного копирования порождается свой процесс записи. При увеличении количества логических файлов для базы данных, увеличивается количество операций параллельного чтения, а при увеличении числа устройств резервного копирования, соответственно увеличивается количество операций параллельной записи.
Также количество операций параллельной записи увеличивается при увеличении количества устройств резервного копирования. При этом необходимо учитывать, что значение “max worker thread” в конфигурации сервера по умолчанию установлено равным 255. Если же общее количество рабочих процессов равняется этому значению, то SQL Server не может создать новый процесс и отказывает в соединении, но в некоторых случаях он может разделить один рабочий процесс между несколькими соединениями, и это приведет к тому, что резервное копирование/восстановление на несколько устройств не будет проходить в режиме параллельного считывания / записи, а соответственно снизится скорость резервного копирования/восстановления и необходимость использования нескольких устройств потеряет смысл. В этом случае необходимо предусмотреть чтобы значение этого параметра было установлено таким образом, чтобы этого количества хватило и на соединения к серверу и на процессы записи/чтения при резервном копировании/восстановлении. Но не следует без необходимости увеличивать значение этого параметра, т.к. это может привести к снижению производительности сервера.
Уменьшение времени на создания резервной копии можно добиться, если создавать резервную копию на локальный диск, а затем уже переносить эту копию по сети на другой компьютер или ленту для хранения. Восстановление с локального диска также проходит быстрее.
Если резервная копия создается на локальный ленточный накопитель, то лучше если этот накопитель использует собственный интерфейс SCSI, а не разделенный с дисковым массивом.
Для того чтобы убедиться, что операция резервного копирования или восстановления на диск проходит с оптимальной скоростью можно измерить следующие счетчики в Performance Monitor:

• SQL Server Backup Device Object: Device Throughput Bytes/sec - Определяет количество данных, скопированных, либо восстановленных в секунду. Если значение слишком мало, необходимо подумать над тем, чтобы увеличить эффективность системы ввода/вывода.
• Phisical Disk: %Disk Time - Это значение не должно превышать 55%. Если это значение превышает 90% длительное время при выполнении операций резервирования или восстановления, то это показывает что система ввода/вывода является узким местом. Для того, чтобы определить является ли узким местом физический диск, необходимо также оценить значения счетчиков %Disk Read Time и %Disk Write Time, чтобы понять является причиной появления узкого места считывание или запись.
• Phisical Disk Object: Avg. Disk Queue Length - Если значение этого счетчика длительное время превышает 2 для каждого диска в массиве, когда проходит процесс резервного копирования или восстановления, вероятно у Вас узким местом является этот дисковый массив.

[В начало]

Распределенные секционированные представления MS SQL Server. Часть 2

По материалам статьи Don Schlichting: MS SQL Server Distributed Partitioned Views Part 2
Перевод Виталия Степаненко

Во второй статье рассматривается использование распределенных секционированных представлений для операций вставки, обновления и удаления.

[В начало]

Введение

В 1 части был произведен обзор основ распределенных секционированных представлений, объединенных баз данных, и горизонтального секционирования. В качестве примеров были созданы связанный сервер, секционированная таблица и представление, использующее оператор UNION. Во второй части будет показан новый пример, демонстрирующий выражения DML (INSERT, UPDATE и DELETE).

[В начало]

Связи

Мы начнем с создания тестовой среды. Примеры будут создаваться на основе двух машин, на каждой из которых установлен SQL 2000 под Windows 2000. Хотя в наших примерах будут только две машины, те же самые правила подходят для трех и более.
Начните с создания взаимно связанных серверов: Server2 на первом сервере Server1, и Server1 на втором сервере Server2. Установите соединение с первым сервером Server1 как sa и выполните следующий код.

USE master
GO

EXEC sp_addlinkedserver
 @server = 'server2',
 @srvproduct = 'SQLServer OLEDB Provider',
 @provider = 'SQLOLEDB',
 @datasrc = 'InfoNet'

GO

EXEC sp_addlinkedsrvlogin 'server2', 'false', 'sa', 'sa', 'secret'

GO

SELECT *
FROM server2.pubs.dbo.authors

В результате должны быть возвращены все записи таблицы Authors. Установите соединение со вторым сервером Server2 как sa и выполните следующий код:

USE master
GO

EXEC sp_addlinkedserver
 @server = 'server1',
 @srvproduct = 'SQLServer OLEDB Provider',
 @provider = 'SQLOLEDB',
 @datasrc = 'dons13'
GO

EXEC sp_addlinkedsrvlogin 'server1', 'false', 'sa', 'sa', 'secret'
GO

SELECT *
FROM server1.pubs.dbo.authors

Объяснение вышележащего кода см. в 1 части.

[В начало]

Таблицы

После создания связанных серверов следующим шагом является создание тестовых таблиц. Представьте таблицу заказов, содержащую гигабайты истории продаж и снижающуюся производительность работы с этой таблицей. Мы разделим эту большую таблицу на две части. Первый сервер Server1 будет хранить продажи с порядковыми номерами меньше 1 000. Заказы с порядковыми номерами больше 1 000 будут храниться на втором сервере Server2.
Выполните следующие выражения на первом сервере Server1 в БД master для создания тестовой таблицы:

CREATE DATABASE test
GO

USE test
GO

CREATE TABLE [dbo].[OrdersUnder] (
 [ord_nbr] [int] NOT NULL ,
 [ord_date] [datetime] NOT NULL ,
 [cust_id] [int] NOT NULL,
 [amount] [money] NOT NULL  
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[OrdersUnder] WITH CHECK ADD 
 CONSTRAINT [PK_ord_nbr] PRIMARY KEY  CLUSTERED 
 (
  [ord_nbr]
 )  ON [PRIMARY] 
GO

ALTER TABLE [dbo].[OrdersUnder] WITH CHECK ADD 
 CONSTRAINT [CHK_Under] CHECK ([ord_nbr] <= 1000)
GO

На втором сервере Server2 код практически тот же. Меняются только название и ограничение:

CREATE DATABASE test
GO

USE test
GO

CREATE TABLE [dbo].[OrdersOver] (
 [ord_nbr] [int] NOT NULL ,
 [ord_date] [datetime] NOT NULL ,
 [cust_id] [int] NOT NULL,
 [amount] [money] NOT NULL  
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[OrdersOver] WITH CHECK ADD 
 CONSTRAINT [PK_ord_nbr] PRIMARY KEY  CLUSTERED 
 (
  [ord_nbr]
 )  ON [PRIMARY] 
GO

ALTER TABLE [dbo].[OrdersOver] WITH CHECK ADD 
 CONSTRAINT [CHK_Over] CHECK ([ord_nbr] > 1000)
GO

Необходимо отметить несколько пунктов. Во-первых, требуется ограничение CHECK. Оптимизатор запросов использует это ограничение, чтобы определить, на каком сервере расположены данные. Ограничение CHECK должно позволять данным храниться на одном, и только одном сервере.
Во-вторых, для выражений DML требуется первичный ключ. Выборка данных не требует наличия ключа. Но для операций вставки, обновления и удаления должен присутствовать первичный ключ. Однако первичный ключ не может быть создан на столбце с автоинкрементом. В этом случае будет выведена ошибка:

Server: Msg 4433, Level 16, State 4, Line 1
Cannot INSERT into partitioned view 'ViewName' 
   because table '[TableName]' has an IDENTITY constraint.

[В начало]

Представления

Следующее представление является простой выборкой данных с двух серверов в один результирующий набор. На первом сервере Server1 создайте представление со следующим кодом:

CREATE VIEW AllOrders
AS
SELECT * 
FROM OrdersUnder
UNION ALL
SELECT *
FROM server2.test.dbo.OrdersOver

На втором сервере Server2 код снова практически тот же:

CREATE VIEW AllOrders
AS
SELECT * 
FROM OrdersOver
UNION ALL
SELECT *
FROM server1.test.dbo.OrdersUnder

Существует несколько правил для представлений DML. Чтобы представление было обновляемым, должны возвращаться все столбцы, включенные в первичный ключ. На всех столбцах, не включенных в представление, должны быть разрешены значения NULL.
Протестируйте представление, выполнив простую выборку:

SELECT *
FROM AllOrders

В результате должен быть возвращен пустой результирующий набор. Перед тем, как начать выполнение выражений DML, еще остается пара вопросов, требующих рассмотрения.

[В начало]

Координатор распределенных транзакций

Перед выполнением примеров требуется запустить координатор распределенных транзакций (DTC). DTC управляет выполнением транзакций, когда задействованы несколько различных источников данных. Для Windows 2000 требуется service pack 1.
Откройте сервисы консоли MMC, найдите и запустите DTC с установками по умолчанию.

[В начало]

lazy schema validation

Хотя это не является обязательным требованием, но установка опции спящего режима проверки схемы (lazy schema validation) повышает производительность запросов. Проверка схемы - это проверка удаленной схемы на то, что ее метаданные верны. При установке этой проверки в спящий режим SQL не проверяет верность удаленных метаданных относительно нашего запроса до его выполнения. Если произошло изменение удаленной схемы, то наш запрос вернет ошибку. В нашем случае мы знаем, что удаленная таблица верна и имеет ту же структуру, что и наша локальная таблица. Не проверяя удаленную схему, мы получим повышение производительности.

use master
GO
sp_serveroption 'LocalServerName', 'lazy schema validation', true
GO
sp_serveroption 'server2', 'lazy schema validation', true
GO

[В начало]

Collation Compatible

Если мы дадим SQL информацию, что сортировка и набор символов одинаковы у локального и удаленного серверов, то удаленный сервер сможет принимать участие в сравнениях. В противном случае все данные сначала будут приходить на локальный сервер. Все сравнения в этом случае будут делаться локально, снижая производительность. Этого можно избежать, включив опцию совместимого сопоставления (collation compatible). Эта опция также не является обязательным требованием, а используется для оптимизации.

use master
GO
sp_serveroption 'LocalServerName', 'collation compatible', true
GO
sp_serveroption 'server2', 'collation compatible', true
GO
DML

Начнем со вставки данных в новую пустую таблицу. Следующий код выполнит вставку одной записи:

use test
GO
SET XACT_ABORT  ON
GO
INSERT INTO AllOrders
 (ord_nbr, ord_date, cust_id, amount)
VALUES
 (1001, '01/01/1993', 5, 50.25)

Сама вставка - это операция, которую Transact-SQL выполняет регулярно. Опция XACT_ABORT требуется выражений, которые модифицируют данные. Когда опция установлена, любая ошибка времени исполнения приводит к откату всей транзакции.
Выборка данных из нашего представления подтверждает, что запись была успешно сохранена:

Удаление записей включает те же шаги:

SET XACT_ABORT  ON
GO
DELETE 
FROM AllOrders
WHERE cust_id = 5

Недавно добавленная запись удалена. Отметим, что выражению WHERE не требуется ссылаться на наш первичный ключ или столбец с ограничением CHECK.

[В начало]

Все понемногу

Представление может обращаться к связанной таблице по имени, состоящем из четырех частей (как это сделано в нашем примере), при использовании функции OPENROWSET или функции OPENDATASOURCE.
Вставка и обновление данных не разрешены в таблицах со столбцом timestamp.
Полный список правил работы с представлениями см. в BOL "Секционированные представления".
Хотя у нас теперь имеется две таблицы на двух различных серверах, которые действуют как одна, нет никаких автоматических средств для сохранения или восстановления их как единого целого.

[В начало]

Заключение

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

[В начало]

ССЫЛКИ НА СТАТЬИ

Статьи на русском языке

Работа с данными в ADO.NET-I
Александр Игнатьев
В этой статье рассмотрены классы пространства имен System.Data - DataColumn, DataRow, DataTable, DataSet - предназначенные для работы с отсоеденными данными. В первой части статьи мы рассмотрим создание таблиц DataTable и класс DataColumn

[В начало]

Англоязычные статьи

Building Joins the Easy Way
Dale Elizabeth Corey
Okay, I admit it. Before I became an SQL Server 2000 DBA, I was bottlefed on Microsoft Access. When it came to building complex queries with joins, I became an expert on Access's Grid Manager, formally known as a form of Query By Example (QBE) developed by IBM's Dr. Zloof in the 1970's. Call me lazy but when building complex joins, I found that Access's Grid Manager was better than anything I could type or formulate so I let Access's Grid Manager do all the work. Of course, I ventured into Access's SQL View every now and then to modify the actual SQL syntax (Access's own unique version) but not too often. I didn't need to
MDX in Analysis Services: Introducing DISTINCT COUNT
William Pearson
In our last tutorial, Named Sets in MDX: An Introduction, we introduced named sets in MDX queries, focusing on their creation through use of the WITH clause, to allow us to gain an understanding of the general capabilities of static and dynamic named sets. We introduced the concepts behind named sets, and then examined the MDX syntax required to create them and to specify them for presentation in our results. Next, we discussed the nature of static and dynamic named sets, and then activated what we had learned through an illustrative practice example for each of the two types. Finally, we discussed the results we obtained in each hands-on example, illustrating the value that named sets can offer us
SQL Server 2000 Security - Part 2 (Authentication)
Marcin Policht
Access to SQL Server resources is controlled by two separate mechanisms. The first one is authentication, which determines the identity of a user attempting to connect, based on a verifiable identifier. The second one is authorization, which establishes the level of privileges granted to a login associated with the logged on user. In this article, we will focus on the authentication (authorization will be covered later in the series)
Capturing The Error Description In A Stored Procedure
Amit Jethva
How do you accomplish error handling in a stored procedure? 99.99 % of people will answer use @@ERROR. How do you capture actual error message of the error raised by SQL Server within a stored procedure? Such as
Auditing Your SQL Server Part 4 - Selective Auditing
Steve Jones
Auditing is always a double edged sword. When you need to determine what happened, you want all the information that you can possibly have. However when you don't have issues, you have this huge volume of information to wade through, most of which doesn't really make sense. Balancing these two can be difficult, but it is something that you want to keep in mind and think long and hard about what you audit and how much you keep. You also want to be sure that you capture enough information that you can trace back the true issues that you face
Using SQL Server's XML Support
Ken Henderson
This chapter updates the coverage of SQLXML in my last book, The Guru's Guide to SQL Server Stored Procedures, XML, and HTML. That book was written before Web Release 1 (the update to SQL Server 2000's original SQLXML functionality) had shipped. As of this writing, SQLXML 3.0 (which would be the equivalent of Web Release 3 had Microsoft not changed the naming scheme) has shipped, and Yukon, the next version of SQL Server, is about to go into beta test
Monitoring and Troubleshooting Transactional Replication
Baya Pavliashvili
So you set up replication and it works for a week. Then one fine day your pager goes off. Now what? Where do you look for clues? How do you troubleshoot? How can you tell if your replicated system performs well? Read on to find out the answers from Baya Pavliashvili
Design Elements Part 5: Where Does The Code Live?
InformIT
The interesting part of writing code using T-SQL is that it isn't really a full programming language; it's a platform programming language. That means that important programming concepts, such as User Interface design and file manipulation aren't part of what T-SQL handles. In that aspect, Transact-SQL isn't a "full" or complete programming language
Introduction into Caching in SQL Server 2000
ExtremeExperts.com
This topic has been in my minds for quite some time now. Just thought to get them into a understandable article for public use ... Well, most of the DBA's and many programmers of SQL Server should have heard of the terms data cahe and procedure cahe in conjunction with SQL Server. These are the primary building blocks or parts of the caching mechanism we all talk about. But what is this cache on first place?
Auto-Generating Wrapper Classes for Stored Procedures, Part 1: Using the AutoSproc Tool
Steve J. Rodgers
The AutoSproc tool uses reflection to auto-generate wrapper classes for calling stored procedures. This saves the developer from having to work with ADO.NET classes such as SqlCommand, SqlParameter, SqlDataAdapter, etc. Here, we'll take a look at the salient points of the tool and review how to use it in your application. For more details on the internals of the tool, see the companion article Auto-Generating Wrapper Classes for Stored Procedures, Part 2: The Internals of the AutoSproc Tool. (18 printed pages)
SQL Server Needs Incremental Updates
Brian Knight
As you may have heard, the next version of SQL Server (code named Yukon) has a name. The release is now formally called SQL Server 2005 to match Visual Studio 2005. A new schedule was announced that pushes the beta cycle out as well. Beta 2 will be widely shipped in the summer of 2004. Beta 3 will be shipping in the late 4th quarter and the GA release will ship in the first half of next year
SQL Server "Yukon" and the CLR: Using Server Data
Mike Gunderloy
In my previous article, I showed you how to write a very simple function in Visual Basic .NET and then call it from T-SQL code in SQL Server "Yukon." But that's only part of the CLR integration story for the next version of SQL Server. One important part of the story that I left out is the in-process managed provider, an ADO.NET provider that CLR functions can use to talk directly to the instance of SQL Server that invoked them. In this article, I'll show you some of the basics of using this plumbing
Date, Math and Text Functions in SQL Server 2000
Baya Pavliashvili
In the previous articles in this series, I introduced you to aggregate and system-related functions. This article continues to explore various types of built-in functions. I will walk you through the most useful functions that fall into date and time, math, and text function categories
When to use data replication
Baya Pavliashvilli
As it relates to SQL Server, replication is a way of keeping data synchronized in multiple databases. However, if you have numerous database servers that need to be involved in various types of replication, this seemingly simple task can quickly become complex. Before you make the decision to replicate your database, take a look at this tip from InformIT which examines some of the reasons to use replication
Application Development: SQL Server "Yukon" and CLR integration
Sanders Kaufman, Jr.
If you're a Microsoft programmer, you have probably invested quite a lot in the transition from Windows NT/SQL Server 7 to Windows 2000/SQL Server 2000. The transition to Longhorn/Yukon is going to require a similar investment. Enhancements to SQL Server (Yukon) will include more complex reporting services and better handling of XML/XSL. The big new feature is integration with the .NET Framework

[В начало]

ПОЛЕЗНОСТИ

Оптимизация баз данных: принципы, практика, решение проблем

Бонне Филипп, Шаша Деннис ISBN: 5-93378-096-0, издательство "Кудиц-Образ" ∙ 2004 г. ∙ 432 стр. Книга посвящена практическим аспектам настройки производительности систем управления базами данных. По признанию авторов, настройка баз данных – это не только наука, но и искусство, овладение которым требует глубоких познаний в области информационных систем. В книге даны рекомендации по оценке эффективности программных и аппаратных средств поддержки баз данных, предложены варианты оптимизации их функционирования. Особое внимание уделено внутренним механизмам работы баз данных, индексированию и настройке реляционных систем. Материал книги носит практический характер и основан на многочисленных экспериментах с наиболее популярными реляционными СУБД производства компаний Microsoft, Oracle, IBM, Sybase и рядом специализированных продуктов. Изложенные принципы проиллюстрированы примерами из практики одного из авторов книги. Отдельные главы освещают проблемы мониторинга производительности баз данных, настройки приложений электронной коммерции и информационных хранилищ. В приложения вынесена информация, дополняющая и расширяющая основной материал. Рекомендуется специалистам по проектированию и обслуживанию корпоративных баз данных и студентам, изучающим вопросы построения и администрирования СУБД.

[В начало]

Анализ данных. Генератор отчетов Crystal Reports

Маклаков С.В., Матвеев Д.В. Издано: 2003, БХВ-Петербург. ISBN: 5-94157-230-1 489 стр. Цена: 201.00 руб. Книга представляет собой практическое руководство по созданию аналитических отчетов с помощью генератора отчетов Crystal Reports версии 9. Дан обзор инструментальной среды и принципы выборки, сортировки и группирования данных. Объясняется использование формул, диаграмм и географических карт, матричных отчетов и OLAP-источников данных. Для системных администраторов рассматриваются различные методы распространения отчетов - от экспорта в распространенные форматы до распространения с помощью Crystal Reports Enterprise. Для профессиональных разработчиков информационных систем рассматривается использование Crystal Report Print Engine API и встраиваемых компонентов Crystal Reports (Delphi и Visual Basic), их применение для интеграции в информационные системы, отчетов, созданных в различных средах разработки. В приложениях приведен перечень и подробное описание функций Crystal Report Print Engine API (CRPE), а также описание параметров функций Crystal Report Print Engine API. Для широкого круга пользователей, интересующихся вопросами анализа данных и подготовки отчетов.

[В начало]