Галактика в вопросах и ответах

Подскажите пожалуйста

Гал 7,12+ MS SQL 2000 SP 4

Очень сильно растет размер базы за 3 месяца выросла с 25Гб до 140Гб
на первасиве рост был примерно 1Гб в месяц

Можно ли как-нибудь сжать ее?

для начала посмотрите какие файлы растут.
если это журнал транзакций, то на него нужно поставить ограничение по размеру. Если это другие файлы то нужно делать shrink(в enterprise manager правой кнопкой на базе - все задачи). Журнал лучше сжимать не галактическими средствами, а скриптом в mssql(как поищите на форуме). На все это можно настроить sheduler mssql.

Hi!

Ну просто делать усечения я бы не рекомендовал. Если не сохранять журналы транзакций в копиях то возможен вариант когда после разрушения БД её нельзя будет восстановить полностью.
Сам использую модель восстановления full и каждую ночь запускаю план обслуживания, который перестраивает индексы и усекает неиспользуемое пространство и др. На протяжении суток каждые пол-часа создаю копию журнала транзакций - это предотвращает рост БД в целом. При очень интенсивном росте БД делаю создание копий журнала транзакций чаще.
В результате этого набора работ БД иногда растёт иногда уменьшается. В общем её размер колеблется + -. Кроме того я имею возможность полностью восстановить БД даже если средства Галактики не помогают.

Да и ещё... если включена журнализация таблицы T$saldomc - отключите, поскольку журнал на эту таблицу не даёт никакой пользы (сальдовые остатки при восстановлении с неё всё равно придётся пересчитывать) и очень быстро растёт.

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

Если можно, то подробнее, что такое full и план обслуживания? и где они настраиваются?

Растут Data и INDEX

Читайте доки по MS-SQL - серверу. Есть некоторые тонкости в настройке баз данных. Просто так оставлять на самотек - чревато последствиями. Вы должны управлять вашими ресурсами, а не наоборот.

Simple, Bulk-Logged, Full - модели восстановления БД. Все зависит от требований, которые предъявляются к параметрам упоминаемой базы.

При модели Simple логи практически не растут, но при сбое сервера можно потерять всю работу от последней архивации.

При модели Full можно восстановить данные вплоть до последней минуты, когда рухнул сервер (если захочется так настроить). Однако при этом логи будут расти очень сильно и понадобится много пространства на разделе, где вы логи разместили при установке базы.

Bulk-Logged - нечто среднее.

Это так, вкратце. А вообще - читайте доки.

P.S. У меня как-то стал сильно расти журнал. Много модификаций в базе... Пришлось подрезать.
P.P.S. Кстати, урезать журнал стандартными средствами - полная блокировка работы в MS-SQL. Пришлось извращаться.

maikl писал(а): Если можно, то подробнее, что такое full и план обслуживания? и где они настраиваются?

Ну про full уже выше ответили, а план обслуживания ищите в Enteprise Manager.

1) Настройте бэкап БД и логов. Частота выполнения зависит от размера БД и времени, отводимого на простой в случае разрушения БД. Достаточно будет делать ночью бэкап базы, а в течении дня каждый час бэкап лога.
2) Ни в коем случае нельзя урезать БД и уж тем более доводить ее до состояния, когда ее размер то увеличивается, то уменьшается
Наиболее оптимальным является вариант, когда размер БД заранее устанавливается таким, чтобы перекрывать рост БД на несколько лет вперед (тут конечно зависит от размера самой БД ). Во-первых, это устраняет приращение БД в процессе работы (к сведению, это очень ресурсоемкая операция). Во-вторых, предотвращает фрагментацию файла БД на диске с течением времени.

WiRuc писал(а): 2) Ни в коем случае нельзя урезать БД и уж тем более доводить ее до состояния, когда ее размер то увеличивается, то уменьшается

Позволю себе не согласиться с Вами. Вкладка optimizations в Database maintenance plan содержит операции, которые влияют на размер БД в обе стороны, т.е. на увеличение и на уменьшение.
У меня full модель восстановления, я делаю ночью полный бэкап БД и в течение дня каждые пол-часа создаю резервные копии журнала транзакций и перед полным бэкапом каждый раз всё что содержит указанная выше (optimizations) вкладка. В результате размер БД колеблется и я не теряю возможности восстановления БД на любой момент времени. Это проверено неоднократно. Момент между созданием последней копии журнала транзакций, выполнением операций согласно вкладки optimizations и созданием полной копии БД я также проверял - восстанавливал БД на любое время из диапазона выполнения этих операций.

Возможность восстановления БД и не должна теряться в любом случае. Только не надо усекать БД, делайте только реорганизацию индексов. Раз БД увеличилась в размере, значит это было необходимо и, если вы сейчас урежете БД, то в последующем опять понадобиться прирост и MSSQL опять будет заниматься увеличением файлов. Вот весело, сначала вы режете - потом СУБД увеличивает
И еще раз, увеличение размера БД ресурсоемкая операция, этого необходимо всячески избегать.
Единственное, как можно (и нужно) пользоваться командой по усечению БД:
DBCC SHRINKDATABASE (@dbname, 0, NOTRUNCATE)
В этом случае БД не усекается в размере, а оптимизируется расположение занятых страниц в файлах БД - все занятые страницы переносятся в начало файла, освобождая место в конце (что-то типа дефрагментации). Только план обслуживания такого делать не позволяет.

WiRuc писал(а):Возможность восстановления БД и не должна теряться в любом случае. Только не надо усекать БД, делайте только реорганизацию индексов. Раз БД увеличилась в размере, значит это было необходимо и, если вы сейчас урежете БД, то в последующем опять понадобиться прирост и MSSQL опять будет заниматься увеличением файлов. Вот весело, сначала вы режете - потом СУБД увеличивает

Бывают случаи когда интенсивно используются, например, откаты по журналу в Галактике или пользователи создают свои промежуточные таблицы большого объёма. Эти действия приводят к значительному увеличению БД. Затем несколько дней спустя (зависит от размера журнала) происходит удаление всех старых записей или пользователи удаляют эти промежуточные таблицы. В БД остаётся очень много неиспользуемого места. SQL сам не уменьшает размеры баз. А это место может понадобиться для других баз и не только. Поэтому в плане обслуживания и применяю Remove unused space...
Вследствие этого и уменьшаяется база. После этого она в большинстве случаев не меняется в размере в течении нескольких дней а если и меняется то по крайней мере более 200 одновременно работающих пользователей этого не замечают . Да и БД вроде не маленькая... 148Gb на текущий момент...хотя может у Вас значительно больше?

В БД остаётся очень много неиспользуемого места. SQL сам не уменьшает размеры баз. А это место может понадобиться для других баз и не только.

Интересно, а когда у вас база опять будет расширяться, вы что ей сначала место будете освобождать. Ну, собственно, хозяин-барин, не хотите внять голосу разума - ваше дело.
P.S. А база у нас 100Гб, если вам интересно. И это только Галактика, есть еще и помимо.

Всем спасибо но я так и не понял что делать
за неделю база выросла на 7Г хотя было введено только 2 накладных
в основном растет файл DATA
Что делать как остановить безразмерный рост базы?

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

и каков его размер при размере базы как я понял уже 147GB?

может фактор (Fill Factor) заполнения страниц слишком низкий?