растет неиспользуемое пространство БД
Модератор: mike
- Evchic
- партнер
- Сообщения: 88
- Зарегистрирован: Пн, 17/09/2007 07:57
- Имя Фамилия: Евгений Ильин
- Откуда: Галактика ЮГ г.Ростов-на-Дону
- Контактная информация:
Тут Федор как я понял имеет следующие...Я про общее число используемых таблиц.
Unused растет у тех таблиц интенсивно с которыми больше всего работают... поэтому посмотри текущий размер таблиц... и примерно через неделю у которых вырос unused те и будут состовлять список "используемых таблиц".. у меня это примерно 60 таблиц....
могу привести список...
-
- топ-софт
- Сообщения: 566
- Зарегистрирован: Пт, 21/09/2007 15:19
- Имя Фамилия: Фёдор Терсин
- Откуда: Галактика Софт
- Контактная информация:
Денис, по вашей ссылке приведена таблица. В ней описываются условия, в которых возникает проблема. Одна из колонок - 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.
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.
-
- заказчик
- Сообщения: 117
- Зарегистрирован: Пт, 26/10/2007 14:16
- Имя Фамилия: Денис Кучин
- Откуда: Геомостпроект НПО
Может я чего не понимаю, но я читаю так..:cruger писал(а): ...
Т.е. общее количество всех используемых таблиц, включая системные. Ну а в конечном-то итоге меня интересует, подпадает ли ваша конфигурация под указанные в таблице условия.
...
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 и посмотреть за неделю какова будет статистика по ним. Далее через неделю запустить по ним тоже переиндексацию с кластеризацией, как хочет Федор, по нреку и за неделю опять же собрать статистику по этим таблицам.
Есть замечания ? предложения ?
-
- топ-софт
- Сообщения: 566
- Зарегистрирован: Пт, 21/09/2007 15:19
- Имя Фамилия: Фёдор Терсин
- Откуда: Галактика Софт
- Контактная информация:
Денис, урезать пространство, насколько я понимаю, вполне можно без переиндексации. Для этого надо урезать файлы, а не базы. Для начала надо запустить режим, который перенесёт все непустые страницы в начало файла, а уж потом этот файл обрезать.
Евгений правильно меня понял - кластерный индекс по нреку.
Просто выставить флаг возможно нехорошо, т.к. в индексе прописано, что жить он должен в файловом пространстве индексов. Вероятно данные переедут туда. Может и нет - надо доку смотреть.
Нреки у нас формируются строго последовательно, т.е. в этом индексе все новые записи также будут размещаться последовательно, без пустот. Вопрос с тем, что будет после удаления.
Есть два крайних варианта:
- последовательное удаление старых данных, как в журнале. В этом случае от старых данных страницы очищаются целиком. Вопрос - будет ли сервер размещать там новые данные?
- удаление в случайном порядке. Сходу затрудняюсь порекомендовать такую таблицу, но можно проконсультироваться с прикладниками. Понятно, что из почти любой обычной таблицы удаления происходят случайно. Но в данном случае интересуют массовые удаления. И собственно вопросы: насколько часто придётся переиндексировать такую таблицу, что б убрать из используемых страниц пустоты, т.е. фактически насколько быстро будет расти неиспользуемое пространство? Если довольно быстро, то возможно для таких таблиц стоит выбрать другой кластерный индекс.
Евгений правильно меня понял - кластерный индекс по нреку.
Просто выставить флаг возможно нехорошо, т.к. в индексе прописано, что жить он должен в файловом пространстве индексов. Вероятно данные переедут туда. Может и нет - надо доку смотреть.
Нреки у нас формируются строго последовательно, т.е. в этом индексе все новые записи также будут размещаться последовательно, без пустот. Вопрос с тем, что будет после удаления.
Есть два крайних варианта:
- последовательное удаление старых данных, как в журнале. В этом случае от старых данных страницы очищаются целиком. Вопрос - будет ли сервер размещать там новые данные?
- удаление в случайном порядке. Сходу затрудняюсь порекомендовать такую таблицу, но можно проконсультироваться с прикладниками. Понятно, что из почти любой обычной таблицы удаления происходят случайно. Но в данном случае интересуют массовые удаления. И собственно вопросы: насколько часто придётся переиндексировать такую таблицу, что б убрать из используемых страниц пустоты, т.е. фактически насколько быстро будет расти неиспользуемое пространство? Если довольно быстро, то возможно для таких таблиц стоит выбрать другой кластерный индекс.
- Evchic
- партнер
- Сообщения: 88
- Зарегистрирован: Пн, 17/09/2007 07:57
- Имя Фамилия: Евгений Ильин
- Откуда: Галактика ЮГ г.Ростов-на-Дону
- Контактная информация:
Пример такой таблы SpAllcon... при переформирования ПО- удаление в случайном порядке. Сходу затрудняюсь порекомендовать такую таблицу, но можно проконсультироваться с прикладниками. Понятно, что из почти любой обычной таблицы удаления происходят случайно. Но в данном случае интересуют массовые удаления. И собственно вопросы: насколько часто придётся переиндексировать такую таблицу, что б убрать из используемых страниц пустоты, т.е. фактически насколько быстро будет расти неиспользуемое пространство? Если довольно быстро, то возможно для таких таблиц стоит выбрать другой кластерный индекс.