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

Инсталляция, обновления, нюансы БД, администрирование системы

Модератор: mike

den
заказчик
Сообщения: 117
Зарегистрирован: Пт, 26/10/2007 14:16
Имя Фамилия: Денис Кучин
Откуда: Геомостпроект НПО

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

Сообщение den »

Гал81, SQl2000(sp4). Может конечно не совсем в тематику данного форума, но может люд местный чем то поможет.

Опишу вкратце историю проблемы. Не так давно (с февраля), данные были отконвертирваны в версию 8.1 (перед этим переставляли сервер). После этого стал замечать большой прирост файлов БД схем data, index, journal. Решил проанализировать состояние бд, выполнив следующий скрипт:

Код: Выделить всё

if exists (select * from information_schema.tables where table_name = 'tmp_info') drop table tmp_info 
declare c_tables cursor for select table_name from information_schema.tables where table_type = 'BASE TABLE' and table_schema = 'dbo'
declare @tname varchar(100)
create table tmp_info (name varchar(100), rows int, reserved varchar(100), data varchar(100), index_size varchar(100), unused varchar(100))
open c_tables
fetch next from c_tables into @tname
while @@fetch_status = 0 begin
insert into tmp_info exec sp_spaceused @tname
fetch next from c_tables into @tname
end
close c_tables
deallocate c_tables
select * from tmp_info order by cast(replace(reserved, 'kb', '') as integer) desc
весь результат не буду приводить, но результаты получаются выборочно вот такие :

Код: Выделить всё

-------------------------rows----------reserved -----------data ----------index-----------unused

X$JOURNAL -----995544 --------17170600 KB ------1968800 KB---- 258112 KB ---14943688 Kb
T$OBOROT -----196532 ---------1245640 KB ------ 118744 KB----- 367512 KB ----- 759384 KB
T$HASHAN -----292404 ---------513032 KB---------- 69072 KB -------75456 KB ---- 368504 KB
.... и т.д.

--------------------------------------------------------------------------------
ИТОГО ---- 3844570 ------ 34852008 ---------4260520 ------- 1304152 ----- 29287336
Как видно, очень большая доля неиспользуемого пространства.
Все попытки его сократить не увеничиваются успехом (DBCC SHRINKDATABASE(databse), DBCC SHRINKFILE ). Размер unused практически ооочень ненамного снижается. Что еще предпринять , не знаю. Знаю только что при наших объемах занесения данных, такого прироста быть не должно. Да и главный вопрос ,почему он хавает все больше и больше простр-ва под прирост БД (стоит 10 %). Смущает еще то,что при shrinke по правой кнопке мыши на БД показывается space allocated 36067, space free 1741. Типа все занято. Теперь вот размер текущей БД по сравнению с размером доконвертируемой БД стал в 10 раз больше. Но главное, что динамика большого роста имеет место постоянно быть в росте файлов при относительно небольшом объеме прироста данных реальных.

Есть какие то соображения по вышесказанному?
А то уже устал думать 3-й день...
cruger
топ-софт
Сообщения: 566
Зарегистрирован: Пт, 21/09/2007 15:19
Имя Фамилия: Фёдор Терсин
Откуда: Галактика Софт
Контактная информация:

Сообщение cruger »

а неиспользуемое место на страницах данных или индексов?
den
заказчик
Сообщения: 117
Зарегистрирован: Пт, 26/10/2007 14:16
Имя Фамилия: Денис Кучин
Откуда: Геомостпроект НПО

Сообщение den »

Сделал для примера по 2-м таблицам showcontig :

Код: Выделить всё

DBCC SHOWCONTIG(t$hashan) with all_indexes,tableresults :
DBCC SHOWCONTIG(t$oborot) with all_indexes,tableresults :
Насколько я понимаю, незаюзанное место на страницах данных и индексов:
100 %- Avg. Page Density (full)

результаты прилагаю...
den
заказчик
Сообщения: 117
Зарегистрирован: Пт, 26/10/2007 14:16
Имя Фамилия: Денис Кучин
Откуда: Геомостпроект НПО

Сообщение den »

Ща вот днем опять data подрос на % прироста, и вчера утром такое же было.
Аватара пользователя
Evchic
партнер
Сообщения: 88
Зарегистрирован: Пн, 17/09/2007 07:57
Имя Фамилия: Евгений Ильин
Откуда: Галактика ЮГ г.Ростов-на-Дону
Контактная информация:

Сообщение Evchic »

поможет тебе только dbreindex с кластирезацией
vadim
топ-софт
Сообщения: 197
Зарегистрирован: Чт, 06/09/2007 17:38
Имя Фамилия: Вадим Володько
Откуда: ТопСофт
Контактная информация:

Сообщение vadim »

Думаю, по вопросу отжирания дискового пространства таблицами конкретной версии SQL стоит более предметно пообщаться на профильных SQL-форумах. ;-)

Могу определенно сказать, что Галактика в SQL-таблицах место про запас не резервирует :lol:
Аватара пользователя
Evchic
партнер
Сообщения: 88
Зарегистрирован: Пн, 17/09/2007 07:57
Имя Фамилия: Евгений Ильин
Откуда: Галактика ЮГ г.Ростов-на-Дону
Контактная информация:

Сообщение Evchic »

SQL я согласен не ваша головная боль. А вы попробуйте обьяснить Ген.Деректору что нужно денег на винт обьемом 5 Тб т.к. бд растет... Понятное дело что за рост БД отвечает MS SQL Server...
Будьте добры помогите найти способ бороться с детищем БИЛЛА!!!
cruger
топ-софт
Сообщения: 566
Зарегистрирован: Пт, 21/09/2007 15:19
Имя Фамилия: Фёдор Терсин
Откуда: Галактика Софт
Контактная информация:

Сообщение cruger »

Очень много неиспользуемых страниц данных. В используемых же пустого места немного.
С чем связан такой эффект - непонятно. Возможно - это следствие большого желания MS SQL раскладывать данные по страницам, лежащим недалеко друг от друга, для эффективного доступа. Так же неиспользуемые страницы могут появится после множественных операций, например, перестроения индексов.
Поджать БД, выкинув неиспользуемые страницы, можно, но опытные администраторы утверждают, что после этого производительность становится хуже, т.к. в получившихся файлах БД данные и страницы будут идти вперемешку, не так, как это было бы оптимально для скорости работы.
Тем не менее вероятно комбинация поджатия файла табличного пространства данных и перестроения индексов (в новом табличном пространстве индексов или после поджатия старого с предварительным удалением индексов) поможет достичь обе эти цели, т.к. кластерные индексы в Галактике не используются, а эффект от близкого расположения страниц данных одной таблицы может быть невелик.
Поджимать БД следует поджимая её файлы. Как именно - см. БОЛ. На sql.ru есть русский перевод, если нужно.
Также возможно следует вынести таблицы с наибольшим количеством неиспользуемых страниц в отдельное табличное пространство или пространства, что бы в дальнейшем можно было их перестраивать, не трогая другие данные.
В общем, для достижения цели требуются эксперименты.
Ответы же на заданные вопросы теоретически знают опытные администраторы MS SQL, которых у нас в штате нет, да и не нужны нам таковые - нечего у нас администрить. Ну и в Microsoft. Наверняка у вас есть возможность обратиться за помощью в администрировании в их поддержку.
cruger
топ-софт
Сообщения: 566
Зарегистрирован: Пт, 21/09/2007 15:19
Имя Фамилия: Фёдор Терсин
Откуда: Галактика Софт
Контактная информация:

Сообщение cruger »

Evchic писал(а):Будьте добры помогите найти способ бороться с детищем БИЛЛА!!!
В его поддержку пробовали обращаться?
Аватара пользователя
Evchic
партнер
Сообщения: 88
Зарегистрирован: Пн, 17/09/2007 07:57
Имя Фамилия: Евгений Ильин
Откуда: Галактика ЮГ г.Ростов-на-Дону
Контактная информация:

Сообщение Evchic »

cruger писал(а):
Evchic писал(а):Будьте добры помогите найти способ бороться с детищем БИЛЛА!!!
В его поддержку пробовали обращаться?
Да обращались и для себя мы нашли способ это последовательное создание/удаление кластерного индекса для всех таблиц и переиндексакция каждой таблы
den
заказчик
Сообщения: 117
Зарегистрирован: Пт, 26/10/2007 14:16
Имя Фамилия: Денис Кучин
Откуда: Геомостпроект НПО

