Как сделать шринк базы 1с

Добавил пользователь Валентин П.
Обновлено: 09.09.2024

Базовые операции по обслуживанию баз данных в SQL Server 2008 R2 можно производить как из консоли при помощи служебной программы sqlcmd и языка запросов T-SQL, так и с помощью графической утилиты SQL Server Managment Studio. Отличительной особенностью средства SQL Server Managment Studio является, то что в нем можно использовать оба способа, причем во время выполнения основных операций, программа позволяет переключатся в режим просмотра кода T-SQL. Достаточно нажать кнопку Script в верхней части окна программы. Для вызова средства sqlcmd, достаточно набрать в командной строке sqlcmd. Для подключения к удаленному серверу или именованному экземпляру необходимо добавить ключ -s:

Полный перечень команд доступных в интерактивном режиме, можно получить если набрать:

К основным операциям по обслуживанию баз данных можно отнести резервное копирование (Back up Database), восстановление (Restore Database), сжатие (Shirink Database), дефрагментацию. Рассмотрим каждую из них на примере.

1. Резервное копирование (Back up Database)

SQL-сервером поддерживается широкий перечень методов резервного копирования. Наиболее распространенными являются:

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

Разностные резервные копии (Differential) - следует выполнять для минимизации времени, которое необходимо для восстановления часто изменяемой базы данных. Возможно только в том случае, когда создана полная резервная копия базы данных.

Резервные копии журнала транзакций (Transaction Log) - в них записываются все изменения базы данных. Выполняется только при наличии полной резервной копии базы, и полной модели восстановления. Имеет смысл выполнять при наличии часто изменяемых баз данных.

Для выполнения резервного копирования, в SQL Server Management Studio необходимо перейти на закладку Database, щелкнуться правой кнопкой на нужной базе и в контекстном меню Task выбрать Back Up. В появившемся окне выбрать метод резервного копирования (Backup type), в поле "Back up To" задать путь для хранения резервной копии или оставить по умолчанию. Нажать ок.

Та же операция на языке запросов T-SQL будет выглядеть следующим образом:

2. Восстановление. (Restore Database)

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

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

При помощи параметра RESTRICTED_USER. (Ограничить доступ пользователям) в дополнительных свойствах (Options) базы данных. Если пользователи могут подключатся к базе с правами dbo, то необходимо выставить параметр в SINGLE_USER. В T-SQL за аналогичное действие отвечает параметр WITH RESTRICTED_USER.

Если на сервере имеется только одна рабочая база данных, то лучше просто на время восстановления отключить сетевой доступ к SQL Server. Для этого можно, на время восстановления отключить протокол TCP/IP в контейнере SQL Server 2008 Network Configuration в SQL Server Configuration Manager

Может случиться так, что база данных повреждена настолько сильно, что изменить ее свойства не удается. Она при этом может находиться в состоянии suspect (подозрительное) или в автономном режиме offline (информацию о состоянии можно просмотреть, например, из контейнера Datаbases в Management Studio). Если база данных находится в автономном режиме, то запустить ее восстановление не удастся. В этой ситуации самый простой выход — отсоединить (detach) поврежденную базу данных и произвести восстановление с резервной копии так, как будто эта база данных отсутствует на сервере вообще. Отметим, что для того, чтобы отсоединить базу данных, помеченную как suspect (подозрительная), ее необходимо вначале перевести в состояние emergency (экстренной необходимости):

Существует три модели восстановления баз данных. Полная (Full), простая (Simple), c неполным протоколированием Bulk-Logged).

В полной модели восстановления, используются копии баз данных (*.bak) и все сведения журналов. (*.ldf) Сервером SQL Server заносятся в журнал все изменения базы данных, включая массовые операции и операции создания индексов. Если сами журналы не повреждены, сервером могут быть восстановлены все данные за исключением транзакций, которые обрабатывались на момент сбоя. Поскольку все транзакции записаны в журнал, восстановление может быть выполнено до любого момента времени. Главное ограничение этой модели - большой размер файлов журналов и итоговые затраты памяти и процессорного времени. Полное восстановление имеет смысл, только если:

База данных имеет небольшой размер. Резервное копирование выполняется в течении приемлемого времени.
База данных подвергается незначительным изменениям или доступна только для чтения.

Простая модель восстановления (simple) используется для малых баз данных или баз данных, в которых данные изменяются редко. Копии журналов не предусмотрены. В этой модели восстановления используются полные или разностные копии баз данных, и восстановление ограничивается восстановлением базы данных до момента, когда была создана последняя резервная копия. Все изменения, сделанные после создания резервной копии, утрачиваются. Основное преимущество этой модели, что для хранения журналов (*.ldf) требуется меньше места.

В модели восстановления с неполным протоколированием (Bulk-Logged) для восстановления базы данных используются резервные копии как базы данных так и журнала. Это дополнение к полной модели восстановления, позволяющее выполнять высокопроизводительные операции массового копирования. Основное преимущество - уменьшает место занимаемое журналами, за счет протоколирования большинства массовых операций. Возможно восстановление до конца любой резервной копии. Восстановление до заданной точки не поддерживается.

Представим, что произошел сбой и база данных newdb повредилась и соответственно возникла необходимость в ее восстановлении. Для этого в SQL Server Managment Studio в контейнере Databases выбираем базу newdb, затем Tasks - Restore - Database.

Здесь параметр 'To database' задает в какую базу восстанавливать бэкап. В место выбора базы данных доступен так же вариант ввода своего имени. В этом случае из резервной копии на сервере будет создана новая база данных. В некоторых случаях может быть удобно восстановить копию существующей базы данных под другим именем, а затем при необходимости старую базу данных удалить, а восстановленную переименовать, присвоив ей старое название.

Параметр 'To a point in time' (К моменту времени) задает момент времени на который требуется восстановить базу, по умолчанию: самый последний. Обычно используется только в ситуации, когда пользователь совершил ошибку (например, удалил важные данные) и вы знаете примерно, когда это произошло. Используется только при восстановлении журналов транзакций.

From Database - задает из резервной копии какой базы производить восстановление, по умолчанию предлагает то, что находится в .\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup. В списке можно выбрать не только текущую базу данных, но и другие базы данных, которые есть на этом сервере;

From Device - предлагает выбрать резервную копию расположенную на другом диске или устройстве. Эта возможность используется в тех ситуациях, когда нужно восстановить базу данных на другой сервер или местонахождение резервной копии изменилось.

Соглашаемся с параметрами выбранными по умолчанию, нажимаем ОК, и получаем ошибку:

Restore Failed fo Server 'server'. (Microsoft.SqlServer.SmoExtended) System.Data.SqlClient.SqlError: The tail of the log for the database "newdb" has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log.

'Заключительный фрагмент журнала базы данных "newdb" не был добавлен в резервную копию. Если журнал содержит данные, которые нужно сохранить, используйте для его резервного копирования BACKUP LOG WITH NORECOVERY. Используйте предложение WITH REPLACE или WITH STOPAT инструкции RESTORE для замены содержимого журнала.'

Похоже срабатывает, проверка безопасности, запрещающая производить восстановление базы данных, если на ней осталась часть журнала транзакций (tail-log), резервное копирование которой еще не производилось. Данная проверка срабатывает, только в случае полной модели восстановления и модели восстановления с неполным протоколированием. Поэтому, что бы восстановить такую базу данных необходимо перейти в раздел опций и добавить параметр Overwrite the existing database (WITH REPLACE), который отключает проверку безопасности. Либо во время резервного копирования базы, делать так же резервную копию журнала транзакций и производить восстановление в месте с журналом.

Еще, при восстановлении существуют проверка не допускающая случайной перезаписи базы данных другой базой данных, т.е. если данная база, которую нужно восстановить уже существует на сервере, а имя базы данных или набор файлов для заданной базы данных отличается от имени или набора файлов записанного в резервном наборе данных, то ее восстановление так же не будет выполнено. Так же запрещено перезаписывать файлы, которые относятся к базам данных, находящимся в автономном режиме (offline), и, кроме этого, вообще любые файлы, которые не относятся к SQL Server;

Следующий параметр Preserve the replication settings (WITH KEEP_REPLICATION) (Сохранить настройки репликации при восстановлении) - используется только тогда, когда база данных одновременно участвует и в репликации, и в автоматической доставке журналов (log shipping).

Prompt before restoring each backup (Выводить приглашение перед каждым восстановлением) — выводить приглашение перед восстановлением каждой следующей резервной копии из выбранного вами списка. Если используется стример.

Restrict access to the restored database (Ограничить доступ к восстанавливаемой базе данных) — после восстановления доступ будет открыт только членам роли базы данных db_owner и членам серверных ролей dbcreator и sysadmin. Этот параметр обычно применяется в тех случаях, когда после восстановления базы данных вам необходимо произвести дополнительные проверки или внести исправления.

Restore the database files as (Восстановить файлы базы данных как) — данный параметр, позволяет определить новый путь для восстанавливаемых файлов баз данных. Применяется, в тех ситуациях, когда производится восстановление базы данных на другой сервер, на котором конфигурация дисков выглядит по-другому.

Recovery state (Состояние восстановления) — этот параметр определяет, будет ли база данных открыта для пользователей после окончания восстановления с носителя. Возможны три варианта:

1. WITH RECOVERY — восстановление в обычном режиме. После окончания восстановления начнется процедура RECOVERY, все незавершенные транзакции будут отменены, и в итоге база данных будет открыта для пользователей. Этот параметр используется по умолчанию;

2. WITH NORECOVERY — после окончания процесса восстановления с носителя процедура RECOVERY не начнется. Базы данных останется в нерабочем состоянии восстановления. Этот параметр используется тогда, когда после восстановления резервной копии вы хотите восстановить дополнительные копии, например, после восстановления полной резервной копии восстановить резервную копию журнала транзакций;

3. WITH STANDBY — процедура RECOVERY начнется, но вся информация о всех отмененных незавершенных транзакциях будет записана в файл отмены (его нужно будет указать). В результате пользователи смогут обращаться к восстановленной базе данных для чтения (например, для создания отчетов), но в то же время сохраняется возможность применения следующих резервных копий журналов транзакций. Такое решение используется обычно только при применении автоматической доставки журналов на резервный сервер (log shipping).

На языке запросов восстановление базы данных выглядит следующим образом:

3. Сжатие баз данных (Shirink Database)

В зависимости от того, что содержится в файле баз данных в настоящий момент, может возникнуть потребность уменьшить его размер на диске. Наибольший эффект от операции сжатия достигается после операции, удаляющей из базы данных очень большой объем данных, а также только в случае, когда такое свободное место не планируется использовать повторно.

Большинству баз данных требуется некоторое свободное пространство для выполнения обычных ежедневных операций. Если сжатие баз данных производится регулярно, но ее размер снова увеличится, это означает, что место освобожденное при сжатии, необходимо для нормальной работы. В этом случае регулярное сжатие базы данных не даст нужного эффекта.

Операция сжатия не сохраняет состояние фрагментации индексов в базе данных и, как правило, приводит к большей фрагментации. Поэтому не следует организовывать регулярное сжатие файлов баз; Производить сжатие следует только при появлении большого объема неиспользуемого места в результате выполнения операции, которая оказывает значительное влияние на используемое место в базе данных. Для устранения фрагментации, после выполнения операции сжатия следует выполнять операцию перестроения индексов, но это вызывает повторный рост базы данных и появление неиспользуемого места!

Для выполнения операции сжатия файлов данных и журналов транзакций в конкретной базе необходимо выполнение инструкции DBCC SHRINKDATABASE. Для сжатия отдельных файлов используется команда DBCC SHRINKFILE.

Для выполнения операции сжатия баз данных (Shirink Database) с помощью графического средства Managment Studio в контейнере Database щелкаемся правой кнопкой и в контекстном меню выбираем: Tasks - Shrink - Database.

В появившемся окне в поле Currently allocated space (Выделенное в данный момент место) указывается суммарный объем данных, которые использует база данных и лог транзакций.

В поле Available Free Space (Доступное свободное место) указывается объем данных который высвободится после операции сжатия.

