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

Обновлено: 05.07.2024

При перестроении системных баз данных master, model, msdb и tempdb эти базы данных удаляются и создаются повторно в исходном расположении. Если в инструкции перестроения заданы новые параметры сортировки, системные базы данных создаются с этими параметрами. Все пользовательские изменения этих баз данных будут потеряны. Например, в базе данных master могут содержаться пользовательские объекты, в базе данных msdb — запланированные задания, а в базе данных model — изменения исходных параметров баз данных.

Предварительные требования

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

Зарегистрируйте все значения конфигурации на уровне сервера.КопироватьSELECT * FROM sys.configurations;
Зарегистрируйте все пакеты обновления и исправления, примененные к экземпляру SQL Server , и текущие параметры сортировки. Эти обновления необходимо применить после перестроения системных баз данных.

Перестроение системных баз данных

Следующая процедура перестраивает системные базы данных master, model, msdb и tempdb. Нельзя выбрать, какие системные базы данных будут перестраиваться. Для кластеризованных экземпляров эту процедуру необходимо выполнить на активном узле, а ресурс SQL Server в соответствующей группе приложений кластера перед ее выполнением должен быть переведен в состояние «вне сети».

Эта процедура не перестраивает базу данных resource. См. раздел «Процедура перестроения базы данных resource» ниже.

Перестроение системных баз данных для экземпляра SQL Server:

Задачи, выполняемые после перестроения

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

Восстановить наиболее поздние полные резервные копии баз данных master, model и msdb. Дополнительные сведения см. в статье Резервное копирование и восстановление системных баз данных (SQL Server) .Important
Если изменены параметры сортировки сервера, не следует восстанавливать системные базы данных. В противном случае новые параметры сортировки будут заменены старыми.Если резервная копия недоступна или не является копией текущей базы данных, повторно создайте все отсутствующие записи.Например, повторно создайте все недостающие записи для пользовательских баз данных, устройств резервного копирования, имен входа SQL Server , конечных точек и так далее. Лучшим способом повторного создания записей является запуск создавшего их исходного скрипта.

Рекомендуется защитить применяемые скрипты, чтобы предотвратить их изменение неавторизированными пользователями.

Перестроение базы данных Resource

Приведенная ниже процедура перестраивает системную базу данных resource. После перестроения базы данных resource все исправления и пакеты обновления теряются, поэтому их следует применить заново.

Перестроение базы данных resource

Создание новой базы данных msdb

Если база данных msdb повреждена и нет резервной копии базы данных msdb , можно создать новую базу данных msdb с помощью скрипта instmsdb .

Когда база данных msdb создается заново скриптом instmsdb , удаляется вся информация, которая хранилась в msdb , то есть задания, оповещения, операторы, планы обслуживания, журналы резервных копий, параметры системы управления на основе политик, компоненты Database Mail, хранилище данных о производительности и т. д.

Остановите все службы, подключающиеся к компоненту Компонент Database Engine, включая агент SQL Server , службы Службы SSRS, службы Службы SSISи все приложения, использующие SQL Server как хранилище данных.
Запустите SQL Server из командной строки с помощью команды: NET START MSSQLSERVER /T3608Дополнительные сведения см. в статье Запуск, остановка, приостановка, возобновление и перезапуск ядра СУБД, агента SQL Server и обозревателя SQL Server .
В другом окне командной строки отключите базу данных msdb , выполнив следующую команду, которая заменяет <имя_сервера> экземпляром SQL Server: SQLCMD -E -S<servername> -dmaster -Q"EXEC sp_detach_db msdb"
С помощью проводника Windows переименуйте файлы базы данных msdb . По умолчанию они находятся в папке DATA соответствующего экземпляра SQL Server .
С помощью диспетчера конфигурации SQL Server остановите и перезапустите службу компонента Компонент Database Engine , как обычно.
В окне командной строки подключитесь к серверу SQL Server и выполните следующую команду: SQLCMD -E -S<servername> -i"C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Install\instmsdb.sql" -o"C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Install\instmsdb.out"Замените <имя_сервера> экземпляром компонента Компонент Database Engine. Укажите путь к экземпляру SQL Serverв файловой системе.
Откройте в Блокноте файл instmsdb.out и проверьте выходные данные на наличие ошибок.
Примените заново все пакеты обновления и пакеты исправлений, которые были установлены на экземпляре.
Создайте заново пользовательское содержимое базы данных msdb , в том числе задания, оповещения и т. д.
Создайте резервную копию базы данных msdb .

Устранение ошибок перестроения

Ошибки синтаксиса и ошибки времени выполнения отображаются в окне командной строки. Проверьте инструкцию установки на наличие следующих синтаксических ошибок:

В рамках данной статьи рассмотрим системные базы данных MS SQL Server 2012. Ниже приводится их подробное описание, расположение, а также разбираются вопросы о необходимости резервного копирования системных баз данных.

0. Оглавление

1. Краткое описание системных баз данных

В процессе установки компоненты Database Engine MS SQL Server генерируются следующие системные базы данных:

Системная база данных	Описание
master	В этой базе данных хранятся все данные системного уровня для экземпляра SQL Server.
tempdb	Рабочее пространство для временных объектов или взаимодействия результирующих наборов.
msdb	Используется агентом SQL Server для планирования предупреждений и задач.
model	Используется в качестве шаблона для всех баз данных, создаваемых в экземпляре SQL Server. Изменение размера, параметров сортировки, модели восстановления и других параметров базы данных model приводит к изменению соответствующих параметров всех баз данных, создаваемых после изменения.
resource	Системные объекты физически хранятся в базе данных resource, но логически отображаются в схеме sys любой базы данных.

2. Подробное описание системных баз данных

Рассмотрим каждую из системных баз данных более подробно:

Резервное копирование : По причине важности этой системной базы данных необходимо всякий раз осуществлять ее резервное копирование, после выполнения любых системных операций, таких как добавление новых баз данных, добавления пользователей в SQL Server, изменений параметров экземпляра SQL Server и т. д.

Резервное копирование: Операции резервного копирования и восстановления базы данных tempdb запрещены.

Замечание: База данных tempdb используется системой довольно активно. По этой причине необходимо убедиться, что объем памяти для этой базы данных достаточно большой. Также можно получить значительный прирост производительности SQL Server путем выноса базы tempdb на отдельный дисковый накопитель, или более быстрый SSD-диск.

Резервное копирование : Следует делать резервную копию базы данных model, после каждого изменения этой базы данных.

Резервное копирование : Следует делать резервную копию базы данных msdb, после каждого изменения параметров агента SQL Server.

База данных resource — это доступная только для чтения база данных, которая содержит все системные объекты, включенные в SQL Server. Такие системные объекты SQL Server, как sys.objects, физически хранятся в базе данных resource, но логически присутствуют в схеме sys каждой базы данных. База данных resource не содержит пользовательских данных или метаданных. Содержимое этой базы данных обычно используется для системных обновлений.

Резервное копирование : Резервное копирование базы данных resource не предусмотрено.

3. Просмотр и редактирование свойств системных баз данных

В открывшемся окне можно просмотреть или изменить различные свойства базы данных, располагающиеся на соответствующих вкладках. Например, на вкладке «Файлы» (Files) можно узнать владельца базы данных или путь расположения файлов базы.

О том как изменить каталог расположения файлов системной базы данных tempdb я писал здесь.

Файлы базы данных resource имеют имена mssqlsystemresource.mdf и mssqlsystemresource.ldf и располагаются в каталоге с установленным экземпляром SQL Server. По умолчанию это
C:\Program Files\Microsoft SQL Server\MSSQL11.<instance_name>\MSSQL\Binn\.

Смотрите также:

Ниже приведена пошаговая инструкция, показывающая как добавить новую базу данных в Microsoft SQLServer 2012 (в более старых редакциях, например в Microsoft SQL Server 2008 R2, набор действий аналогичен). Запускаем…

Системная база данных tempdb служит рабочим пространством для хранения временных объектов, таких как временные таблицы, промежуточные результаты вычислений, временные хранимые процедуры, результаты буферов и сортировки, внутренние объекты, создаваемые компонентой Database…

Раннее я уже писал о создании резервных копий в MS SQL Server 2012. В данной статье подробно рассмотрим процессе восстановления базы данных из имеющейся резервной копии (резервных копий) в MS SQL…

