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

← →
Ega23 © (2006-03-13 18:36) [0]

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

← →
Sergey Masloff (2006-03-13 18:59) [1]

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

← →
sniknik © (2006-03-13 20:32) [2]

смотря как как еще был обмен сделан/структура скопирована
мог "потерять" индексы, а они место тоже занимают. мог неправильно задать тип например Char вместо VarChar (разный размер при одинаковом наполнении), или nChar nVarChar вместо предыдущих (двойной размер при тех же данных - юникод). ну или наоборот. VarChar вместо Char... и т.д.

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

← →
Nikolay M. © (2006-03-13 21:26) [3]

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

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

В общем, насчёт размера блоков данных - я примерно так и думал.
Просто убедиться хотел.
Всем большое спасибо!!!

Размер таблицы в памяти Найти похожие ветки