растет неиспользуемое пространство БД

[den]

Насчет проблемы..похоже что да, именно так - выходит это проблема MSSQL

[cruger]

Да я не про open_object. Я про общее число используемых таблиц.

Так что насчёт эксперимента?

[den]

Что в Вашем понятии используемых ? Т.е. открытые и используемые по Вашему разные вещи ? Или просто общее кол-во физически таблиц БД инстэнса ? А тем временем, речь в той таблице идет об одновременно открытых объектах...

Над экспериментом подумаем.. как его провести показательно и безболезненно..)

[Evchic]

Я про общее число используемых таблиц.

Тут Федор как я понял имеет следующие...

Unused растет у тех таблиц интенсивно с которыми больше всего работают... поэтому посмотри текущий размер таблиц... и примерно через неделю у которых вырос unused те и будут состовлять список "используемых таблиц".. у меня это примерно 60 таблиц....
могу привести список...

[cruger]

Денис, по вашей ссылке приведена таблица. В ней описываются условия, в которых возникает проблема. Одна из колонок - threshold. Про неё сказано:
The cumulative number of tables in these databases is larger than the specific threshold that is listed in the table at the end of this section. These tables include the system table, the user table, and the temporary table.
Т.е. общее количество всех используемых таблиц, включая системные. Ну а в конечном-то итоге меня интересует, подпадает ли ваша конфигурация под указанные в таблице условия.

В качестве экспериментальных я бы предложил x$journal и какую-нибудь таблицу, данные в которой рассчитываются. Вроде таблица остатков таковая. Кластерный индекс - по nrec.

[den]

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

Может я чего не понимаю, но я читаю так..:

The cumulative number of tables in these databases is larger than the specific threshold that is listed in the table at the end of this section. These tables include the system table, the user table, and the temporary table.

и сразу далее
Applications that are connected to the instance of SQL Server reference most of these tables.

т..е получается все же в моем случае " общее количество больше 8192, и большинство из них используются приложениями
"

Опять же возвращаюсь к вопросу. Как посчитать/подсмотреть в скуле кол-во таких используемых объектов ???
Физически же в БД Галактики примерно 4500 табл (с учетом таблиц дублеров журнальных. Временных наверное не так много..). Учитывая что у меня работа в основном ведется с одной БД, то исходя из этого по идее порог не должен быть превышен. А в тестовые базы только я сам захожу иногда ,но это нечасто.


Про эксперимент :
- Пока не делал урезания места физ файлов схем БД (с помощью переиндексации с кластеризацией). Планирую на след. неделе. Но думаю пока не переиндексировать таб x$journal & t$oborot и посмотреть за неделю какова будет статистика по ним. Далее через неделю запустить по ним тоже переиндексацию с кластеризацией, как хочет Федор, по нреку и за неделю опять же собрать статистику по этим таблицам.
Есть замечания ? предложения ?

[Evchic]

Есть замечания ? предложения ?

Есть...
Федор говорит не о "переиндексацию с кластеризацией", а о том чтоб сделть NREC постоянным кластерным индексом.

[den]

Евгений, ты имеешь ввиду что просто выставить флаг clustered у существующего индекса по нрек у конкретной таб ?

[cruger]

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

Евгений правильно меня понял - кластерный индекс по нреку.
Просто выставить флаг возможно нехорошо, т.к. в индексе прописано, что жить он должен в файловом пространстве индексов. Вероятно данные переедут туда. Может и нет - надо доку смотреть.

Нреки у нас формируются строго последовательно, т.е. в этом индексе все новые записи также будут размещаться последовательно, без пустот. Вопрос с тем, что будет после удаления.
Есть два крайних варианта:
- последовательное удаление старых данных, как в журнале. В этом случае от старых данных страницы очищаются целиком. Вопрос - будет ли сервер размещать там новые данные?
- удаление в случайном порядке. Сходу затрудняюсь порекомендовать такую таблицу, но можно проконсультироваться с прикладниками. Понятно, что из почти любой обычной таблицы удаления происходят случайно. Но в данном случае интересуют массовые удаления. И собственно вопросы: насколько часто придётся переиндексировать такую таблицу, что б убрать из используемых страниц пустоты, т.е. фактически насколько быстро будет расти неиспользуемое пространство? Если довольно быстро, то возможно для таких таблиц стоит выбрать другой кластерный индекс.

[Evchic]

- удаление в случайном порядке. Сходу затрудняюсь порекомендовать такую таблицу, но можно проконсультироваться с прикладниками. Понятно, что из почти любой обычной таблицы удаления происходят случайно. Но в данном случае интересуют массовые удаления. И собственно вопросы: насколько часто придётся переиндексировать такую таблицу, что б убрать из используемых страниц пустоты, т.е. фактически насколько быстро будет расти неиспользуемое пространство? Если довольно быстро, то возможно для таких таблиц стоит выбрать другой кластерный индекс.

Пример такой таблы SpAllcon... при переформирования ПО