Сообщение den »

Добрый день,спасибо за участие в проблеме Евгению и Федору.
Надыбал тут ссылку на статью, читаю сижу, может кому тоже инетерсно будет :

http://support.microsoft.com/Default.aspx?kbid=924947
cruger
топ-софт
Сообщения: 566
Зарегистрирован: Пт, 21/09/2007 15:19
Имя Фамилия: Фёдор Терсин
Откуда: Галактика Софт
Контактная информация:

Сообщение cruger »

И как, Денис, попадает ваша конфигурация в таблицу по ссылке?
den
заказчик
Сообщения: 117
Зарегистрирован: Пт, 26/10/2007 14:16
Имя Фамилия: Денис Кучин
Откуда: Геомостпроект НПО

Сообщение den »

В статье предлагается два метода решения проблемы :
-Convert heap tables to tables that use clustered indexes
-Set the open objects configuration option to a high value

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

вопрос : "почему операция переиндексации с созданием кластерного индекса помогла ?"

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

ответ : "Когда нет кластерного индекса, то нет возможности избавиться от пустот в страницах, которые могут появится после обновлений и удалений."

вопрос : "Следуя логике, получается без наличия такого индекса БД обречена на такие траблы работы с дисковой памятью "

ответ : "На больших таблицах с часто изменяющимися данными - да "

Таким образом, получается Галактическая скуль-база, с ее безкластерностью, получается будет давать подобный трабл при работе с ней.

Если Вы, Федор, о втором из двух вариантов, предложенных в статье
-Set the open objects configuration option to a high value

то возникает вопрос как измерить,а надо ли повышать данный параметр. В статье говориться :

1. Determine the total number of tables that are present in the specific instance of SQL Server.

Опеределить общее число таблиц на данном инстнэнсе (как я понимаю во всех БД этого инстэнса)

2. Estimate a buffer size that gives room for temporary tables and worktables that different queries and applications may use.

Оценить размер буфера, отданный под временные таблы, рабочие таблы , разные запросы

3. Add the number of user tables and system tables to the buffer to determine the total number of tables that may be accessed in this instance of SQL Server. This total number is the value that you should set for the open objects configuration option.

Добавить кол-во юз. таблиц и сис таблиц к буферу чтобы опеределить общее число таблиц,которые м.б. доступны данному инстненсу скуля. Это число и есть значение которое вы должны выставить в open objects


Вопрос - как оценить размер буфера в пункте 2 и принять решение о изменение этого параметра...не совсем я понял это из статьи
cruger
топ-софт
Сообщения: 566
Зарегистрирован: Пт, 21/09/2007 15:19
Имя Фамилия: Фёдор Терсин
Откуда: Галактика Софт
Контактная информация:

Сообщение cruger »

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

Вообще это выходит мощная проблема MS SQL, с которой они принципиально не хотят бороться. Т.к. это как раз для кластерного индекса в теории удаление данных будет приводить к фрагментации. Типа страница была заполнена, потом часть оттуда удалили, вставлять туда из других страниц бессмысленно, а появятся ли новые данные с близким значением индекса - неизвестно. Для хипа же как раз неважно, какие данные хранятся на странице: место есть, значит можно туда вдуть.

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

Не хотите ли рассмотреть вариант перевода части таблиц на кластерный индекс? В экспериментальном порядке, что бы оценить изменение роста пространства, отхваченного под эти таблицы. Если эксперимент пройдёт успешно - будем дорабатывать систему, что бы можно было штатными средствами выбрать такой вариант хранения.
den
заказчик
Сообщения: 117
Зарегистрирован: Пт, 26/10/2007 14:16
Имя Фамилия: Денис Кучин
Откуда: Геомостпроект НПО

Сообщение den »

Скажу честно - я не знаю как оценить/где позырить кол-во открытых объектов на текущий момент в скуле (как Вы сказали, "общего числа используемых таблиц БД"). Если знаете - подскажите как :-)
Ответить