Reorganize files before releaising unused space. (Реорганизовывать файлы перед освобождением неиспользованного места). Установка данного флажка эквивалентна выполнению инструкции DBCC SHRINKDATABASE с заданием целевого процентного параметра. Снятие данного флажка эквивалентно выполнению инструкции DBCC SHRINKDATABASE с параметром TRUNCATEONLY (освобождает для операционной системы все свободное пространство в конце файла, но не выполняет перемещение страниц внутри файла) По умолчанию при открытии диалогового окна этот флажок не установлен. Если этот флажок установлен, то необходимо задать целевое процентное значение в поле Maximum free space in files after shirinking (максимальное свободное пространство в %, которое должно остаться в базе данных после ее сжатия.)

Аналогичная операция на языке запросов T-SQL, будет выглядеть так:

Иногда, может возникнуть ситуация, когда файлы журнала начали существенно увеличиваться в размере, порой превышая по объему саму базу данных в несколько раз. Происходит это, потому что, в свойствах базы данных выставлена полная модель восстановления (Full) или модель с неполным протоколированием (Bulk-Logged), которая по сравнению с простой моделью восстановления (Simple) не предполагает автоматическое очищение журнала транзакций. Поэтому, что избежать данной ситуации необходимо на ровне с полным резервным копированием регулярно выполнять резервное копирование журнала транзакций.

Для того что бы уменьшить размер файла журнала транзакций, необходимо сначала:

Выполнить его резервное копирование (*.trn), при этом убедившись что полная резервная копия самой базы (*.bak) так же присутствует.

Затем выполнить сжатие файла журнала транзакции при помощи вышеназванной операции либо при помощи команды DBCC SHRINKFILE или соответствующей ей операции в графическом контексте Managment Studio:

В контейнере Database щелкаемся правой кнопкой и в контекстном меню выбираем: Tasks - Shrink - Files.

В появившемся окне в поле File Type выбираем Log. Нажимаем Ок.

При помощи команд T-SQL:

4. Дефрагментация индексов.

Индексы - это определяемые пользователем структуры данных, позволяющие организовать быстрый доступ к данным без поиска по всей БД.

Перестроение (пересоздание) индекса (Rebuild Index) удаляет индекс и создает новый. При этом фрагментация исчезает, а дисковое пространство освобождается с помощью сжатия страниц, используя заданное или существующее значение коэффициента заполнения. Строки индекса упорядочиваются заново в смежных страницах (при необходимости выделяются новые страницы). Это может повысить быстродействие диска, уменьшая число чтений страниц, необходимое для получения запрошенных данных.

При обновлении бухгалтерии, на этапе сохранения, получил следующую ошибку:

Каталог не обнаружен 'v8srvr://sql/acc_main/configsave/e0666db2-45d6-49b4-a200-061c6ba7d569.6b9d6525-ee94-4e13-b73d-82d3e8e8441d'

по причине: Каталог не обнаружен 'ConfigSave\e0666db2-45d6-49b4-a200-061c6ba7d569.6b9d6525-ee94-4e13-b73d-82d3e8e8441d'

по причине: Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Журнал транзакций для базы данных "acc_main" переполнен. Причина: "LOG_BACKUP". HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1

Идем на сервер и первым делом проверяем место на дисках,

А оно закончилось нужно потом почистить хард или увеличивать объем, а пока порежем лог

Открываем SQL Server Management Studio

Это ошибка Microsoft SQL Server - переполняется лог транзакций и не очищается. Урезать его возможно различными способами, в том числе и с помощью стандартной оснастки, но не всегда данная операция получается, и размер файла лога остается прежним. Как вариант предлагаю следующее решение из двух строчек( где acc_main - название базы Бух)

Тоже самое можно сделать вручную:

Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе - Свойства(Properties) - Параметры(Options) - 4-й сверху пункт Модель восстановления(Recovery model) - Простая(Simple) - OK.

Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе - Задачи(Tasks) - Сжать(Shrink) - Файлы(Files) - установить Тип файла(File type) - Журнал(Log) - в Операция сжатия(Shrink action) - выбрать Реорганизовать страницы, перед тем осводить неиспользуемое место(Reorganize pages before releseasing unused space) - Сжать файл (Shrink file to) - указать приемлемый размер лога.

Шаг 3. Установить модель восстановления Полная(Full). Правой кнопкой на базе - Свойства(Properties) - Параметры(Options) - 4-й сверху пункт Модель восстановления(Recovery model) - Полная(Full) - OK.

В дополнении скажу, что можно сохранить лог в файл и выполнить шринк так(BaseDB - имя базы данных):

Еще в этой же категории

Ключевые слова и Изображения

Слова упорядочены по частоте использования в тексте

Изображения

Планы обслуживания/Maintenance Plan в MS SQL Server

Вообще, планы обслуживания нужно подстраивать под конкретное оборудование и базы данных. Оставим это на усмотрение профессионалов администрирования баз данных. В общем случае, для базы данных не более 200 Гб в MS SQL Server рекомендуется выполнять следующие регламентные операции:

Проверка целостности базы данных
Реорганизация индекса/Восстановить индекс
Обновление статистики

Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур.

Проверка целостности базы данных/DBCC CHECKDB

Периодичность: 1 раз в неделю.

Время запуска: в технологическом окне — во время минимальной нагрузки.

Выбираем необходимые базы данных для обслуживания: либо какую-то определенную, либо несколько, либо все пользовательские.

Реорганизация индекса/Восстановить индекс

MS SQL Server самостоятельно создает и изменяет индексы при работе с базой. С течением времени данные в индексе становятся фрагментированными, т.е. разбросанными по базе данных. Существенно фрагментированные индексы могут серьезно снижать производительность запросов и служить причиной замедления работы базы. Если фрагментация составляет от 5 до 30%, то рекомендуется ее устранить с помощью реорганизации, при фрагментации свыше 30% необходимо полное перестроение индексов.

В простейшем случае получить информацию по фрагментации индексов можно с помощью кода:

Почему регулярно стоит использовать именно реорганизацию индекса?

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

Вывод: Если фрагментация более 30%, нужно выполнить разовое полное перестроение индексов (восстановить индекс). После перестроения планово использовать только реорганизацию.

Периодичность: 1 раз в сутки.

Время запуска: в технологическом окне — во время минимальной нагрузки.

Обновление статистики

Статистика — небольшая таблица (обычно до 200 строк), в которой хранится обобщенная информация о том, какие значения и как часто встречаются в таблице. На основании статистики сервер принимает решение, как лучше построить запрос. Обычно, оптимизатор запросов создает необходимую статистику, но иногда необходимо создать дополнительные статистические данные для достижения лучших результатов.

Во время выполнения процедуры обновления статистики данные не блокируются, т.е. пользователи могут работать. Однако, следует помнить, что нагрузка во время выполнения этой процедуры на сервер SQL возрастает, а это может сказаться негативно на производительности системы. Поэтому обновлять статистику желательно в технологическом окне — времени наименьшей нагрузки на базу.

Периодичность: 1 раз в сутки.

Время запуска: в технологическом окне — во время минимальной нагрузки.

Обновление статистик и реорганизацию индекса и создание полного архива можно уместить в одну задачу, выбрав в окне выбора задач обслуживания соответствующие флаги.

Контроль выполнения планов обслуживания

Если в журнале будут обнаружены ошибки, стоит изучить проблему и принять меры. Планы обслуживания должны отрабатывать успешно.

Почему не стоит использовать сжатие базы данных (шринк/shrink)?

Пожалуй, единственным случаем, когда есть смысл использовать сжатие базы данных — масштабные изменения в базе данных. Например: после восстановления из DT-дампа, свертки или реструктуризации информационной базы.

В остальных случаях:

сжатие файла базы данных (MDF) приводит к увеличению индексов;
сжатие файла журнала транзакций (LDF) не нужно при правильной настройке резервного копирования и обслуживании индексов. При использовании полной модели восстановления (Full Recovery Model) базы SQL важно делать регулярные резервные копии файла журнала транзакций и только перестроение индексов. Тогда, файл LDF будет соизмерим с размером файла базы данных и не будет бесконтрольно расти.

Очень часто в практике встречаются случаи, когда, с точки зрения администраторов, "внезапно" начинает катастрофически увеличиваться размер журнала транзакций (*.ldf) и файла с данными (*.mdf) у рабочей базы MS SQL. Для связки 1С:Предприятие + MS SQL вообще характерно такое поведение. Связано оно, в первую очередь, с обновлениями конфигураций 1С, когда с очередным обновлением добавляются новые объекты и процедуры, проводятся какие-то манипуляции с существующими объектами типа их реиндексации, реструктуризации баз и т.п. Второй вариант причины такого поведения - запуск массовой обработки объектов базы 1С, возможно, не оптимальными методами. Ну и третий вариант - просто резкое увеличение рабочей нагрузки на базу. Поскольку дисковый ресурс серверов БД, как известно, не резиновый, резкий рост размеров базы зачастую приводит к панике администраторов и разнообразным попыткам самостоятельно эту проблему решить. Предлагаю администраторам БД отработанные на практике несколько более или менее эффективных способов решения.

1. Если у вас есть возможность перенести рассматриваемую базу на более ёмкий диск, а лучше, просто на другой, можно это сделать. Как вариант - перенести только журнал транзакций *.ldf или файл с данными *.mdf. Причем, если вы не опирались на мои и другие известные рекомендации при развертывании этой самой базы, не поздно это сделать и сейчас, тем более, ситуация позволяет). Делается это, в основном, с помощью SQL Server Management Studio (SSMS) следующим образом:

- подготовить новый раздел, куда будет перенесен журнал транзакций (или данные), желательно, если это будет физически вообще другой диск;

- убедиться, что нет ни одного активного сеанса работы с базой. Если это база 1С:Предприятия, рекомендуется остановить службу "Агент сервера 1С:Предприятия";

- выполнить присоединение (attach) базы с указанием нового места расположения файла с журналом (или данными);

Таким образом вы на некоторое время отсрочите очередное возникновение проблемы с нехваткой дискового пространства. Вместе с тем, вы получите некоторый прирост производительности базы за счет разнесения на разные диски файла данных и журнала MS SQL.

2. В оснастке SSMS существуют инструменты для "сжатия" или "усечения" (shrink) как отдельных файлов, так и базы данных целиком:

Бывают случаи, когда подобное усечение помогает существенно уменьшить занимаемое базой дисковое пространство как за счет уменьшения mdf-файла, так и за счет уменьшения размера файла с журналом *.ldf.

Хотелось бы отметить, что как временная мера методы 1 и 2 в общем то эффективны. Но если база уже "пошла в рост", скорее всего, этот процесс не остановить и через некоторое время вы опять столкнетесь с увеличением ее размеров. Поэтому давайте подробно рассмотрим еще один, более радикальный способ борьбы с ростом баз.

Итак, если приведенные выше методы уже исчерпали себя, или вы еще только проектируете систему и не хотите в будущем столкнуться с проблемой нехватки места для баз, я рекомендую использование периодического оперативного бэкапа вашей базы. Суть выполнения этого оперативного бэкапа в том, что с его помощью высвобождаются неактивные записи журнала транзакций (Transaction Log) путем выгрузки их в бэкап и последующего автоматического усечения файла журнала.

Теперь о том, как это настроить. Для начала необходимо выделить место, куда будут выгружаться бэкапы. Это должен быть ёмкий дисковый массив, достаточно скоростной (в первую очередь необходим скоростной линк к серверу БД) и надежный, учитывая хранение на нем бэкапов. Причем, повторюсь, я говорю не о стандартном, скажем, ежесуточном бэкапе средствами MS SQL, а об оперативном бэкапе, который мы будем выполнять чаще, чем раз в сутки, а именно, в рабочие часы, с интервалом от 30 минут до 2-х часов (зависит от интенсивности работы в базе и ее размеров). Остальные действия по настройке выполняются в SSMS.

Читайте также:

Как сделать шринк базы 1с

Похожие FAQ

Еще в этой же категории

Ключевые слова и Изображения

Слова упорядочены по частоте использования в тексте

Изображения

Планы обслуживания/Maintenance Plan в MS SQL Server

Проверка целостности базы данных/DBCC CHECKDB

Реорганизация индекса/Восстановить индекс

Почему регулярно стоит использовать именно реорганизацию индекса?

Обновление статистики

Контроль выполнения планов обслуживания

Почему не стоит использовать сжатие базы данных (шринк/shrink)?