Ms sql shrink log: Шринк (Shrink) лога транзакций MS SQL 2008/2012

Шринк (Shrink) лога транзакций MS SQL 2008/2012

Когда при подключении к базе MS SQL появляются ошибки:

Ошибка СУБД: 
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных «ReportServer» заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы 
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1
или
Ошибка СУБД: 
Microsoft OLE Provider for SQL Server: The transaction log for database “ReportServer” is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column is sys.database 
HRESULT=80040E14, SQLSTATE=4 2000, native=9002

это значит, что на диске, где расположен лог транзакций закончилось место и теперь СУБД некуда записывать данные о новых транзакциях. Чаще всего такое происходит, когда не установлено никаких ограничений на размер лога и в MS SQL не создано соответствующих планов обслуживания.

В таком случае нужно уменьшить размер самого файла транзакций (*.ldf), другими словами сделать шринк (сжатие) лога. Для этого можно использовать как запрос, так и сжатие лога вручную.

Рассмотрим сжатие лога транзакций вручную:

Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе — Свойства(Properties)

Далее:  Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Простая(Simple) — OK.

Выполнить сжатие (Shrink) лога транзакций. Правой кнопкой на базе — Задачи(Tasks) — Сжать(Shrink) — Файлы(Files) 

Установить Тип файла(File type) — Журнал(Log) — в Операция сжатия(Shrink action) — выбрать Реорганизовать страницы, перед тем освоить неиспользуемое место(Reorganize pages before releseasing unused space) — Сжать файл (Shrink file to)
указать приемлемый размер лога.

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

Вконтакте

Одноклассники

Мой мир

Facebook

E-mail

Shrink базы данных MS SQL — Записки сумасшедшего дроида

Существует ситуация, когда LDF файл занимает много гигабайт места (файл с _log), и его необходимо уменьшить.

Это происходит когда база в SQL находится в режиме Full, т.е. с фиксацией всех произведенных транзакций. Модель Full позволяет восстановить состояние базы SQL на любое время, в то время, как модель Simple не позволяет этого сделать, а только восстановить базу из бэкапа. Смысл модели Full в том, что в журнал транзакций LDF записываются ВСЕ транзакции и там остаются, ну до определенного времени, например, до операции shrink. Таким образом SQL последовательным откатом транзакций назад может восстановить состояние базы на любой момент времени периода записанных в LDF транзакций.

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

Первое что нужно сделать, перевести базу в модель восстановления Simple (при этом настроить механизм создания беэкапов базы, если этого до сих пор не сделано). Эту операцию можно делать «на ходу».
Однако, перевод в simple автоматически не уменьшает размер файла транзакций. Можно, провести операцию shrink (сжатие базы) сразу, но лучше сначала сделать полный бэкап базы средствами SQL (есть там в SQL-е по этому поводу одна маленькая хитрость), а потом сделать shrink как файлу базы MDF, так и файлу журнала транзакций LDF. Размер базы тоже должен уменьшиться, но не на много, а, вот, размер файла транзакций LDF, если было сделано все правильно, должен стать практически нулевым (в случае, когда в этом момент в базе нет активной работы пользователей).
Операции бэкапа средствами SQL, и shrink-а, можно делать не выгоняя пользователей, эти операции могут, разве что, сказаться на производительности. Настоятельная рекомендация сделать резервные копии перед началом этой операции.

USE [dbname];
GO
— Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE [dbname]
SET RECOVERY SIMPLE;
GO
— Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE ([dbname_Log], 1);
GO
— Reset the database recovery model.
ALTER DATABASE [dbname]
SET RECOVERY FULL;
GO

Километры логов и восстановление баз данных на MS SQL / Блог компании СофтЛаб / Хабр

Или как без труда восстанавливать базы данных из длинной цепочки бэкапов

Введение

Если вы используете SQL Server, то, вероятно, слышали про Полную и Простую модель восстановления баз данных. Вы, возможно, знаете, что Простая модель позволяет восстановить данные только на момент создания резервной копии, в то время как Полная — на любой момент времени, надо лишь регулярно делать резервные копии журнала транзакций. Однако, для восстановления данных при Полной модели потребуется «накатить» резервные копии журналов транзакций в определенной последовательности. Это можно без проблем сделать с помощью SSMS, но только на том SQL Server, где создавались резервные копии. Для восстановления на другом сервере потребуется вручную написать T-SQL скрипт. И чем длиннее будет цепочка резервных копий, тем больше будет сам скрипт и тем больше времени уйдет на его создание. По этой же причине администраторы редко используют уже созданные резервные копии, когда требуется развернуть копию базы на другом SQL Server, и предпочитают создавать свежий полный бэкап. Но такая процедура может быть настоящей проблемой для больших баз данных из-за высокой нагрузки на сервер. Кроме этого, если сервер «упал», то, как правило, нет времени писать длинный T-SQL скрипт для восстановления. В такие моменты нужно делать все максимально быстро и без лишней нервотрепки.

В интернете, в том числе и на Хабре (например, тут), можно найти различные способы, решающие задачу автоматизированного построения T-SQL скрипта восстановления. В основном это различные скрипты, базирующиеся на названиях файлов резервных копий или запросы на сервер-источник к истории резервных копий (к базе msdb). В этой статье я хотел бы сделать обзор возможностей XML-планов восстановления, которые появились в Quick Maintenance & Backup for MS SQL начиная с версии 1.6.

Обзор самой утилиты можно почитать в статье по этой ссылке или на официальном сайте. Наличие XML-плана восстановления в сетевой папке вместе с резервными копиями позволит не тратить время на подготовку T-SQL скрипта. Какая бы длинная ни была цепочка резервных копий, вы в несколько кликов восстановите базу данных на другом SQL Server. Также это можно делать по расписанию, на тестовом или рабочем сервере, например, для проверки всей цепочки резервных копий или актуализации копий баз данных.

Что такое XML-план восстановления

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

<?xml version="1.0" encoding="cp866"?>

<RestorationPlanInfo xmlns:i="http://www. w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/ScriptManagerServer.Core.ScriptManagerServerCore.BackupRestore">
  <Version>1</Version>
  <ServerName>London</ServerName>
  <ServerVersion>10</ServerVersion>
  <ServerDescriptrion>Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) </ServerDescriptrion>
  <CreationDate>2016-02-16T17:00:04.65625+03:00</CreationDate>
  <Databases>
    <RestorationPlanDbInfo>
      <Name>Northwind</Name>
      <RestorePoint>2016-02-16T17:00:02</RestorePoint>
      <Files>
        <RestorationPlanDbFileInfo>
          <FileName>London\Northwind\Full\20160216_155457_London_Northwind_Full.bak</FileName>
          <BackupType>Full</BackupType>
          <Position>1</Position>
          <BackupStartDate>2016-02-16T15:54:57</BackupStartDate>
          <FirstLsn>58000000021900037</FirstLsn>
          <LastLsn>58000000023500001</LastLsn>
          <StopAt i:nil="true" />
        </RestorationPlanDbFileInfo>
        <RestorationPlanDbFileInfo>
          <FileName>London\Northwind\Diff\20160216_162546_London_Northwind_Diff. bak</FileName>
          <BackupType>Differential</BackupType>
          <Position>1</Position>
          <BackupStartDate>2016-02-16T16:25:47</BackupStartDate>
          <FirstLsn>58000000024300034</FirstLsn>
          <LastLsn>58000000025800001</LastLsn>
          <StopAt i:nil="true" />
        </RestorationPlanDbFileInfo>
        <RestorationPlanDbFileInfo>
          <FileName>London\Northwind\Log\20160216_163000_London_Northwind_Log.trn</FileName>
          <BackupType>Log</BackupType>
          <Position>1</Position>
          <BackupStartDate>2016-02-16T16:30:01</BackupStartDate>
          <FirstLsn>58000000024300001</FirstLsn>
          <LastLsn>58000000025800001</LastLsn>
          <StopAt i:nil="true" />
        </RestorationPlanDbFileInfo>
        <RestorationPlanDbFileInfo>
          <FileName>London\Northwind\Log\20160216_170001_London_Northwind_Log. trn</FileName>
          <BackupType>Log</BackupType>
          <Position>1</Position>
          <BackupStartDate>2016-02-16T17:00:02</BackupStartDate>
          <FirstLsn>58000000025800001</FirstLsn>
          <LastLsn>58000000025800001</LastLsn>
          <StopAt i:nil="true" />
        </RestorationPlanDbFileInfo>
      </Files>
    </RestorationPlanDbInfo>
  </Databases>
</RestorationPlanInfo>

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

Создание XML-плана

Программа позволяет создавать XML-план двумя способами:

• Для тех, кто обслуживает базы данных с помощью QMB, достаточно установить свойство Создавать XML-план восстановления в политике обслуживания. Теперь XML-файл будет пересоздаваться каждый раз после создания любой резервной копии в сценарии обслуживания. Если в программе настроено копирование бэкапов в сетевую папку, то файл XML-плана также будет копироваться. Таким образом в сетевой папке будет всегда свежий XML-план восстановления.
• Тем, у кого уже имеется штатный План обслуживания, создающий бэкапы, можно воспользоваться специальной задачей и по расписанию создавать XML-план восстановления.  В задаче необходимо указать имя XML-файла, базы данных и подключение к папке, где будет создан XML-план восстановления, см. рисунок. Для того чтобы задача выполнялась по расписанию, её необходимо включить в сценарий.

Перед созданием XML-файла программа определит последовательность резервных копий по информации, хранимой в системной базе mdsb, аналогично тому, как это делает SQL Server Management Studio. Для первого и второго способов XML-план будет содержать последовательность резервных копий, необходимых для восстановления базы данных на последнее возможное состояние.

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

Восстановление по XML-плану

Восстановление баз данных по XML-плану может выполняться двумя способами:

1. Вручную. Для этого в программе имеется специальное окно, которое вызывается командой «Восстановить по XML-плану» из контекстного меню в древовидном списке серверов.

На форме нужно выбрать XML-файл и базы данных, резервные копии которых будут восстановлены. Обратите внимание, восстанавливать можно в одноименные базы данных, во временную, либо в указанную базу данных. Режим восстановления во временную базу данных удобен для проверки цепочки резервных копий. Режим в Указанную базу данных может быть полезен, если требуется восстановить в определенную базу данных, например, с нестандартным размещением её файлов на дисках. По кнопке «Показать Т-SQL» можно просмотреть сформированный T-SQL скрипт, который будет запущен для восстановления.
2. Автоматически по заданному расписанию. Например, если требуется регулярная проверка цепочки резервных копий на тестовом SQL Server, или актуализация баз данных. Для этих целей в программе предусмотрена специальная задача. Параметры, указываемые в задаче, практически аналогичны тем, что задаются на форме восстановления в ручном режиме.
Для того чтобы задача выполнялась по расписанию, её необходимо включить в сценарий. Например, в ночной. Подробный лог восстановления можно просматривать в журнале обслуживания.

Заключение

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

Если вы уже используете QMB и не задействовали эту возможность, то ск

Уменьшение размера логов баз SQL – ЗАПИСКИ КРАСНОДАРСКОГО СИСАДМИНА

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

Заходим в SQL Server Management Studio, подключаемся к нужному серверу, выбираем нужную базу и открываем для неё форму свойства в контекстном меню и в разделе “Параметры” меняем модель восстановления на простую.

Закрыв форму “Свойства”, выбираем в контекстном меню базы “Задачи”-“Сжать”-“Файлы”

В появившийся форме выбираем тип файла “Журнал”, и в настройках операций сжатия пункт “Реорганизовать страницы, перед тем как освободить”. Если в пункте “Сжать файл” установить 0, тогда накопившиеся на момент сжатия логи будут удалены.

При необходимости, возвращаем обратно модель восстановления данных “Полная”.

В продолжение темы, рассмотрим удаление неиспользуемых журналов регистрации из папки Srvinfo Сервера Предприятия 1С.

Для каждой базы данных 1С существует своя директория хранения журнала регистрации и выглядит она таким образом

C:\Program Files\1cv8\srvinfo\<Имя кластера сервера>\<Идентификатор базы на сервере>\1Cv8Log

После удаления базы данных с сервера 1С папка журнала регистрации не удаляется из Srvinfo. Поэтому из множества папок в Srvinfo могут находиться и те, которые давно не используются и просто занимают место на жестком диске. Вычислить эти папки можно открыв файл 1CV8Clst.lst, который находится так же в reg_1541.

Копируем <Идентификатор базы на сервере> из папки Srvinfo и ищем в файле 1CV8Clst. lst. Если идентификатор в файле не найден, то папку можно удалять.

В директории Srvinfo находится папка с названием вида snccntx+<Идентификатор базы на сервере>. Эта папка содержит сеансовые данные и ее лучше не удалять без необходимости, да и много места она не занимает.

1 013

Операции резервного копирования, усечения и сжатия журнала транзакций SQL Server

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

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

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

Резервное копирование журнала транзакций

При настройке базы данных с использованием простой модели восстановления журнал транзакций SQL Server будет помечен как неактивный и автоматически усечен после фиксации активной транзакции. Это не относится к моделям восстановления базы данных с полным и неполным протоколированием. Когда для базы данных настроена модель полного восстановления, журнал транзакций SQL Server в файле журнала транзакций будет помечен как неактивный после фиксации транзакции без автоматического усечения, так как это будет , ожидающее выполнения резервного копирования журнала транзакций . Напомним, что только резервная копия журнала транзакций, но НЕ полная резервная копия базы данных, будет вырезать журналы транзакций из файла журнала транзакций и сделать его доступным для повторного использования. Если из базы данных не берется резервная копия журнала транзакций, файл журнала транзакций будет постоянно увеличиваться без усечения, пока в нем не закончится свободное пространство.

Резервная копия журнала транзакций SQL Server может быть взята только из базы данных, если модель восстановления этой базы данных является полной или с неполным протоколированием.Модель восстановления базы данных можно проверить на вкладке Options окна Database Properties, как показано ниже:

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

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

Давайте сделаем полную резервную копию базы данных, чтобы иметь возможность делать резервную копию журнала транзакций для этой базы данных. Мы будем использовать команду T-SQL BACKUP DATABASE для выполнения операции полного резервного копирования базы данных в нашем примере. Дополнительные сведения о различных способах и вариантах выполнения резервного копирования базы данных в SQL Server см. В серии «Резервное копирование и восстановление SQL Server».Полную резервную копию базы данных можно сделать с помощью сценария T-SQL ниже:

После того, как будет выполнено полное резервное копирование базы данных, мы начнем резервное копирование журнала транзакций для базы данных. Первая резервная копия журнала транзакций создаст резервную копию всех транзакций, произошедших в базе данных с момента последней полной резервной копии. Резервную копию журнала транзакций можно сделать с помощью команды T-SQL BACKUP LOG ниже:

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

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

Предположим, что вы по ошибке выполнили приведенную ниже инструкцию DELETE, не указав предложение WHERE. Это означает, что все записи таблицы будут удалены:

Если вы разработали подходящее решение для резервного копирования, данные можно легко восстановить, восстановив базу данных до определенного момента времени перед выполнением оператора DELETE.В окне «Восстановить базу данных» SQL Server вернет полную цепочку резервных копий, взятую из этой базы данных. Если вы знаете точный файл, который берется непосредственно перед удалением данных, вы можете остановиться на этом конкретном файле, как показано ниже:

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

Усечение журнала транзакций

Усечение журнала транзакций SQL Server — это процесс, в котором все VLF, помеченные как неактивные, будут удалены из файла журнала транзакций SQL Server и станут доступны для повторного использования. Если в VLF есть одна активная запись журнала , общий VLF будет считаться активным журналом и не может быть усечен.

Журнал транзакций SQL Server для базы данных, настроенной с использованием модели восстановления Simple , может быть автоматически усечен, если:

• Сработал оператор контрольной точки
• Транзакция базы данных зафиксирована

Журнал транзакций SQL Server для базы данных, для которой настроена модель восстановления Full или Bulk-Logged , может быть усечен автоматически:

• После выполнения процесса резервного копирования журнала транзакций, когда журнал транзакций не ожидает активной транзакции или какой-либо функции высокой доступности, такой как зеркалирование, репликация или группа доступности AlwaysOn

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

• TRUNCATE_ONLY Параметр резервного копирования журнала транзакций, который прерывает цепочку резервного копирования базы данных и усекает доступные журналы транзакций. (Доступно только до SQL Server 2008.)
  Если вы попытаетесь усечь журнал транзакций базы данных с помощью параметра TRUNCATE_ONLY в экземпляре SQL Server версии 2008 и более поздних версий, выполнение оператора завершится ошибкой с сообщением об ошибке ниже:

Уменьшение журнала транзакций

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

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

Файл журнала транзакций базы данных можно уменьшить, щелкнув правой кнопкой мыши базу данных и выбрав параметр «Сжать» -> «Файлы» в меню «Задачи», как показано ниже:

На странице «Файл сжатия» измените Тип файла на Журнал и выберите файл журнала транзакций, который нужно сжать. На этой странице у вас есть три варианта:

Тот же файл журнала транзакций можно сжать с помощью инструкции DBCC SHRINKFILE T-SQL ниже:

Сжать файл журнала транзакций до размера, меньшего, чем размер виртуального файла журнала, невозможно, даже если это пространство не используется.Это связано с тем, что файл журнала транзакций можно сжать только до границы VLF. В этом случае ядро ​​СУБД SQL Server освободит как можно больше места, а затем выдаст информационное сообщение, как показано ниже:

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

Содержание

Ахмад Ясин (Ahmad Yaseen) — инженер Microsoft по большим данным с глубокими знаниями и опытом в областях SQL BI, администрирования баз данных SQL Server и разработки.

Он является сертифицированным специалистом по решениям Microsoft в области управления данными и аналитикой, сертифицированным партнером по решениям Microsoft в области администрирования и разработки баз данных SQL, партнером разработчика Azure и сертифицированным инструктором Microsoft.

Кроме того, он вносит свои советы по SQL во многие блоги.

Посмотреть все сообщения от Ahmad Yaseen

Последние сообщения от Ahmad Yaseen (посмотреть все)

Ежедневное сжатие журнала базы данных с автоматическим использованием заданий в SQL Server — статьи TechNet — США (английский)

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

Шаг 1

Откройте SQL Server и перейдите к агенту SQL Server. Агент SQL Server должен быть запущен, если он остановлен. Щелкните правой кнопкой мыши агент SQL Server и нажмите кнопку Пуск.

После нажатия кнопки «Пуск» появится запрос на подтверждение в виде «Вы действительно хотите запустить службу SQLSERVERAGENT». Нажмите кнопку ОК.

Теперь агент SQL Server запущен.Теперь мы можем создавать задания для сжатия журнала базы данных. После запуска агента SQL Server мы можем увидеть следующий снимок экрана.

Шаг 2

Для сжатия журнала базы данных нам нужно написать SQL-запрос. Синтаксис и SQL-запрос для сжатия журнала базы данных приведены ниже.

Синтаксис

1. ALTER DATABASE Database_Name SET RECOVERY SIMPLE WITH NO_WAIT
2. DBCC SHRINKFILE ([DatabaseName_Log], 0, TRUNCATEONLY)
3. ALTER DATABASE Database_Name SET RECOVERY FULL WITH NO_WAIT
4. ГО

Запрос

Здесь мы используем базу данных как «образец». Запрос на сжатие журнала базы данных написан ниже.

1. ALTER DATABASE Sample SET ВОССТАНОВЛЕНИЕ ПРОСТО С NO_WAIT
2. DBCC SHRINKFILE ([Sample_log], 0, TRUNCATEONLY)
3. ALTER DATABASE Sample SET RECOVERY FULL WITH NO_WAIT
4. ГО

Найти базу данных и файл журнала

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

Разверните базу данных и перейдите в нашу базу данных.Теперь щелкните правой кнопкой мыши свою базу данных и перейдите в Свойства. Затем нажмите «Файлы» в окне «Свойства базы данных» и подтвердите имя базы данных и имя файла журнала в столбце «Логическое имя».

Шаг 3

Щелкните правой кнопкой мыши «Задания» и выберите «Новое задание». Откроется окно «Новое задание».

Введите имя, описание, а сведения о владельце и категории вводятся по умолчанию.

Шаг 4

Перейдите в «Шаги» в окне «Новое задание» и нажмите кнопку «Создать» в нижней части окна.

После нажатия кнопки «Новый» откроется окно «Новый шаг задания». Введите имя шага, выберите тип «Transact-SQL script (T-SQL)».

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

Шаг 5

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

Мы можем установить конкретное время для запуска SQL-скрипта для сжатия журнала базы данных в «Ежедневной частоте», затем нажмите кнопку ОК.

Шаг 6

Теперь мы завершаем все настройки и нажимаем ОК в окне «Новое задание». Перейдите к агенту SQL Server и разверните Jobs в разделе SQL server agent, мы увидим наши задания журнала сжатия базы данных.

Шаг 7

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

Мы можем ежедневно проверять, успешно ли работает наша работа. Перейдите в раздел «Работа» и щелкните правой кнопкой мыши «Задания», затем нажмите «Просмотреть историю». Теперь мы можем видеть историю всех вакансий.

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

Shrink Database File (mdf) в SQL Server

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

Самый простой способ — использовать метод transact-sql DBCC SHRINKDATABASE для сжатия только файла данных. Следующий метод — использовать transact-sql DBCC SHRINKFILE . Другой способ — использовать графический интерфейс Shrink File в SSMS . Я рассмотрю эти методы один за другим. Перед сжатием файла данных ознакомьтесь с лучшими практиками и следуйте им.

Передовой опыт

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

DBCC SHRINKDATABASE (Transact-SQL)

Шаблон запроса

ИСПОЛЬЗУЙТЕ {{Имя базы данных}}
ИДТИ
DBCC SHRINKDATABASE ({{Имя базы данных}})
ИДТИ
 

Пример

ИСПОЛЬЗУЙТЕ WideWorldImporters
ИДТИ
DBCC SHRINKDATABASE (WideWorldImporters)
ИДТИ
 

DBCC SHRINKFILE (Transact-SQL)

1. Получите имя файла журнала транзакций с помощью этого запроса.
   
   

   Шаблон запроса

   ИСПОЛЬЗУЙТЕ {{Имя базы данных}}
   ИДТИ
   EXEC sp_helpfile
   ИДТИ
    

   Пример

   ИСПОЛЬЗУЙТЕ WideWorldImporters
   ИДТИ
   EXEC sp_helpfile
   ИДТИ
    

   В этом примере WWI_Primary и WWI_UserData являются файлами базы данных этой базы данных.

2. Теперь выполните DBCC SHRINKFILE . Включите имя файла журнала в запрос файла сжатия. Целевой размер не является обязательным. Но желательно указать целевой размер, чтобы освободить достаточно места для обычных операций.
   
   

   Шаблон запроса

   ИСПОЛЬЗУЙТЕ {{Имя базы данных}}
   ИДТИ
   DBCC SHRINKFILE ('{{Имя файла журнала}}', {{Целевой размер в МБ}})
   ИДТИ
    

   Пример

   ИСПОЛЬЗУЙТЕ WideWorldImporters
   ИДТИ
   DBCC SHRINKFILE ('Первая мировая война', 10)
   ИДТИ
   DBCC SHRINKFILE ('WWI_UserData', 10)
   ИДТИ
    

Использование графического интерфейса пользователя SSMS

Метод сжатия базы данных

1. Войдите в систему SSMS .
2. В обозревателе объектов разверните папку Базы данных .
3. Выберите базу данных, файл журнала которой вы хотите сжать.
4. Щелкните правой кнопкой мыши по базе данных и выберите Задачи >> Сжать >> База данных .
5. В окне Shrink Database в разделе Shrink action выберите опцию Reorganize pages перед освобождением неиспользуемого пространства .и введите процент пространства, которое вы хотите оставить свободным.
6. Нажмите ОК. Это сократит файл базы данных.

Метод сжатия файла

1. Войдите в систему SSMS .
2. В обозревателе объектов разверните папку Базы данных .
3. Выберите базу данных, файл журнала которой вы хотите сжать.
4. Щелкните правой кнопкой мыши по базе данных и выберите Задачи >> Сжать >> Файлы .
5. В окне Shrink File выберите тип файла Data из раскрывающегося списка File Type .
6. В разделе Действие сжатия выберите опцию Реорганизовать страницы перед освобождением неиспользуемого пространства . И введите пространство, которое вы хотите оставить свободным.
7. Нажмите ОК. Это сократит файл базы данных.

Ссылка

• Об уменьшении размера базы данных в MSDN.
• О DBCC SHRINKFILE в MSDN.

SQL Server — Data Dosyasını Shrink Yapmalı mıyız?

SQL Server сжимает данные и журнал dosyaları üzerinde bulunan Boş alanları geri alarak dosya sisteminde kullanıma dahil etmek için yapılan işlemdir. Genellikle kısıtlı disk alanı yüzünden data veya log dosyalarındaki boş alanları küçülterek diskte yer açmak için tercih edilir. Birde küçük data dosyaları ( mdf, ndf ) daha performanceanslıdır diye bir efsane de vardır J

Gerçekten data dosyalarını shrink etmeli miyiz? Veri dosyalarını küçültmek avantajlı mıdır? Yoksa dezavantajları da var mı?

ncelikle SQL Server ’da Data dosyalarımızı küçültmek istediğimizde shrink işlemi yapılırken sistemde çok fazla kilitlenme meydana getirecektir.Çünkü küçültme işlemi için sayfalardaki veriler taşınacaktır. Taşıma yapılırken kilitlenmeler meydana gelecek olup işlem yapılan ее satır bilgi de günlük dosyasına (файл журнала) kaydedilecektir. Сжать файл данных işlemi yapılırken çok büyük oranda log dosyamızda büyüme olacaktır. (I / O Малиети)

Сжать yapılırken işlem yapılacak page arabellek havuzuna (буферный кеш) yüklenecek olup, arabellek havuzunu da ihtiyacımız olmayan sayfalarda dolduracaktır. Буферный кеш ihtiyaç olmayan sayfaları bellekten temizlese де sistem kaynağı maliyeti meydana gelecektir.

Сжать файл данных işleminden sonra yine yüksek bir I / O maliyeti ile karşı karşıya kalacağız. Bu maliyet dizin parçalanması (Фрагментация индекса) ‘dır. İstenmeyen бир durum olan index fragmentasyonu meydana geldiğinde veriye ulaşmak için daha fazla time ve i / o maliyeti ortaya çıkacak. Сжать işleminden sonra index fragmentasyonunu ortadan kaldırmak için yüksek CPU ve I / O maliyeti olan Index Восстановить индекс veya Реорганизовать işlemi yapmamız kaçınılmaz olacaktır.

Görüldüğü gibi avantajından daha çok dezavantajları bulunan shrink işlemini kesinlikle düzenli olarak (Автоматическая усадка) yapmanızı önermiyorum. Eğer bir seferlik büyük bir oranda küçülme ihtiyacınız varsa tavsiye olarak yeni bir data dosyası ( .ndf ) oluşturmanızı, tablolarınızı ve indexlerinuzi yeni Tabiki kullanmış olduğunuz sisteminize ve altyapınıza göre olarak size en uygun çözümü tercih etmelisiniz.

Shrink işleminin Index parçalanmasına nasıl sebep olduğunu incelemek için aşağıdaki örneği hazırladım. Özetle örneimde;

· Yeni бир veri tabanı oluşturuyorum.

· 2 танэ табло oluşturup birini boş alan meydana getirmek için siliyorum.

· Сжать işlemi yaptıktan sonra tablomda tanımlı olan Index’in parçalanma oranına bakıyorum.

Shrink işlemi öncesi Index Fragmentation oranımızı kontrol edelim.

Yukarıdaki resimde de görüldüğü gibi Index’imize parçalanma oranı neredeyse% 0

Artık « TempDemoTable » tablomuzu silbiliriz. Tablomuzu sildikten sonra veri tabanımızı kaç mb’ta kadar küçültebiliriz kontrol edelim. Bunun için ShrinkDemo veri tabanına sağ tıklayıp> Задачи> Сжать> Файлы menüsünü seçiyorum.

Ekranda 4 MB’ta kadar data dosyamın küçültülebileceği bilgisi mevcut. Данные досями 4 Мб сжаты редакцией.

Shrink işlemi sonrası tekrar Index parçalanma durumunu sorguluyorum.

Yukarıdaki resimde de görüldüğü gibi shrink işlemi sonrası dizin parçalanma durumu% 77 ‘ye ulaştı. Демо-тест и этмиш olduğumuz gibi Data File Shrink yapmadan önce birkaç kez daha düşünmekte fayda var.

Yararlı olmasını dilerim.

Сервер

sql сжимается

Программное обеспечение и алгоритмы

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

Языки программирования

Язык программирования — это формальный сконструированный язык, предназначенный для передачи инструкций машине, в частности компьютеру. Его можно использовать для создания программ для управления поведением машины.
Java, C,
С ++, С #

База данных

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

Оборудование

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

Веб-технологии

Веб-разработка — это широкий термин для обозначения работы, связанной с разработкой веб-сайта для Интернета или внутренней сети.Html, Css, JavaScript, ASP.Net, PHP — одни из самых популярных технологий.
J2EE, Spring Boot, Servlet,
JSP, JSF,
ASP

Мобильные технологии

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

Сеть

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

Операционные системы

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