Начнём с Access, а закончим MS SQL Express.
Одной из первых серьёзных проблем, с которой пришлось столкнуться - отсутствие 2/3 записей базы. Произошло это сразу после перегона базы из формата АС-2 в АС-3. Поиск по номеру записи показывал присутствие всех, но поиск по автору и другим полям был катастрофическим.
В общем, странность прояснилась сразу после сжатия базы. Оказалось, что процесс индексации (в терминах АС-3) страшным образом потребляет ресурсы базы, она распухает на глазах, и по достижении порога в 2Гб тихо останавливается без всякой ругани. Если ты не знал об этом - возьми на заметку. Знаю, что многие напоролись на этот феномен, и если бы эта инфа была в паблике на тот момент - мне удалось бы сэкономить несколько недель на более полезные дела. Поэтому в скобках приведу несколько фраз исключительно для поисковика (нет половины базы, АС-Библиотека-3 не находит записи, пропали записи в АС-Библиотека-3).
Итак, чем жмём? Естественно Access-ом, скажешь ты. А если для базы выделен отдельный компьютер. Держать на нём офис исключительно для сжатия? А если это выделенный сервер, то даже устанавливать на него офис - есть нонсенс. Существует крайне простая, маленькая и бесплатная утилита под названием JetComp (условия использования на странице продукта и в архиве). Просто вбей название в поисковой строке на сайте Microsoft. Использовать её крайне просто.
В верхней строке указываем базу, а в нижней - имя файла, в котором окажется сжатая база. Я просто копировал путь и добавлял единичку к имени файла. Остальные параметры как есть. После исходный файл удалял, а новый переименовывал. По сравнению со сжатием в Access, здесь есть дополнительный манёвр, на случай нехватки места на разделе диска, можно сжать в файл на другом разделе. Я успешно эксплуатировал эту утилиту в течение двух лет, до перехода на MS SQL.
Если этого мало вот ещё один вариант. Оснастка "Источники данных ODBC" (Панель управления ->Система и безопасность->Администрирование).
Но такая возможность есть не во всех версиях ОС. Например, в моей текущей семёрке нет. Точнее драйвер Jet есть, а доступа через ODBC нет. С другой стороны в предварительном релизе Srv2012 есть
Не будем долго с этим париться. Если есть - грех не воспользоваться. Итак, на вкладке "Пользовательский DSN" жмём кнопку "Добавить...". В появившемся окне выбираем "Microsoft Access Driver (*.mdb)" и жмём "Готово".
В следующем окне появляется заветная кнопка "Сжать...".
Нажимаем и, в диалоге, указываем базу для сжатия.
Нажимаем ОК. В следующем окне указываем имя файла, в который будет сжиматься база. Все, как и в JetComp, но не забудь установить "Формат" в "Версия 4.x".
Жмём ОК и ждём результат.
Далее отменяем всё до кнопки "Сжать..." и жмём следующую базу. После этого закрываем все окна, удаляем старые базы и переименовываем новые. Как видишь, мы ничего не создаём, хотя, исключительно для удобства, можно создать "Пользовательский DSN" и использовать его в качестве ссылки.
Возникает вопрос. Какой метод лучше? С точки зрения собственно сжатия не имеет значения. Раскрою маленький секрет. Функция сжатия реализована в самом движке Jet. И Access и JetComp и ODBC драйвер всего лишь запускают одну и ту же функцию интерфейса IJetCompact, реализованную в движке. Поэтому при выборе средства для сжатия можно ограничиться соображениями удобства.
Теперь SQL. Я коснусь бесплатной версии Express. Его возможностей стало хватать ещё больше после того как в версии 2008 R2 была поднята планка размера б.д. до 10Гб. Платные версии редкий зверь для библиотеки, хотя если задействовать его мощь по полной ...
Собственно функцию сжатия можно запустить в оболочке "SQL Server Management Studio" - это не секрет. Тонкость заключается в предварительной дефрагментации индексов. Следующий скрипт ищет в базе все индексы, с фрагментацией более 10% и обрабатывает. Это не самопал. Скрипт взят из документации Microsoft к SQL Server. При желании найдёшь его там (плюс дополнительная инфа!). Если желания нет - просто скопируй его в студию, установи контекст базы для обработки (см. первый комментарий) и запусти.
-- Ensure a USE <databasename> statement has been executed first.
SET NOCOUNT ON;
DECLARE @objectid int;
DECLARE @indexid int;
DECLARE @partitioncount bigint;
DECLARE @schemaname nvarchar(130);
DECLARE @objectname nvarchar(130);
DECLARE @indexname nvarchar(130);
DECLARE @partitionnum bigint;
DECLARE @partitions bigint;
DECLARE @frag float;
DECLARE @command nvarchar(4000);
-- Conditionally select tables and indexes from the sys.dm_db_index_physical_stats function
-- and convert object and index IDs to names.
SELECT
object_id AS objectid,
index_id AS indexid,
partition_number AS partitionnum,
avg_fragmentation_in_percent AS frag
INTO #work_to_do
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED')
WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;
-- Declare the cursor for the list of partitions to be processed.
DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do;
-- Open the cursor.
OPEN partitions;
-- Loop through the partitions.
WHILE (1=1)
BEGIN;
FETCH NEXT
FROM partitions
INTO @objectid, @indexid, @partitionnum, @frag;
IF @@FETCH_STATUS < 0 BREAK;
SELECT @objectname = QUOTENAME(o.name), @schemaname = QUOTENAME(s.name)
FROM sys.objects AS o
JOIN sys.schemas as s ON s.schema_id = o.schema_id
WHERE o.object_id = @objectid;
SELECT @indexname = QUOTENAME(name)
FROM sys.indexes
WHERE object_id = @objectid AND index_id = @indexid;
SELECT @partitioncount = count (*)
FROM sys.partitions
WHERE object_id = @objectid AND index_id = @indexid;
-- 30 is an arbitrary decision point at which to switch between reorganizing and rebuilding.
IF @frag < 30.0
SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE';
IF @frag >= 30.0
SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD';
IF @partitioncount > 1
SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10));
EXEC (@command);
PRINT N'Executed: ' + @command;
END;
-- Close and deallocate the cursor.
CLOSE partitions;
DEALLOCATE partitions;
-- Drop the temporary table.
DROP TABLE #work_to_do;
GO
После чего запусти сжатие.
Интересно, что дефрагментация и сжатие "противоречивые" процедуры - сразу после сжатия база окажется фрагментированной, а после дефрагментации появится свободное пространство для сжатия. В документации рекомендуется последней операцией оставлять дефрагментацию.
Темпы роста базы очевидно, связаны с беспощадной эксплуатацией со стороны АС-3. С другой стороны, как ты, наверное, уже заметил, в базе проиндексировано абсолютно всё. По принципу, чем больше - тем лучше. В результате место, занимаемое индексами в базе значительно превышает размер самих данных. Так что, тут как видишь, непочатый край работы для админа. Но тюнинг индексов уже выходит за рамки текущей темы.
