Sql сколько памяти занимает таблица
Если я правильно понял, то на объём(размер) таблицы, который она занимает на диске компьютера, влияет тип таблицы, тип полей и т.д.
Вопрос
Как рассчитать объём таблицы?
Есть какие-нибудь калькуляторы для этих целей?
Никак, количество ваших записей в таблице будет отличаться от прогнозируемого с околоединичной вероятностью, а полученный расчет все равно будет бесполезен для экономии дискового пространства, потому что у вас всегда должно быть свободно от 50% места на случай всплеска активности.
Если размер записи фиксирован, то можно посчитать объём таблицы с достаточно большой точностью. NULL-поля, поля переменной длины, блобы — усложняют расчёт. Если у вас поле varchar(500) , где обычно лежат 5 символов, то надо считать именно 5 символов, а не 500.
Объекты репликации
Максимальные размеры и количества для различных объектов, определяемых в компонентах репликации SQL Server .
SQL Server Объект Replication | Максимальные размеры и количества для SQL Server (64-разрядная версия) |
---|---|
Статей (публикация слиянием) | 2048 |
Статей (моментальный снимок или публикация транзакций) | 32 767 |
Столбцов в таблице * (публикация слиянием) | 246 |
Столбцов в таблице ** (моментальный снимок или публикация транзакций SQL Server) | 1000 |
Столбцов в таблице ** (моментальный снимок или публикация транзакций Oracle) | 995 |
Байтов на столбец, используемый в фильтре строк (публикация слиянием) | 1024 |
Байтов на столбец, используемый в фильтре строк (моментальный снимок или публикация транзакций) | 8000 |
* Если для обнаружения конфликтов применяется трассировка на уровне строк (по умолчанию), базовая таблица может содержать не более 1024 столбцов, однако столбцы из статьи должны быть отфильтрованы, чтобы было опубликовано не более 246 столбцов. Если применяется трассировка на уровне столбцов, базовая таблица может содержать не более 246 столбцов.
** Базовая таблица может включать максимальное количество столбцов, разрешенное в базе данных публикации (1024 для SQL Server), но столбцы должны быть отфильтрованы из статьи, если они превышают максимальное количество, заданное для данного типа публикации.
До выхода SQL Server 2016 (13.x); размер данных "в строке" для таблицы, оптимизированной для памяти, не мог превышать 8060 байт. Но в SQL Server 2016 (13.x); и более поздних версиях, а также в базе данных SQL Azure появилась возможность создать таблицу, оптимизированную для памяти, с несколькими большими столбцами (например, несколькими столбцами varbinary(8000)) и столбцами LOB (т. е. varbinary(max), varchar(max) и nvarchar(max)), и выполнять с ними операции, используя типы таблиц и модули T-SQL, скомпилированные в собственном коде.
Столбцы, превышающие максимальный размер строки в 8060 байт, размещаются вне строки в специальной внутренней таблице. У каждого такого столбца имеется соответствующая внутренняя таблица, которая, в свою очередь, имеет один некластеризованный индекс. Дополнительные сведения об этих внутренних таблицах, используемых для столбцов вне строк, см. в разделе sys.memory_optimized_tables_internal_attributes (Transact-SQL).
Существуют определенные сценарии, в которых удобно вычислять размер строки и таблицы.
Какой объем памяти используется таблицей?
Объем используемой таблицей памяти невозможно подсчитать точно. На объем используемой памяти влияет множество факторов. Это такие факторы, как постраничное выделение места в памяти, размещение, кэширование и заполнение. Кроме того, несколько версий строк, которые имеют активные связанные транзакции либо ожидают сборку мусора.
Минимальный размер, необходимый для данных и индексов в таблице, определяется вычислением для [размера таблицы], о котором рассказывается ниже.
Вычисление используемой памяти в самом лучшем случае может быть выполнено лишь приближенно, поэтому рекомендуется включить планирование вместимости в планы разработки.
Каков размер строки данных, и укладывается ли он в ограничение размера строки 8060 байт? Чтобы получить ответ на эти вопросы, используйте вычисление для [размера текста строки], о котором рассказывается ниже.
Таблица, оптимизированная для памяти, представляет собой набор строк, а также индексов, которые содержат указатели на строки. На следующей схеме показана таблица с индексами и строками, которые в свою очередь содержат заголовки и текст:
Таблица, оптимизированная для памяти, состоящая из индексов и строк.
Объекты Компонент Database Engine
Максимальные размеры и количество различных объектов, определяемых в базах данных SQL Server или ссылающихся на них Transact-SQL инструкциях.
Можно определить ключ, использующий столбцы переменной длины, максимальная длина которых превышает лимит. При этом совокупные размеры данных в этих столбцах ни в коем случае не могут превышать лимит.
Размер ключа для хэш-индекса не ограничивается.
Для индексов в таблицах, оптимизированных для памяти, понятие включенных столбцов не используется, поскольку все индексы по определению охватывают все столбцы.
25 экземпляров отказоустойчивого кластера при использовании общих дисков кластера в качестве хранилища.
Отчет «Использование дисковой памяти секцией» (Disk Usage by Partition)
Отчет содержит подробные данные об использовании места на диске индексом и секциями, расположенными в базе данных.
Хотел бы обратить Ваше внимание что в данном отчете неверно рассчитывается дисковое пространство по кластерному индексу. Для получения реально используемого дискового пространства кластерным индексом можно: из «объема, используемого всеми индексами таблицы» (указанном в отчете «Использование дисковой памяти таблицей») вычесть «объем всех не кластерных индексов» (по отчету «Использование дисковой памяти секцией»)
В отчете представлена информация:
Отчеты «Использование дисковой памяти таблицей» (Disk Usage by Table), «Использование дисковой памяти верхними таблицами» (Disk Usage by Top Tables)
Отчет содержит подробные данные об использовании места на диске таблицами, расположенными в базе данных. Отличие этих двух отчетов заключается лишь в том что в отчете «By Top Tables» вывод происходит только для «верхних» (первых) 1000 таблиц.
В отчете представлена информация:
- Количество записей в таблице базы данных (Records)
- Размер зарезервированного пространства на диске (Reserved)
- Размер данных на диске (Data)
- Общий размер индексов таблицы на диске (Indexes)
- Размер не используемого пространства (Unused)
Примеры диагностируемых ошибок
Ошибка | Следствие |
---|---|
Использование остаточного регистра накопления для оборотных данных | Итоговая таблица регистра накопления не будет закрываться, что приведет к ее чрезмерному разрастанию |
Ошибки в алгоритме закрытия остаточного регистра | Аналогично предыдущей ошибке |
Отсутствует перерасчет итогов по регистрам | Рост таблицы итоговых записей за счет «нулевых» записей |
Использование избыточных индексов | Рост размера индексов таблицы |
Хранение массивных двоичных данных в таблицах БД | Рост размера таблицы |
Данный перечень не является полным, но одним из общих сигналов приведенных выше ошибок является чрезмерный рост тех или иных таблиц базы данных. Естественно, большой размер таблиц/индексов не является прямым указанием на наличие ошибок, в то же время следует «приглядеться» к такого рода сигналам и провести их анализ.
Для ошибок «Использование остаточного регистра накопления для оборотных данных» и «Ошибки в алгоритме закрытия остаточного регистра» рост таблиц итоговых записей является буквально прямым следствием, но, возможна ситуация, что таков набор данных (приход был, а расхода еще не было).
Для ошибки «Отсутствует перерасчет итогов по регистрам» также характерен рост таблицы итоговых записей, но при этом (особенно для регистра остатков) дополнительным условием является наличие «нулевых» записей в регистре итогов. Подробнее об этом можно прочитать в статье «Что такое итоги регистров накопления».
Для ошибки «Использование избыточных индексов» первоочередным, конечно же, является анализ необходимости такого индекса. Но никто не станет анализировать все индексы базы данных без причин, а вот наличие «тяжелых» индексов таблицы может стать одним из таких сигналов к действию.
Касательно «Хранения массивных двоичных данных в таблицах БД», я считаю это неприемлемым, данные такого рода должны храниться на диске независимо от базы данных с обеспечением доступа к ним из системы, а также с обеспечением отдельной процедуры резервного копирования.
Объекты служебной программы SQL Server
Максимальные размеры и количество для различных объектов, которые были проверены в служебной программе SQL Server .
SQL Server Объект программы | Максимальный размер или количество SQL Server (64-разрядная версия) |
---|---|
Компьютеры (физические или виртуальные машины) в расчете на одну программу SQL Server | 100 |
Экземпляров SQL Server на компьютер | 5 |
Общее число экземпляров SQL Server на одну служебную программу SQL Server | 200 * |
Пользовательских баз данных на экземпляр SQL Server, включая приложения на уровне данных | 50 |
Общее число пользовательских баз данных на одну служебную программу SQL Server | 1000 |
Файловых групп на одну базу данных | 1 |
Файлов данных на одну файловую группу | 1 |
Файлов журналов на одну базу данных | 1 |
Томов на компьютер | 3 |
* Максимальное число управляемых экземпляров SQL Server, поддерживаемых служебной программой SQL Server, может меняться в зависимости от конфигурации оборудования сервера. Дополнительные сведения о начале работы см. в разделе Функции и задачи служебной программы SQL Server. SQL Server доступна не во всех выпусках SQL Server. Список функций, поддерживаемых в выпусках SQL Server, см. в разделах Функции, поддерживаемые выпусками SQL Server 2019, Функции, поддерживаемые выпусками SQL Server 2017 и Функции, поддерживаемые выпусками SQL Server 2016.
Вычисление размера таблицы
Размер, занимаемый таблицей в памяти (в байтах) вычисляется следующим образом.
Размер хэш-индекса фиксируется на момент создания таблицы и зависит от фактического числа контейнеров. Значение bucket_count , указанное спецификацией индекса, округляется в сторону увеличения до ближайшей степени числа 2 для получения фактического числа контейнеров. Например, если заданное число bucket_count равно 100 000, то фактическое число контейнеров для индекса составляет 131 072.
Размер некластеризованного индекса определяется в [row count] * [index key size] .
Размер строки вычисляется путем сложения значений для заголовка и текста:
Основные инструкции по оценке требований к памяти
Начиная с SQL Server 2016 (13.x);, не существует ограничений на размер таблиц, оптимизированных для памяти, хотя таблицы должны умещаться в памяти. В SQL Server 2014 (12.x) размер поддерживаемой данных — 256 ГБ для таблиц SCHEMA_AND_DATA.
Размер оптимизированной для памяти таблицы соответствует размеру данных плюс определенный объем для размещения заголовков строк. При переносе дисковой таблицы в таблицу, оптимизированную для памяти, размер оптимизированной для памяти таблицы будет примерно соответствовать размеру кластеризованного индекса или кучи исходной дисковой таблицы.
Индексы в таблицах, оптимизированных для памяти, как правило, меньше, чем некластеризованные индексы в дисковых таблицах. Размер некластеризованных индексов равен порядка [primary key size] * [row count] . Размер хэш-индексов — [bucket count] * 8 bytes .
Если имеется активная рабочая нагрузка, дополнительная память требуется для управления версиями строк и различных операций. Объем необходимой памяти на практике зависит от рабочей нагрузки, однако для надежности рекомендуется начинать с объема памяти, в два раза превышающего ожидаемый размер оптимизированных для памяти таблиц и индексов и наблюдать, каковы потребности в памяти на самом деле. Объем дополнительных затрат ресурсов на управление версиями строк всегда зависит от характеристик рабочей нагрузки. Так, длительные транзакции увеличивают нагрузку на память особенно сильно. Для большинства рабочих нагрузок, использующих более крупные базы данных (например, более 100 ГБ), расход ресурсов ограничен (25 % и менее).
В этой статье приведены максимальные размеры и количество для разных объектов, определяемых в SQL Server версии 2016 и выше.
В дополнение к сведениям, приведенным в этой статье, вы можете ознакомиться с информацией по следующим ссылкам.
SQL Server Объекты приложений уровня данных
Максимальные размеры и количество различных объектов, которые были протестированы в приложениях уровня данных SQL Server .
SQL Server Объект приложения уровня данных | Максимальный размер или количество SQL Server (64-разрядная версия) |
---|---|
Баз данных на DAC | 1 |
Объектов на приложение уровня данных * | Ограничено числом объектов в базе данных или доступной памятью. |
* Типы объектов, включенные в ограничения, — пользователи, таблицы, представления, хранимые процедуры, определяемые пользователем функции, определяемые пользователем типы данных, роли баз данных, схемы и определяемые пользователем табличные типы.
Вычисление размера текста строки
Структура строк. Строки в таблице, оптимизированной для памяти, включают следующие компоненты.
Заголовок строки содержит метку времени, необходимую для управления версиями строки. Заголовок строки также содержит указатель индекса, который позволяет реализовать цепочку строк в хэш-контейнере (описано выше).
Текст строки содержит фактические данные столбцов, которые включают некоторые вспомогательные сведения, такие как массив значений NULL для столбцов, допускающих значение NULL, и массив смещений для типов данных с переменной длиной.
На следующем рисунке показана структура строк для таблицы с двумя индексами.
Метки времени начала и конца показывают период, в котором определенная версия строки является допустимой. Транзакции, запускаемые в данном интервале, могут видеть эту версию строки. Дополнительные сведения см. в разделе Транзакции с таблицами, оптимизированными для памяти.
Указатели индекса указывают на следующую строку в цепочке, принадлежащей хэш-контейнеру. На следующем рисунке показана структура таблицы с двумя столбцами (имя, город) и двумя индексами, один для столбца name и второй для столбца city.
На этом рисунке имена Джон и Джейн хэшированы на первый контейнер. Сьюзан хэширована на втором контейнере. Города Пекин и Богота хэшированы на первом контейнере. Париж и Прага хэшированы на втором контейнере.
Таким образом, цепочки для хэш-индекса по именам выглядят следующим образом.
Первый контейнер: (Джон, Пекин); (Джон, Париж); (Джейн, Прага)
Второй контейнер: (Сьюзан, Богота)
Цепочки для индекса по городам выглядят следующим образом:
Первый контейнер: (Джон Пекин), (Сьюзан, Богота)
Второй контейнер: (Джон, Париж), (Джейн, Прага)
Конечная метка времени ∞ (бесконечность) указывает, что это действительная на данный момент версия строки. Строка была обновлена или удалена с того момента, как была записана эта версия.
Для времени больше 200 таблица содержит следующие строки.
Имя | Город |
---|---|
Джон | Пекин |
Джейн | Прага |
Однако любая активная транзакция с начальным временем 100 увидит следующую версию таблицы.
Имя | Город |
---|---|
Джон | Париж |
Джейн | Прага |
Сьюзан | Богота |
Вычисление [размера текста строки] демонстрируется в следующей таблице.
Размер текста строки вычисляется двумя способами: вычисляемый размер и фактический размер.
Вычисляемый размер (далее — вычисляемый размер строки) используется для того, чтобы определить, не превышает ли размер строки ограничение в 8060 байт.
Фактический размер (далее — фактический размер строки) представляет собой фактический размер строки в памяти и в файлах контрольных точек.
Оба показателя, вычисляемый размер строки и фактический размер строки, вычисляются схожим образом. Отличается только вычисление размера столбцов (n)varchar(I) и столбцов varbinary (I), как показано в нижней части таблицы. Вычисляемый размер строки использует в качестве размера столбца декларируемый размер i , тогда как фактический размер строки использует фактический размер данных.
В следующей таблице описано вычисление размера текста строки как фактический размер текста строки = SUM(размер мелких типов) + 2 + 2 * число столбцов глубокого типа.
Bit: 1
Tinyint: 1
Smallint: 2
Int: 4
Real: 4
Smalldatetime: 4
Smallmoney: 4
Bigint: 8
Datetime: 8
Datetime2: 8
Float: 8
Money: 8
Числовой (точность <=18): 8
Time: 8
Numeric(precision18>): 16
1, если в таблице присутствуют столбцы глубоких типов, а общий размер данных в столбцах поверхностного типа является нечетным числом.
0, если в таблице нет столбцов глубоких типов
1, если в таблице имеются столбцы глубоких типов данных и размер массива значений NULL равен нечетному числу байтов.
Размер каждого столбца составляет:
i для типов char(i) и binary(i).
вычисляемый размер каждого столбца составляет:
i для типов varchar(i) и varbinary(i)
Фактический размер каждого столбца составляет:
n, где n — количество символов, хранящихся в столбце, для типа varchar(i).
2 * n, где n — количество символов, хранящихся в столбце, для типа nvarchar(i).
«Стандартные отчеты» в пользовательском интерфейсе Management Studio
SQL Server Management Studio предоставляет минимальный необходимый набор стандартных отчетов для получения информации о размере базы данных/ее файлов/таблиц/индексов в режиме пользовательского интерфейса.
Доступ к этим отчетам может быть выполнен через «Обозреватель объектов» (Object explorer) → Правый клик мыши по базе данных → «Отчеты» (Reports) → «Стандартный отчет» (Standard reports)
Стандартные отчеты по использованию дискового пространства
Пример: вычисление размера строки и таблицы
Для хэш-индекса фактическое число контейнеров округляется в сторону увеличения до ближайшей степени числа 2. Например, если заданное число bucket_count равно 100 000, то фактическое число контейнеров для индекса составляет 131 072.
Рассмотрим таблицу Orders со следующим определением:
Обратите внимание, что эта таблица содержит один хэш-индекс и некластеризованный индекс (первичный ключ). Кроме того, она содержит три столбца фиксированной длины и один столбец переменной длины, при этом один из столбцов допускает значения NULL ( OrderDescription ). Допустим, таблица Orders содержит 8379 строк, а средняя длина значений в столбце OrderDescription составляет 78 символов.
Чтобы определить размер таблицы, сначала необходимо определить размер индексов. Для обоих индексов указан показатель bucket_count, равный 10 000. Эта величина округляется в большую сторону до ближайшей степени числа 2: 16384. Поэтому общий размер индексов для таблицы Orders составляет:
Остается найти размер данных таблицы, который равен
(Пример таблицы содержит 8379 строк.) Теперь у нас есть:
Теперь давайте рассчитаем [фактический размер текста строки].
Столбцы поверхностных типов:
Заполнение для столбцов поверхностных типов равно 0, поскольку общий размер столбцов поверхностного типа является четным числом.
Массив смещений для столбцов глубоких типов:
Массив значений NULL = 1
Заполнение массива значений NULL = 1, так как размер массива значений NULL является нечетным числом, а в таблице есть столбцы глубоких типов.
8 — наибольшее требования выравнивания.
Размер на данный момент равен 16 + 0 + 4 + 1 + 1 = 22.
Ближайшее число, кратное 8, — это 24.
В итоге заполнение составляет 24 – 22 = 2 байта.
В таблице нет столбцов глубоких типов фиксированной длины (столбцов глубоких типов фиксированной длины: 0).
Фактический размер столбца глубокого типа составляет 2 * 78 = 156. Единственный столбец глубокого типа OrderDescription имеет тип nvarchar .
Для завершения вычисления:
Таким образом, общий размер, занимаемый таблицей в памяти, составляет около 2 мегабайт. Это значение не учитывает потенциальные издержки при выделении памяти, а также управление версиями строк, необходимое для доступа транзакций к этой таблице.
Фактический размер памяти, выделяемый для данной таблицы и используемый ею и ее индексами, можно получить при помощи следующего запроса:
Ограничения столбца "вне строки"
Ниже перечислены некоторые ограничения и пояснения, касающиеся использования столбцов "вне строки" в таблице, оптимизированной для памяти.
Рост размера информационной базы является закономерным явлением ее эксплуатации, но, в некоторых случаях, данный процесс свидетельствует об ошибках в архитектуре системы. Среда SQL Server Management Studio предоставляет возможность легко получить информацию о занимаемом БД месте на диске, в том числе: сводную информацию; в разрезе таблиц базы данных; индексов таблиц. Анализ необычных (для системы в целом) данных может выявить ошибки архитектуры и/или ошибки выполнения регламентных операций. Способы получить такую информацию о размере данных на диске будут рассмотрены в данной статье.
Динамические административные представления
Помимо вышеприведенных способов, для получения необходимой информации можно обратиться к динамическим административным представлениям. На самом деле, как отчеты, так и хранимая процедура sp_spaceused сама их и использует. Способы получения информации с помощью динамических административных представлений будут рассмотрены в следующих статьях.
Хранимые процедуры
Данные о размере базы данных и таблиц также можно получить с помощью хранимой процедуры sp_spaceused Management Studio.
Синтаксис:
sp_spaceused [[ @objname = ] ‘objname’ ]
[,[ @updateusage = ] ‘updateusage’ ]
В процедуре могут быть использованы 2 не обязательных параметра:
- @objname — Полное или неполное имя таблицы, индексированного представления или очереди. Если параметр не указан — результаты возвращаются для всей базы данных.
- @updateusage — Указывает на необходимость запустить процедуру обновления сведений
Примеры запросов по всей базе данных и по конкретной таблице приведены ниже:
Результат работы хранимой процедуры sp_spaceused
В первом блоке отражен результат запроса по всей базе данных, во втором — по конкретной таблице.
1 ответ 1
Точно объем таблицы можно посчитать только в случае, если размер записи фиксирован. Для этого надо, чтобы:
Все поля записи имели фиксированный размер. char(50) всегда имеет размер 50 байт, в то время как varchar(50) имеет размер от 1 до 51 байт.
Запись не содержала NULL-полей.
Размеры типов можно найти в документации по MySQL.
Типы nchar , varchar , varbinary , tinyblob , tinytext , blob , text , mediumblob , mediumtext , longblob , longtext не имеют фиксированного размера. Если таблица содержит поля этих типов, точный её размер посчитать невозможно. Иногда размер можно посчитать приблизительно с высокой точностью, если понятно, какие данные будут хранится.
Все остальные типы имеют фиксированный размер. INT 4 байта, это просто. CHAR(7) 7 байт. Размер NUMERIC(12, 3) посчитать сложнее, поскольку MySQL упаковывает каждые 9 десятичных цифр в 4 байта.
Каждая запись содержит служебный заголовок, который имеет размер от 5 байт. Если NULL-поле имеет значение NULL, оно не хранится в записи, просто выставляется бит в заголовке.
После того, как размер таблицы посчитан в байтах, можно прикинуть, сколько она занимает места на диске. Для скорости MySQL хранит данные большими страницами, блоками размером 4Кбайт или 8Кбайт. Если запись с заголовком занимает 100 байт, а размер страницы 4096 байт, то на странице поместится 40 записей и ещё останется 96 пустых байт на каждой странице. 400 записей займут на диске 10 страниц или 40Кбайт.
Помимо данных, таблица содержит индексы, каждый из которых тоже занимает место. Если в индексе встречаются поля типов переменного размера, сам индекс также будет переменного размера.
Не смотря на то, что точный размер таблицы определить трудно, на практике достаточно бывает оценить порядок.
Дополнительно
Когда MySQL хранит текст, то она и цифры хранит как обычные символы. Скажем, в кодировке UTF-8 все цифры занимают один байт, а русские буквы занимают 2 байта. Чтобы считать корректно, необходимо знать, какая кодировка используется для данного поля.
Типы INT и т.д. хранят числа в двоичной системе. INT всегда требует 4 байта, где хранится целое число в интервале -2 31 ..2 31 −1.
Тип DECIMAL хранит числа в десятичной системе, используя хитрое кодирование, чтобы упаковывать каждые 3 десятичные цифры в 10 бит (каждые 9 цифр в 4 байта).
Типы BIT(n) упаковываются вместе в достаточное количество байт. BIT(3) всегда будет занимать 1 байт, потому что меньше памяти выделить невозможно. Но два поля по BIT(3) также будут занимать 1 байт, поскольку MySQL будет хранить их вместе.
Оптимизированные для памяти таблицы требуют наличия достаточного объема памяти для хранения всех строк и индексов в памяти. Поскольку память является ограниченным ресурсом, важно понимать принципы управления загруженностью памяти в системе. Темы в этом разделе описывают распространенные сценарии использования и управления памятью.
При создании новой, оптимизированной для памяти таблицы или переносе существующей на диске таблицы в таблицу Выполняющаяся в памяти OLTP, оптимизированную для памяти, важно иметь оценку требований к памяти для каждой таблицы, чтобы подготовить сервер с достаточным объемом памяти. В этом разделе описывается, как определить объем памяти, необходимый для хранения данных в таблице, оптимизированной для памяти.
Если вы рассматриваете переход от дисковых таблиц к таблицам, оптимизированным для памяти, то перед продолжением чтения посмотрите в разделе Определение, должна ли таблица или хранимая процедура быть перенесена в In-Memory OLTP сведения о том, какие таблицы лучше всего подходят для миграции. Все разделы статьи Миграция в In-Memory OLTP содержат руководство по миграции дисковых таблиц в оптимизированные для памяти.
Отчет «Занято места на диске» (Disk Usage)
Отчет содержит общие сведения об использовании места на диске базой данных.
В отчете представлена информация следующего рода:
- Общий объем, занятый на диске (Total space reserved)
- Место, занятое файлами данных (Data files space reserved)
- Место, занятое журналом транзакций (Transaction log space reserved)
- Отражает графически процент пространств в составе файлов данных: индексов (index), данных (data), не выделенного (unallocated) и не используемого (unused)
- Отражает графически процент примененного (used) и неиспользуемого (unused) пространства в составе журнала транзакций
- Выводит записи событий автоматического увеличения (autogrow) и/или сжатия (autoshrink) для базы данных
- Выводит информацию о месте на диске, используемом файлами данных
Читайте также: