Добрый день,

Имеется MSSQL Server 7.0. Исходный размер базы 3,5G. В таблице ( 8 миллионов записей) изменяю тип нескольких полей с bit на tinyint (использую EM 2000). По завешению операции размер фала данных 17G (используемый).

Вопросы:
1. Что произошло?
2. Как привести базу в порядок?

Дело в том, что Shrink не помогает. Я уже запускал Reindex и Shrink Database.
Есть подозрение, что проблему создают индексы созданные сервером автоматически для некоторых полей. Но как это связано с изменением типа поля ( индексов по этим полям нет и не было)?

Я достаточно хорошо знаю где и что находится. Нужна идея.
Возможно стоит убить и создать вновь все индексы? Но что делать с "nonclustered, statistics, auto create located on PRIMARY"? ( 2Glory: эти индексы созданы сервером на полях decimal(14, 0))

Так как конструктивных идей не было, я удалил все идексы и статистику, сделал Shrink Files и Shrink Database. В результате размер используемого просьрансьва сократился до 12G. Это меня не устроило. Я создал новую базу ( со всеми таблицами, вьюшками и индексами). После чего перегнал в нее все данные из старой базы ( INSERT INTO Table SELECT * OldDB..Table). Через сорок минут все таблицы были скопированы, размер новой базы 2G. Если кто-то может, пожалуйста объясните это явление!!!

2 Glory:
>Поэтому при интенсивной работе с данным появляется элементарная дефрагментация. Информацию о дефрагментации можно >получить с помощью DBCC SHOWCONTIG, а борются с ней с помощью DBCC INDEXDEFRAG.
>Кроме этого можно получить данные о занимаемом объектом объема с помощью sp_spaceused(обратите внимание и на второй >параметр - возможно у вас ошибки в базе). Кстати можете сравнить объекты в "старой" и "новой" базах на предмет кто и >сколько занимает места.
Спасибо.
Как раз этого мне и вчера и нехватало. После того, как создал новую базу я покопался в BOL и нашел эти разделы, но к сожалению потом.

Но остается неясным один вопос. Вот скрипт от EM по изменению типа поля:

BEGIN TRANSACTION
CREATE TABLE dbo.Tmp_BaseVisitCommonSubject
(
...
Availability int NULL,
...
) ON [PRIMARY]
GO
IF EXISTS(SELECT * FROM dbo.BaseVisitCommonSubject)
EXEC('INSERT INTO dbo.Tmp_BaseVisitCommonSubject (..., Availability, ...)
SELECT ..., CONVERT(int, Availability), ... FROM dbo.BaseVisitCommonSubject TABLOCKX')
GO
DROP TABLE dbo.BaseVisitCommonSubject
GO
EXECUTE sp_rename N'dbo.Tmp_BaseVisitCommonSubject', N'BaseVisitCommonSubject', 'OBJECT'
GO
ALTER TABLE dbo.BaseVisitCommonSubject ADD CONSTRAINT
pkBaseVisitCommonSubject PRIMARY KEY CLUSTERED
(
VisitId,
SubjectId
) WITH FILLFACTOR = 10 ON [PRIMARY]

GO
CREATE NONCLUSTERED INDEX ix_BaseVisitCommonSubjectMosaicId ON dbo.BaseVisitCommonSubject
(
MosaicId
) WITH FILLFACTOR = 10 ON [PRIMARY]
GO
COMMIT

(Я немного сократил, но суть, думаю, осталась)
Если разобраться, ни о каком интенсивном использовании речь не идет. Удаляеться один объект и создается новый. Я понимаю, что в этом случае возможна дефрагментация файла данных, но это легко побеждаеться Shrink Database/File.
По поводу DBCC UPDATEUSAGE:
Речь идет (как я понял) о таблице sysindexes. Но после тотго, как я удалил все индексы, ситуация принципиально не изменилась.
Мне кажется здесь более глубокая проблема.
К сожалению я удалил старую базу (места всегда нехватает) и нельзя будет проверить другие идеи. Но с радостью их прочту.
И последнее:
При запуске dbcc dbreindex статистика созданная сервером автоматически обрабатывается также как и идекс (достаточно посмотреть выдаваемые сообщения).

2Garya:
Цитирую BOL:
Microsoft® SQL Server™ optimizes the storage used for bit columns. If there are 8 or fewer bit columns in a table, the columns are stored as 1 byte. If there are from 9 through 16 bit columns, they are stored as 2 bytes, and so on.

Т. е. Если в таблице одно из полей типа bit, то после изменения типа этого поля на tinyint, размер таблицы не изменяется. Если таких полей два то размер таблицы должен увеличиться на (Rows * 2) байт но не в двое, так как есть другие поля.

P.S.
Из-за праздников не мог ответить раньше.

Спасибо за участие!
Собака закопалась именно там.