как узнать размер базы sql
Размер базы данных MySQL
Но сколько занимает ваша база данных? А каждая таблица? Для больших проектов эти показатели могут достигать очень больших значений. В сегодняшней статье мы поговорим о том, как узнать размер базы данных MySQL через консоль и другими способами.
Размер базы данных MySQL
SELECT table_schema AS «Имя базы данных»,
ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS «Размер в Мб»
FROM information_schema.TABLES
GROUP BY table_schema;
Запрос выведет точный размер базы MySQL для каждой из существующих баз, теперь вы можете ориентироваться что и сколько занимает. Если у вас очень большой проект и большая база данных, то вы можете выводить информацию в гигабайтах:
SELECT table_schema AS «Имя базы данных»,
ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024, 2) AS «Размер в Гб»
FROM information_schema.TABLES
GROUP BY table_schema;
Но это еще не все. Возможно, в базе данных есть ненужная информация, которая только замедляет работу системы. Мы можем посмотреть размер таблиц для каждой из баз данных. Запрос для этого будет выглядеть следующим образом:
SELECT table_name AS «Имя таблицы»,
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS «Size in (MB)»
FROM information_schema.TABLES
WHERE table_schema = «wpfc_options»
ORDER BY (data_length + index_length) DESC;
Данная информация помогает понять какая таблица сколько занимает и это уже может навести на интересные мысли.
Размер базы данных в Phpmyadmin
Если вы не очень любите работать в терминале, то вы всегда можете использовать Phpmyadmin для просмотра размера базы данных. Размер каждой из таблиц базы данных вы можете посмотреть на вкладке «Структура», когда выберите базу данных для работы:
Что касается размера самой базы данных, то придется выполнить тот же запрос в интерфейсе программы на вкладке «SQL»:
Выводы
В этой небольшой статье мы рассмотрели как узнать размер базы данных MySQL несколькими способами. Если у вас остались вопросы, спрашивайте в комментариях!
Получение информации о размере базы данных, таблиц и индексов на диске (СУБД MS SQL Server)
Рост размера информационной базы является закономерным явлением ее эксплуатации, но, в некоторых случаях, данный процесс свидетельствует об ошибках в архитектуре системы. Среда SQL Server Management Studio предоставляет возможность легко получить информацию о занимаемом БД месте на диске, в том числе: сводную информацию; в разрезе таблиц базы данных; индексов таблиц. Анализ необычных (для системы в целом) данных может выявить ошибки архитектуры и/или ошибки выполнения регламентных операций. Способы получить такую информацию о размере данных на диске будут рассмотрены в данной статье.
«Стандартные отчеты» в пользовательском интерфейсе Management Studio
SQL Server Management Studio предоставляет минимальный необходимый набор стандартных отчетов для получения информации о размере базы данных/ее файлов/таблиц/индексов в режиме пользовательского интерфейса.
Доступ к этим отчетам может быть выполнен через «Обозреватель объектов» (Object explorer) → Правый клик мыши по базе данных → «Отчеты» (Reports) → «Стандартный отчет» (Standard reports)
Стандартные отчеты по использованию дискового пространства
Отчет «Занято места на диске» (Disk Usage)
Отчет содержит общие сведения об использовании места на диске базой данных.
В отчете представлена информация следующего рода:
Отчеты «Использование дисковой памяти таблицей» (Disk Usage by Table), «Использование дисковой памяти верхними таблицами» (Disk Usage by Top Tables)
Отчет содержит подробные данные об использовании места на диске таблицами, расположенными в базе данных. Отличие этих двух отчетов заключается лишь в том что в отчете «By Top Tables» вывод происходит только для «верхних» (первых) 1000 таблиц.
В отчете представлена информация:
Отчет «Использование дисковой памяти секцией» (Disk Usage by Partition)
Отчет содержит подробные данные об использовании места на диске индексом и секциями, расположенными в базе данных.
Хотел бы обратить Ваше внимание что в данном отчете неверно рассчитывается дисковое пространство по кластерному индексу. Для получения реально используемого дискового пространства кластерным индексом можно: из «объема, используемого всеми индексами таблицы» (указанном в отчете «Использование дисковой памяти таблицей») вычесть «объем всех не кластерных индексов» (по отчету «Использование дисковой памяти секцией»)
В отчете представлена информация:
Хранимые процедуры
Данные о размере базы данных и таблиц также можно получить с помощью хранимой процедуры sp_spaceused Management Studio.
Синтаксис:
sp_spaceused [[ @objname = ] ‘objname’ ]
[,[ @updateusage = ] ‘updateusage’ ]
В процедуре могут быть использованы 2 не обязательных параметра:
Примеры запросов по всей базе данных и по конкретной таблице приведены ниже:
Как узнать размер базы данных в Microsoft SQL Server?
Иногда у разработчиков или администраторов Microsoft SQL Server возникает необходимость узнать размер базы данных, поэтому сегодня, специально для начинающих, я покажу несколько возможностей получения данной информации.
Надеюсь, Вы понимаете, что все действия, которые мы будем рассматривать в данном материале, требуют определенных знаний в части Microsoft SQL Server и языка T-SQL, поэтому если Вы новичок, то я Вам рекомендую предварительно или после прочтения данной статьи и в случае возникновения тех ли иных вопросов, ознакомиться со следующими материалами:
Итак, давайте начинать, причин, по которым Вам может потребоваться узнать размер базы данных, много, также и способов это сделать тоже много. Начнем мы с самого простого, который показывает общий размер базы данных, причем все действия Вы будете делать с помощью мышки.
Примечание! В качестве СУБД в примерах ниже будет использована версия Microsoft SQL Server 2016 Express. На данном экземпляре SQL сервер создана база данных TestBase, размер которой мы и будем узнавать.
Узнаем размер базы данных с помощью SQL Server Management Studio
Данный способ подразумевает использование графического инструмента SQL Server Management Studio и заключается он в открытие свойств конкретной базы данных, где как раз и есть информация о ее размере.
Для того чтобы узнать размер базы данных с помощью Management Studio, открываем ее и в «Обозревателе объектов» выбираем нужную базу данных, кликаем по ней правой кнопкой мыши и выбираем «Свойства».
В итоге у Вас откроется окно «Свойства базы данных», в котором будет отображено много информации. На вкладке «Общие» в разделе «База данных» есть свойство «Размер» — это как раз размер базы данных.
Данный способ, может быть, будет не удобен, если Вам, например, необходимо узнать размер каждого файла, который относится к базе данных (например, отдельно файл с данными и журнал транзакции) или у Вас несколько баз данных и Вам необходимо получить сведения сразу по всем.
Узнаем размер базы данных с использованием системной процедуры sp_helpdb
Следующий способ, можно сказать классический, подразумевает использованием системной хранимой процедуры sp_helpdb, которая может показать информацию как по одной базе данных, для этого в качестве параметра передаем имя базы данных, так и по всем, т.е. запускаем без параметров. В случае если мы указали конкретную базу данных, то SQL сервер нам вернет дополнительный результирующий набор, в котором мы увидим информацию обо всех файлах, относящихся к данной БД, включая их размер.
Как видите, нам вернулось два результирующих набора, первый общий, второй для каждого файла. Этот способ может быть для некоторых тоже не удобен, за счет того, что здесь мы используем процедуру. Поэтому переходим к следующему способу, который, как мне кажется, на текущий момент самый универсальный.
Определяем размер базы данных с помощью системного представления sys.database_files
Данный способ заключается в использовании системного представления sys.database_files, которое также возвращает много полезной информации в разрезе файлов базы данных.
Например, давайте с помощью данного представления определим общий размер базы данных в мегабайтах, а также размер каждого файла в текущей БД.
Размер базы данных в SQL сервере отображается в страницах по 8 КБ, поэтому для того чтобы посчитать размер БД в мегабайтах мы должны число, которое нам возвращает SQL сервер, не только поделить на 1024, но и умножить на 8, в примере выше использована сокращенная запись данной операции (1024/8=128), которая обычно используется в официальной документации.
В случае необходимости получить информацию о размере всех баз данных находящейся на текущем экземпляре SQL сервер, можно использовать представление sys.master_files, которое возвращает сведения обо всех файлах баз данных, расположенных на SQL Server.
Как Вы заметили, все три способа вернули нам одинаковый результат, так и должно быть, какой из способов Вам будет удобней использовать в той или иной ситуации, решать, конечно же, Вам, а у меня на этом все, удачи!
Отображение сведений о месте на диске, занимаемом данными и журналами базы данных
В этой статье описано, как отобразить данные и сведения о пространстве журнала для базы данных в SQL Server 2019 (15.x) с помощью среды SQL Server Management Studio или Transact-SQL.
Перед началом
Разрешение на выполнение процедуры sp_spaceused предоставлено роли public. Параметр @updateusage могут указывать только члены предопределенной роли базы данных db_owner.
Использование среды SQL Server Management Studio
Отображение данных и сведений о пространстве для базы данных
В обозревателе объектов подключитесь к экземпляру SQL Server и разверните его.
Разверните узел Базы данных.
Щелкните базу данных правой кнопкой мыши, наведите указатель на пункт Отчеты, затем на пункт Стандартные отчеты и выберите пункт Использование диска.
Использование Transact-SQL
Отображение данных и сведений о пространстве журнала для базы данных при помощи процедуры sp_spaceused
Установите соединение с компонентом Компонент Database Engine.
На стандартной панели инструментов выберите пункт Создать запрос.
Вставьте следующий пример в окно запроса и нажмите кнопку Выполнить. В этом примере используется системная хранимая процедура sp_spaceused, которая передает сведения о заполнении места на диске для всей базы данных, включая таблицы и индексы.
Отображение пространства данных, используемого объектом и единицей распределения для базы данных
Установите соединение с компонентом Компонент Database Engine.
На стандартной панели инструментов выберите пункт Создать запрос.
Вставьте следующий пример в окно запроса и нажмите кнопку Выполнить. В этом примере запрашиваются представления каталога объектов для сообщения об использовании дискового пространства на таблицу и в каждой таблице на единицу распределения.
Отображение данных и сведений о пространстве журнала для базы данных путем запроса к представлению каталога sys.database_files
Установите соединение с компонентом Компонент Database Engine.
На стандартной панели инструментов выберите пункт Создать запрос.
Исследуем базы данных с помощью T-SQL
Как 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)
Другие представления каталога, такие как 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 и в более поздних редакциях. Текст достаточно объёмный, я старался как мог его вычитать и найти свои ошибки (стилистические, синтаксические, смысловые и прочие), но, наверняка что-то не заметил, напишите мне в личку, пожалуйста, если что-то будет резать глаз.