Для отдельных баз данных и эластичных пулов Базы данных SQL Azure используются только базы данных master и tempdb. Дополнительные сведения см. в разделе Что являет собою сервер Базы данных SQL Azure?. Описание базы данных tempdb в контексте Базы данных SQL Azure см. в разделе База данных tempdb в базе данных SQL. Для Управляемого экземпляра SQL Azure применяются все системные базы данных. См. дополнительные сведения об Управляемом экземпляре Базы данных SQL Azure.

изменение системных данных

SQL Server не поддерживает прямое обновление пользователями данных в таких системных объектах, как таблицы, системные хранимые процедуры и представления каталогов. Вместо этого SQL Server предоставляет полный набор административных средств, позволяющих пользователям управлять всей системой, пользователями и объектами базы данных. следующие основные параметры.

Административные программы, например SQL Server Management Studio.

SQL-SMO API. Этот программный интерфейс позволяет программистам включать любые административные возможности SQL Server в разрабатываемые приложения.

Transact-SQL . Можно использовать системные хранимые процедуры и DDL-инструкции Transact-SQL .

Эти средства защищают приложения от изменений системных объектов. Например, иногда в целях поддержки новых возможностей, добавленных в новые версии SQL Server , приходится изменять системные таблицы этих версий SQL Server . Приложения, выполняющие инструкции SELECT, которые ссылаются непосредственно на системные таблицы, часто зависят от старого формата этих таблиц. Обновление сайтов до новой версии SQL Server невозможно, пока для них не будут переписаны приложения, выполняющие выборку из системных таблиц. SQL Server учитывает существующие системные хранимые процедуры, DDL и опубликованные интерфейсы SQL-SMO и работает, поддерживая обратную совместимость этих интерфейсов.

SQL Server не поддерживаются триггеры, заданные для системных таблиц, поскольку они могут влиять на работу системы.

Системные базы данных не могут размещаться в общих каталогах UNC.

просмотр данных системной базы данных

Не следует создавать инструкции Transact-SQL , которые выполняют запросы непосредственно к системным таблицам, если только это не единственный способ получить данные, необходимые для приложения. Приложения должны получать данные каталога и системные данные с помощью следующих средств:

Представления системного каталога

интерфейса инструментария управления Windows (WMI);

функций каталога, методов, атрибутов или свойств данных API, использующихся в приложении, например ADO, OLE DB или ODBC;

Как dba и консультант по оптимизации производительности SQL Server в Ambient Consulting, я часто сталкиваюсь с необходимостью анализа узких мест производительности на экземплярах SQL Server, которые вижу первый раз в жизни. Это может быть сложной задачей. Как правило, у большинства компаний нет документации по их базам данных. А если есть, то она устарела, или же её поиск занимает несколько дней.

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

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

Как и с любыми скриптами, сначала проверьте их в тестовом окружении, прежде чем запускать в продакшене. Я бы рекомендовал вам погонять их на тестовых базах MS, таких как AdventureWorks или pubs.

Ну, хватит слов, давайте я покажу скрипты!

Начнём с запросов, предоставляющих информацию о ваших серверах.

Базовая информация

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

Как долго ваш SQL Server работает после последнего перезапуска? Помните, что системная база данных tempdb пересоздаётся при каждом перезапуске SQL Server. Вот один из методов определения времени последнего перезапуска сервера.

Связанные сервера

Связанные сервера – это соединения, позволяющие SQL Server’у обращаться к другим серверам с данными. Распределённые запросы могут быть запущенны на разных связанных серверах. Полезно знать – является ли ваш сервер баз данных изолированным от других, или он связан с другими серверами.

Список всех баз данных

Во-первых, получим список всех баз данных на сервере. Помните, что на любом сервере есть четыре или пять системных баз данных (master, model, msdb, tempdb и distribution, если вы пользуетесь репликацией). Вы, вероятно, захотите исключить эти базы в следующих запросах. Очень просто увидеть список баз данных в SSMS, но, эти запросы будут нашими «строительными блоками» для более сложных запросов.

Есть несколько путей для получения списка всех БД на T-SQL и ниже вы увидите некоторые из них. Каждый метод возвращает похожий результат, но с некоторыми отличиями.

Последний бэкап?

Стоп! Прежде чем двигаться дальше, каждый хороший dba должен узнать есть ли у него свежий бэкап.

Будет лучше, если вы сразу узнаете путь к файлу с последним бэкапом.

Активные пользовательские соединения

Хорошо было бы понимать какие БД сейчас используются, особенно, если вы собираетесь разбираться с проблемами производительности.

Примечание переводчика: это будет работать только в SQL Server 2012 и выше, в предыдущих редакциях, в dmv sys.dm_exec_sessions отсутствовал столбец database_id. Чтобы узнать в каких БД в данный момент работают пользователи, можно воспользоваться sp_who.

Давайте заглянем поглубже и посмотрим, как мы можем собрать информацию об объектах во всех ваших БД, используя различные представления каталога и dmv. Большинство из запросов, представленных в этом разделе, смотрят «внутрь» только одной БД, поэтому не забывайте выбирать нужную БД в SSMS или с помощью команды use database. Также помните, что вы всегда можете посмотреть в контексте какой БД будет выполнен запрос, с помощью select db_name().

Системная таблица sys.objects одна из ключевых для сбора информации об объектах, составляющих вашу модель данных.

Ниже представлен список типов объектов, информацию о которых мы можем получить (смотрите документацию на sys.objects в MSDN)

AF = статистическая функция (среда CLR);
C = ограничение CHECK;
D = DEFAULT (ограничение или изолированный);
F = ограничение FOREIGN KEY;
PK = ограничение PRIMARY KEY;
P = хранимая процедура SQL;
PC = хранимая процедура сборки (среда CLR);
FN = скалярная функция SQL;
FS = скалярная функция сборки (среда CLR);
FT = возвращающая табличное значение функция сборки (среда CLR);
R = правило (старый стиль, изолированный);
RF = процедура фильтра репликации;
S = системная базовая таблица;
SN = синоним;
SQ = очередь обслуживания;
TA = триггер DML сборки (среда CLR);
TR = триггер DML SQL;
IF = встроенная возвращающая табличное значение функция SQL;
TF = возвращающая табличное значение функция SQL;
U = таблица (пользовательская);
UQ = ограничение UNIQUE;
V = представление;
X = расширенная хранимая процедура;
IT = внутренняя таблица.

Другие представления каталога, такие как sys.tables и sys.views, обращаются к sys.objects и предоставляют информацию о конкретном типе объектов. С этими представлениями, плюс функцией OBJECTPROPERTY, мы можем получить огромное количество информации по каждому из объектов, составляющих нашу схему БД.

Расположение файлов баз данных

Физическое расположение выбранной БД, включая основной файл данных (mdf), и файл журнала транзакций (ldf), могут быть получены с помощью этих запросов.

Таблицы

Конечно, Object Explorer в SSMS показывает полный список таблиц в выбранной БД, но часть информации с помощью GUI получить сложнее, чем с помощью скриптов. Стандарт ANSI предполагает обращение к представлениям INFORMATION_SCHEMA, но они не предоставят информацию об объектах, которые не являются частью стандарта (такие как триггеры, extended procedures и т.д.), поэтому лучше использовать представления каталога SQL Server.

Количество записей в таблице

Если вы ничего не знаете о таблице, то все таблицы одинаково важны. Чем больше вы узнаёте о таблицах, тем больше вы их разделяете на условно более важные и условно менее важные. В целом, таблицы с огромным количеством записей чаще оказывают серьёзное влияние на производительность.

В SSMS мы можем нажать правой кнопкой мыши на любую таблицу, открыть свойства на вкладке Storage и увидеть количество записей в таблице.

Довольно тяжело собрать вручную эту информацию обо всех таблицах. Опять же, если мы будем писать SELECT COUNT(*) FROM TABLENAME для каждой таблицы, нам придётся очень много печатать.

Намного удобнее использовать T-SQL для генерирования скрипта. Скрипт, приведённый ниже, сгенерирует набор инструкций T-SQL для получения количества строк в каждой таблице текущей базы данных. Просто выполните его, скопируйте результат в новое окно и запустите.

Примечание переводчика: у меня запрос не работал, добавил схему к имени таблицы.

sp_msForEachTable

Sp_msforeachtable – это недокументированная функция, которая «проходит» по всем таблицам в БД и выполняет запрос, подставляя вместо ‘?’ имя текущей таблицы. Так же существует похожая функция sp_msforeachdb, работающая на уровне баз данных.

Известно несколько проблем с этой недокументированной функцией, например, использование спецсимволов в именах объектов. Т.е. если имя таблицы или базы данных содержит знак ‘-‘, хранимая процедура, листинг которой ниже, завершится с ошибкой.

Самый быстрый способ получения количества записей – кластерный индекс

Все предыдущие метода использовали COUNT(*), который медленно отрабатывает, если в таблице больше чем 500K записей.

Самый быстрый способ получения количества записей в таблице – получать количество записей в кластерном индексе или куче. Помните, что хоть этот метод и самый быстрый, MS говорит, что информация о количестве записей индекса и реальное количество строк в таблице может не совпадать, из-за того, что на обновление информации требуется хоть и небольшое, но время. В большинстве же случаев, эти значения или одинаковы, или очень-очень близки и вскоре станут одинаковыми.

Поиск куч (таблиц без кластерных индексов)

Работа с кучами – это как работа с плоским файлом, вместо базы данных. Если вы хотите гарантированно получать полное сканирование таблицы при выполнении любого запроса, используйте кучи. Обычно я рекомендую добавлять primary key ко всем таблицам-кучам.

Разбираемся с активностью в таблице

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

Помните, что эта информация из dmv, очищается при каждом перезапуске SQL Server. Чем дольше сервер работает, тем более надёжна статистика. Я чувствую себя намного более уверенно со статистикой, собранной за 30 дней, чем со статистикой, собранной за неделю.

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

Примечание переводчика: курсор не отработает, если у вас в списке есть базы данных с состоянием, отличным от ONLINE.

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

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

В SQL Server, в некоторых случаях, мы можем обновлять данные с использованием представления. Чтобы получить представление «только для чтения», можно использовать SELECT DISTINCT при его создании. Данные «через» представление можно менять только в том случае, если каждой строке представления соответствует только одна строка в «базовой» таблице. Любое представление, не отвечающее этому критерию, т.е. построенное на нескольких таблицах, или с использованием группировок, агрегатных функций и вычислений, будет доступно только для чтения.

Синонимы

Несколько раз в моей карьере я сталкивался с ситуацией, когда не мог понять к какой же таблице обращается запрос. Представьте простой запрос SELECT * FROM Client. Я ищу таблицу под именем Client, но я не могу найти её. Хорошо, думаю я, должно быть это представление, ищу представление с именем Client и всё равно не могу найти. Может быть я ошибся базой данных? В итоге выясняется, что Client – это синоним для покупателей и таблица, на самом деле, называется Customer. Отдел маркетинга хотел обращаться к этой таблице как к Client и из-за этого был создан синоним. К счастью, использование синонимов – это редкость, но разбирательства могут вызвать определённые затруднения, если вы к ним не готовы.

Хранимые процедуры

Хранимые процедуры – это группа скриптов, которые компилируются в единственный план выполнения. Мы можем использовать представления каталога, чтобы определить какие ХП созданы, какие действия они выполняют и над какими таблицами.

Добавив простое условие в WHERE мы можем получить информацию только о тех хранимых процедурах, которые, например, выполняют операции INSERT.

Немного модифицировав условие в WHERE, мы можем собрать информацию о ХП, производящих обновление, удаление или же обращающихся к определённым таблицам.

Функции

Функции хранятся в SQL Server, принимают какие-либо параметры и выполняют определённые действия, либо вычисления, после чего возвращают результат.

Триггеры

Триггер – это что-то вроде хранимой процедуры, которая выполняется в ответ на определённые действия с той таблицей, которой этот триггер принадлежит. Например, мы можем создать INSERT, UPDATE и DELETE триггеры.

CHECK-ограничения

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

Ранее, мы использовали скрипты, которые дали нам представление о «верхнем уровне» объектов, составляющих нашу базу данных. Иногда нам нужно получить больше данных о таблице, включая столбцы, их типы данных, какие значения по умолчанию заданы, какие ключи и индексы существуют (или должны существовать) и т.д.

Запросы, представленные в этом разделе, предоставляют средства почти что реверс-инжиниринга существующей модели данных.

Столбцы

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

Значения по умолчанию

Значение по умолчанию – это значение, которое будет сохранено, если никакого значения для столбца не будет задано при вставке. Зачастую, для столбцов хранящих дату ставят get_date(). Также, значения по умолчанию используются для аудита – вставляется system_user для определения учётной записи пользователя, совершившего определённое действие.

Вычисляемые столбцы

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

Столбцы identity

Столбцы IDENTITY автоматически заполняются системой уникальными значениями. Обычно используются для хранения порядкового номера записи в таблице.

Ключи и индексы

Как я писал ранее, наличие первичного ключа и соответствующего индекса у таблицы – это одна из best practice. Ещё одна best practice заключается в том, что внешние ключи так же должны иметь индекс, построенный по столбцам, входящим во внешний ключ. Индексы, построенные «по внешним ключам» отлично подходят для соединения таблиц. Эти индексы так же хорошо сказываются на производительности при удалении записей.

Какие индексы у нас есть?

Скрипт для поиска всех индексов во всех таблицах текущей БД.

Каких индексов не хватает?

На основании ранее исполнявшихся запросов, SQL Server предоставляет информацию об отсутствующих индексах в БД, создание которых может увеличить производительность.

Не добавляйте эти индексы вслепую. Я бы подумал о каждом из предложенных индексов. Использование включенных столбцов, например, может аукнуться серьёзным увеличением объёмов.

Внешние ключи

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

Пропущенные индексы по внешним ключам

Как я уже говорил, желательно иметь индекс, построенный по столбцам, входящим во внешний ключ. Это значительно ускоряет соединения таблиц, которые, обычно, всё равно соединяются по внешнему ключу. Эти индексы так же значительно ускоряют операции удаления. Если такого индекса нет, SQL Server будет производить table scan связанной таблицы, при каждом удалении записи из «первой» таблицы.

Зависимости

Это зависит… Я уверен, вы слышали это выражение раньше. Я рассмотрю три разных метода для «реверс-инжиниринга» зависимостей в БД. Первый метода – использовать хранимую процедуру sp_msdependecies. Второй – системные таблицы, связанные со внешними ключами. Третий метод – использовать CTE.

sp_msdependencies

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

Если мы выведем все зависимости, используя sp_msdependencies, мы получим четыре столбца: Type, ObjName, Owner(Schema), Sequence.

Обратите внимание на номер последовательности (Sequence) – он начинается с 1 и последовательно увеличивается. Sequence – это «порядковый номер» зависимости.

Я несколько раз использовал этот метод, когда мне нужно было выполнить архивирование или удаление на очень большой БД. Если вы знаете зависимости таблицы, значит у вас есть «дорожная карта» — в каком порядке вам нужно архивировать или удалять данные. Начните с таблицы с самым большим значение в столбце Sequence и двигайтесь от него в обратном порядке – от большего к меньшему. Таблицы с одинаковым значением Sequence могут быть удалены одновременно. Этот метод не нарушает ни одного из ограничений внешних ключей и позволяет перенести/удалить записи без временного удаления и перестроения ограничений (constraints).

В SSMS, если вы нажмёте правой кнопкой мыши на имя таблицы, вы сможете выбрать «View Dependencies» и «Объекты, которые зависят от TABLENAME»:

Мы также можем получить эту информацию следующим способом:

Если в SSMS, в окне просмотра зависимостей, выбрать «Объекты которые зависят от TABLENAME», а затем раскрыть все уровни, мы увидим следующее:

Ту же самую информацию вернёт sp_msdependencies.

Так же, в SSMS, мы можем увидеть от каких объектов зависит выбранная таблица.

Следующий запрос, с использованием msdependencies, вернёт ту же самую информацию.

Если вы хотите получить список зависимостей таблиц, вы можете использовать временную таблицу, чтобы отфильтровать зависимости по типу.

Запросы к системным представлениям каталога

Второй метод «реверс-инжиниринга» зависимостей в вашей БД – это запросы к системным представлениям каталога, связанным со внешними ключами.

Использование CTE

Третий метод, для получения иерархии зависимостей – использование рекурсивного CTE.

Таким образом, за час или два, можно получить неплохое представление о внутренностях любой базы данных, используя методы «реверс-инжиниринга», описанные выше.

Примечание переводчика: все запросы в тексте (за исключением одного, в тексте он отмечен) будут работать на SQL Server 2005 SP3 и в более поздних редакциях. Текст достаточно объёмный, я старался как мог его вычитать и найти свои ошибки (стилистические, синтаксические, смысловые и прочие), но, наверняка что-то не заметил, напишите мне в личку, пожалуйста, если что-то будет резать глаз.

Читайте также: