Shrink database не дает видимого эффекта
Есть база 7.7 на sql размер примерно 20Gb без учета журнала, в ней изначально были данные начиная с 2006 по настоящее время, после удаления данных за весь 2006 год (программно документ.удалить(1)) пробую сжать базу средствами sql, визуально эффекта нет (уменьшился только файл журнала). Как можно для базы на sql удалить удаленные объекты.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(6)
Тут как раз ничего странного. В dbf удаленные записи на самом деле не удаляются, а помечаются, как удаленные (это не пометка удаления 1С, а именно самой dbf). Потом эти записи по мере необходимости используются под новые. В скуле технология таблиц совершенно другая.
странно что убрали из sql версии возможность сжать базу
Тут как раз ничего странного. В dbf удаленные записи на самом деле не удаляются, а помечаются, как удаленные (это не пометка удаления 1С, а именно самой dbf). Потом эти записи по мере необходимости используются под новые. В скуле технология таблиц совершенно другая.
УМЕНЬШЕНИЕ РАЗМЕРОВ БАЗЫ SQL ИЛИ ПРОБЛЕМЫ КОМАНДЫ SHRINK
Многие администраторы баз данных сталкивались с проблемой роста объемов информации в базах MS SQL Server 2005. Главным источником проблем обычно является так называемый log-файл (файл с расширением *.ldf или журнал транзакций). Данная ситуация разрешается простым шринком (уменьшением объемов log-файла) — об этом знают практически все, кто так или иначе работал с MS SQL, приведенные ниже варианты кода довольно просты:
DBCC shrinkdatabase(N’имя_базы’, TRUNCATE_ONLY); — усечение всей базы
use [имя_базы] DBCC SHRINKFILE (N’имя_базы_Data’, 101); — усечение только файла данных до размера 101 мб
use [имя_базы] DBCC SHRINKFILE (N’имя_базы_Log’, 0); — усечение только файла транзакций до размера 0 мб
Но бывает так, что по каким-то причинам уменьшить объемы не получается, и в момент исполнения кода появляются сообщения об ошибках. Такая проблема проявляется в основном на тех базах данных, для которых установлена модель архивирования Full (для модели Simple проблем, как правило, не возникает, далее поясним почему). В сообщениях об ошибке говорится о том, что log-файл находится в использовании, поэтому операцию выполнить невозможно — это более чем удивительно, поскольку обычно процесс шринка производится при завершенной работе пользователей (никто не обращается к базе). Монитор соединений так же показывает отсутствие какой-либо активности.
В документации по этому поводу информация есть, но ее чтение после второго абзаца наводит тоску зеленого оттенка. Анализ сообщений на различных форумах и практическим путем было установлено следующее. Прежде, чем выполнять шринк базы необходимо выполнить архивацию, но не всей базы, а именно файла транзакций. Только после завершения этой процедуры можно смело выполнять команду shrink, и результат будет достигнут. Надо сказать, что процедура архивации нужна только, если для базы данных установлена модель архивирования Full. В модели Simple log-файл автоматически помечается, как свободный для использования и команда shrink работает без проблем, в модели Full файл становится свободным для использования только после backup-а соответствующего файла.
Многие администраторы баз данных сталкивались с проблемой роста объемов информации в базах MS SQL Server 2005. Главным источником проблем обычно является так называемый log-файл (файл с расширением *.ldf или журнал транзакций). Данная ситуация разрешается простым шринком (уменьшением объемов log-файла) — об этом знают практически все, кто так или иначе работал с MS SQL, приведенные ниже варианты кода довольно просты:
DBCC shrinkdatabase(N’имя_базы’, TRUNCATE_ONLY); — усечение всей базы
use [имя_базы] DBCC SHRINKFILE (N’имя_базы_Data’, 101); — усечение только файла данных до размера 101 мб
use [имя_базы] DBCC SHRINKFILE (N’имя_базы_Log’, 0); — усечение только файла транзакций до размера 0 мб
Но бывает так, что по каким-то причинам уменьшить объемы не получается, и в момент исполнения кода появляются сообщения об ошибках. Такая проблема проявляется в основном на тех базах данных, для которых установлена модель архивирования Full (для модели Simple проблем, как правило, не возникает, далее поясним почему). В сообщениях об ошибке говорится о том, что log-файл находится в использовании, поэтому операцию выполнить невозможно — это более чем удивительно, поскольку обычно процесс шринка производится при завершенной работе пользователей (никто не обращается к базе). Монитор соединений так же показывает отсутствие какой-либо активности.
В документации по этому поводу информация есть, но ее чтение после второго абзаца наводит тоску зеленого оттенка. Анализ сообщений на различных форумах и практическим путем было установлено следующее. Прежде, чем выполнять шринк базы необходимо выполнить архивацию, но не всей базы, а именно файла транзакций. Только после завершения этой процедуры можно смело выполнять команду shrink, и результат будет достигнут. Надо сказать, что процедура архивации нужна только, если для базы данных установлена модель архивирования Full. В модели Simple log-файл автоматически помечается, как свободный для использования и команда shrink работает без проблем, в модели Full файл становится свободным для использования только после backup-а соответствующего файла.
Есть база на основе УТ 10.3 на SQL Server 2005. Был у нее размер примерно 50 Гб. Размер интенсивности использования совсем не соответствует.
Я посмотрел, что там столько занимает, нашел пару таблиц, которые совсем не нужны, каждая примерно по 6 Гб. Почистил их. Размер базы стал 60 Гб.
Сделал ночью ТИИ со всеми галками. Размер базы стал 75 Гб. Примерно 67 - файл базы и 8 - журнал.
Что делать? Shrink базу не поломает? а поможет?
Я посмотрел, что там столько занимает, нашел пару таблиц, которые совсем не нужны, каждая примерно по 6 Гб. Почистил их. Размер базы стал 60 Гб.
Сделал ночью ТИИ со всеми галками. Размер базы стал 75 Гб. Примерно 67 - файл базы и 8 - журнал.
Что делать? Shrink базу не поломает? а поможет?
Тю блин. Зачем чужие некроветки поднимать? Это сбивает с толку. Свои создавай.
(11) А отчет по ТИИ был "чистым"? Или ты его не читал? :) Может, он там битых ссылок тонну восстановил.
А так, как я уже сказал - смотришь сколько студия показывает свободного места. Если половина от полезного или выше, тогда имеет смысл шринкнуть.
Заручаешься актуальным бэкапом, обеспечиваешь время простоя на всяк пожарный, ставишь галки сжатия с реорганизацией и шринкаешь до 10 процентов.
(11) А отчет по ТИИ был "чистым"? Или ты его не читал? :) Может, он там битых ссылок тонну восстановил.
А так, как я уже сказал - смотришь сколько студия показывает свободного места. Если половина от полезного или выше, тогда имеет смысл шринкнуть.
Заручаешься актуальным бэкапом, обеспечиваешь время простоя на всяк пожарный, ставишь галки сжатия с реорганизацией и шринкаешь до 10 процентов.
По дефолту шринкается только свободное место в конце базы, т.к. только эту операцию можно выполнить гарантированно быстро.
Более эффективный шринк по сути требует частичной дефрагментации и может выполняться долго.
Если базу через мастер шринкать, то там отдельные галки за это отвечают - типа "реорганизовать файлы перед освобождение места" или как-то так. И указать сколько чтобы осталось в процентах. Оставь процентов десять.
Более эффективный шринк по сути требует частичной дефрагментации и может выполняться долго.
Если базу через мастер шринкать, то там отдельные галки за это отвечают - типа "реорганизовать файлы перед освобождение места" или как-то так. И указать сколько чтобы осталось в процентах. Оставь процентов десять.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот