Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Размер таблицы в памяти [MSSQL]

Ega23 © (2006-03-13 18:36:00)
Есть процедура s_spaceused , фактически "наследник" системной sp_spaceused.
Выдаёт информацию о физическом размере таблицы, количестве записей и т.п.
Есть 2 сервера, есть база с шестью таблицами. Написал некий репликатор этих шести таблиц с рабочего сервера на резервный.
Взялся проверять, насколько корректно добавились записи (там достаточно сложная иерархическая структура).
Прогнал эту ХП для шести таблиц на обоих серверах. По количеству записей - всё ОК. А вот по занимаемому таблицей размеру - на основном (рабочем) сервере чуть ли не в 2 раза размер таблиц больше.
Собственно вопрос: это может быть как-то связано с тем, что на основном сервере данные таблицы активно используются? Ну там, свап какой-нибудь, или что-то в этом роде?
А то что-то не хочется 10000 записей вдумчиво проверять...

Ega23 (2006-03-14 08:59:00) [1]
В общем, насчёт размера блоков данных - я примерно так и думал.
Просто убедиться хотел.
Всем большое спасибо!!!

Nikolay M. (2006-03-13 21:26:00) [2]

> Собственно вопрос: это может быть как-то связано с тем,
> что на основном сервере данные таблицы активно используются?
> Ну там, свап какой-нибудь, или что-то в этом роде?

Обычная фрагментация страниц данных. Особенно заметна на активно обновляемых таблицах. Почти полная аналогия с фрагментацией жесткого диска.

sniknik (2006-03-13 20:32:00) [3]
смотря как как еще был обмен сделан/структура скопирована
мог "потерять" индексы, а они место тоже занимают. мог неправильно задать тип например Char вместо VarChar (разный размер при одинаковом наполнении), или nChar nVarChar вместо предыдущих (двойной размер при тех же данных - юникод). ну или наоборот. VarChar вместо Char... и т.д.

перед сравнением делай Shrink Database в EM обоих баз (и галочки там выставь "перемещать данные перед упаковкой" вроде, и % резерва 0... там увидиш поймеш). тогда приблизительно должно сходится.

Sergey Masloff (2006-03-13 18:59:00) [4]
Ega23 © (13.03.06 18:36)
>Собственно вопрос: это может быть как-то связано с тем,
Я абсолютно не знаток MS SQL но примерно одинаково же данные организуются. Есть % заполнения блоков при достижении заполнения которого начинается следующий блок. Этот % настраивается (в Oracle, DB2 -точно, уверен что и в MS есть нечто подобное). При разном % размер одинаковых таблиц будет разным.
Более того при интенсивной работе с таблицей блоки могут оказаться заполнеными не до допустимой границы а меньше - ну была запись. Ее проапдейтили так что она стала длиннее и в данный блок не влезает. Естественно она была перемещена в другой блок место от нее пока осталось а по какой-то причине пока не заполнилось. Размер опять будет отличаться - в результате репликации записи по блокам разложены более аккруратно. Ну вобшем ничего страшного ИМХО

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »