How to Truncate Transaction Logs on MS SQL Server?
In this case, this error appears when you are connecting to MS SQL database:
Microsoft OLE Provider for SQL Server: The transaction log for database “YourDBName” 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
Or
Action failed for Database MSSQL (Microsoft.SqlServer.Smo) An exception occurred while executing a Transact-SQL statement or batch (Microsoft.SqlServer.ConnectionInfo) The transaction log for database MSSQL is full due to “LOG_BACKUP” (Microsoft Sql Server, Error 9002)
This means that the drive, where the SQL transaction log stored, is out of space and SQL cannot write a new transaction data. In this case, you can truncate SQL logs files manually (using the SQL query or from the Management Studio GUI).
When error 9002 occurs, all pending transactions are rolled back and SQL Server stops.
This situation typically occurs when using a Full recovery model. In this model, the log files cannot be cleared until all transactions are not present in the backup. It is necessary to ensure you are using a continuous log sequence number (LSN) in the log records. Accordingly, for the truncate, you need to make a full backup of the DB, or (easier and faster) temporarily switch it to Simple recovery mode. It is possible to change the recovery model of MS SQL Server on the fly, but to reduce the risks, it is desirable to switch the database into read-only mode and perform a backup of the transaction log (if it’s possible).
In order to truncate SQL transaction logs, open the SQL Server Management Studio (SSMS), select the desired database (with large transaction log), right click on it, and select Properties from the context menu. Go to Options and switch the database Recovery model to Simple.
Then, in the same context menu, go to section Tasks > Shrink > Files. In File type select Log, in File name field specify the name of the log file. In Shrink action choose Reorganize pages before releasing unused space, set the desired size of the file, and click OK.
You can find three shrink options here:
- Release unused space — this option will reclaim unused space in the transaction log file and shrink the file to the last allocated extent. Allows to reduce the file size without moving data;
- Reorganize pages before releasing unused space — reclaims unused space and tries to relocate rows to unallocated pages;
- Empty file by migrating the data to other files in the same filegroup — is used to move all data from the specified file to other files in the same filegroup. The empty file will be removed later.
After completing an operation, change the database Restore mode back to Full.
Проверить, сколько ядер используют MS SQL Server и 1С
Если у Вас мощный сервер — это еще не значит, что Вы используете его на полную мощность.
Причины у этого могут быть разные. Например, такое происходит, если при настройке окружения не учли ограничения MS SQL или приобрели не ту версию 1С.
Давайте разберем подробнее оба случая.
Проверить, сколько ядер используют MS SQL Server
Разные версии MS SQL имеют разные ограничения
Их важно учитывать при настройке окружения. Например, версия MS SQL Standard 2016 может использовать либо 4 сокета, либо 24 ядра, исходя из того, чего меньше (данные из таблицы на сайте Microsoft Ignite)
Рисунок 3. Ограничения разных версий MS SQL Server
Формулировка очень важна: выбирается именно меньшее, а не большее.
Допустим, у Вас есть многопроцессорный сервер, т. е. сервер с несколькими сокетами. На нем размещена виртуальная машина, на которую установлен сервер MS SQL. При этом в виртуальной машине настроено 12 процессоров по 2 ядра. Сколько ядер будет использовать MS SQL?
MS SQL будет использовать 4 процессора, следовательно, всего 8 ядер из 24. Остальные ядра будут не загружены. Правильным решением будет настроить на виртуальной машине 4 процессора по 6 ядер на каждом, либо 2 по 12 ядер. В этом случае MS SQL сможет использовать все 24 ядра.
Рисунок 4. Неправильная и правильная настройки процессоров. В схеме № 1 MS SQL использует только 4 процессора из 12, а в схеме № 2 — все 12
Вот пример неверной настройки, когда вместо 12 ядер в виртуальной машине было настроено 12 сокетов — по одному ядру на каждый сокет. Видно, что загружены только 4 ядра из 12.
Рисунок 5. Неравномерная загрузка ядер при неправильной настройке виртуальной машины
Чтобы узнать, сколько логических процессоров (ядра, в том числе и гиперпоточные) задействует Ваш экземпляр MS SQL, следует выполнить следующий запрос
select * from sys.dm_os_schedulers where status = ‘VISIBLE ONLINE’ and is_online = 1
Рисунок 6. Отображение реального количества логических процессоров, используемых MS SQL Server
Еще имеет смысл поискать в логах MS SQL сообщения следующего характера:
SQL Server detected 1 sockets with 4 cores per socket and 8 logical processors per socket, 8 total logical processors; using 8 logical processors based on SQL Server licensing. This is an informational message; no user action is required.
Из этого текста следует, что все хорошо — число найденных ядер равно числу используемых.
Но сообщение может быть иным, например:
SQL Server detected 4 sockets with 12 cores per socket and 12 logical processors per socket, 48 total logical processors; using 24 logical processors based on SQL Server licensing. This is an informational message; no user action is required.
В этом случае половина процессорных мощностей простаивает.
Найти такие сообщения в логах можно с помощью следующего запроса:
EXEC sys.xp_readerrorlog 0, 1, N’detected’, N’socket’;
Проверить, сколько ядер используют 1С
Важно помнить, что у 1С тоже есть ограничения по количеству используемых ядер. Например, версия ПРОФ может использовать только 12 ядер и, если поставить ее на 24-ядерный сервер, то половина процессорных мощностей будет простаивать
Если на сервере больше 12 ядер и Вы хотите, чтобы 1С использовала их все, необходимо приобрести версию КОРП.
Убрать лишнее
Этот способ ускорения системы заключается в том, чтобы отключить все, что не используется, но забирает ресурсы. Особенно это касается типовых конфигураций.
Кому-то покажется, что это совет от капитана Очевидность. Но стоит отбросить сарказм — есть множество баз, в которых работают все стандартные регламентные задания и оставлены настройки по умолчанию.
Проведите ревизию включенных регламентных заданий. Действительно ли все эти задания нужны? Может, часть относится к механизмам, которые Вы не используете?
Ситуация усугубляется, когда на сервере расположено большое количество баз: часть из них для разработки, часть — для тестов, еще часть кто-то когда-то зачем-то создал. В каждой из них выполняются задания, обновление полнотекстового поиска и т. д.
Все это никак не помогает производительности Вашей системы, поэтому стоит отключить все лишнее.
Первое, на что нужно обратить внимание при ревизии — это полнотекстовый поиск. Если он не используется, тогда лучше его отключить, чтобы он зря не «съедал» ресурсы системы
(нажмите, чтобы увеличить картинку)
Рисунок 11. Отключение полнотекстового поиска 1С
Если же полнотекстовый поиск используется, тогда стоит оставить свойство «Полнотекстовый поиск» в значении Использовать только для тех реквизитов, где он действительно необходим. У остальных объектов следует его отключить.
Шаг 4. Настройка Планов обслуживания (Maintenance Plans, Регламентных заданий)
Для работы регламентных заданий необходимо создать план обслуживания:
Итак, приведу свой пример настроенного Maintenance Plans с комментариями. Мой план состоит из 5 подпланов:
Первый подплан (ежедневное еженочное обслуживание сервера и резервных копий):
Данный подплан состоит из нескольких шагов. Связи зеленого цвета задают переход к следующему заданию при удачном завершении (т.е. без ошибок), связи синего цвета задают переход к следующему заданию при любом результате выполнения текущего. Параметры шагов видны на размещенных в редакторе заданиях. Параметры некоторых заданий нужно описать отдельно. Первым шагом выполняется «Проверка целостности базы данных» (Check Database Integrity Task), которая выполняется для всех баз системы и следующие задания выполняются только при отсутствии ошибок при проверке баз. Следующим шагом выполняется «Перестроение индексов баз данных» (Rebuild Index Task) для всех баз данных сервера. Данная процедура довольно ресурсоемкая, но в последствии ускоряет работу базы, т.к. если фрагментированость индексов > 25%, это резко снижает производительность сервера. Если размер баз не позволяет выполнять данную задачу, т.к. она занимает много времени, то рекомендуется делать данное действие хотябы раз в неделю, при этом, на ночные задания заменить задачу Перестроение индексов баз данных (Rebuild Index Task) на Дефрагментацию индекса (Reorganize Index Task), которая менее ресурсоемка. Далее происходит «Обновление статистики базы данных» (Update Statistics Task) для всех баз данных, опять же для оптимизации. После этого задания рекомендуется выполнить «Очистку процедурного кэша«:
При этом, запускается процедура
DBCC FREEPROCCACHE
После оптимизации работы желательно сделать резервную копию журналов транзакций. Этот шаг делать не обязательно, но желательно. Во время выполнения предыдущих шагов (Перестроение индексов баз данных (Rebuild Index Task) и Обновление статистики базы данных (Update Statistics Task)) файлы журналов вырастают примерно до размера базы данных, а то и более. В результате, в следующих подпланах при выполнении первого резервного копирования журнала транзакций, размер копии имеет довольно большой объем. Это может сильно увеличить вермя восстановления базы. Таким образом, делая копию логов до полной копии, мы избавляемся от данной проблемы. (спасибо за идею комментатору Kyoshiro)
Далее можно выполнить полный бэкап заданием Создание резервной копии базы данных (Back Up Database Task):
При выполнении данного задания копии складываются в сетевую папку на файловом сервере с расширением bak, при этом, для каждой базы создается своя папка:
SAMBA ~ # ls -1 /backup/full/ database1 database2 ... SAMBA ~ # ls -1 /backup/full/satabase1/ database1_backup_201111210250.bak database1_backup_201111220251.bak ...
После заверешения создания резервной копии параллельно запускается 3 задания: очистка резервных копий журналов транзакция (о создании таких копий — ниже) старее 5 дней, очистка полных бэкапов старее 1 недели и очистка истории старше 1 месяца (сюда входит в основном — очистка служебной информации MS SQL, такой как журналы):
Данный подплан у меня запускается каждую ночь в нерабочее время по будням:
Второй, третий, четвертый подплан (обновление статистики 3 раза в день):
Следующие 3 подплана одинаковы по содержимому и различаются лишь временем выполнения. Выполняются 3 раза в день — в 6, 13 и 19 часов:
Обновление статистики довольно ресурсоемкая задача, поэтому спланируйте ее выполнение в то время, когда база данных не сильно загружена.
Пятый подплан (резервное копирование журнала транзакций):
Данный план выполняет инкрементальное копирование транзакционного лога Microsoft SQL Server:
Копирование выполняется каждые пол часа в рабочее время и сохраняется в сеть с расширением trn:
После настройки данного плана мы имеем регулярное резервное копирование с необходимым регламентным обслуживанием, с хранением копий базы данных за последние 7 дней с возможностью восстановления базы интервалом до 30 минут.
Более подробно о выборе и планировании плана обслуживания можно посмотреть данный подкаст(временно убран по причине заражения сайта s.rpod.ru):
Набор подсистем «Умные таблицы»
Данный набор подсистем – прикладная библиотека, призванная помочь программисту 1С быстрее решать ряд типовых задач бизнес-логики, таких как: ведение статусов объектов, отправка почтовых сообщений в определенное время, ведение произвольных таблиц с возможностью редактирования, сохранения и группировки, ориентированные на расчет бюджетных таблиц (план продаж, ретробонусы B2C, проценты по договорам B2B и договорные условия по КАМ), расчет коммерческой политики для бюджетных таблиц, исполнение произвольных алгоритмов с хранением кода в информационной базе, определение рабочих баз, хранение файлов во внешних СУБД (Postgre SQL, MS SQL и MongoDB) и выполнение произвольного кода после изменений ссылочного объекта вне транзакции изменения.
1 стартмани
22.05.2017
47954
119
Silenser
34
75
Включить механизм версионирования в MS SQL для 8.2
Все еще много конфигураций работает в режиме совместимости с 8.2 или на самой платформе 8.2.
В управляемом режиме блокировок в 8.2 читающие запросы в транзакции устанавливают блокировки. Из-за этого при параллельной работе нескольких пользователей пишущие транзакции блокируют читающие, что приводит к излишним ожиданиям на блокировках.
Если у Вас такая конфигурация и в ней используется режим управляемых блокировок, необходимо обязательно в MS SQL включить режим версионирования READ_COMMITTED_SNAPSHOT.
Это можно сделать с помощью следующей команды:
ALTER DATABASE ИмяБазы SET READ_COMMITTED_SNAPSHOT ON
При этом в базе не должно быть пользователей, иначе команда не будет выполнена.
После выполнения команды поведение системы будет аналогично 8.3: читающие запросы в транзакции не будут блокировать данные, следовательно, количество ожиданий на блокировках сократится.
Проблема в том, что периодически, например при обновлении, платформа будет возвращать прежний режим. Необходимо постоянно следить за тем, чтобы данный режим был включен. Например, можно сделать регламентное задание на MS SQL, которое будет регулярно выполнять вышеприведенных запрос.
Manage Transaction Log Growth by taking Backups
If you have your database set to full or bulk-logged recovery mode, you need to periodically take transaction log backups to keep the transaction log from filling up. Depending on how you have your autogrowth setting for the transaction log, the log might just keep growing based on the FILEGROWTH and MAXSIZE setting. If you never take a take transaction log backups it might grow until it reaches the MAXSIZE setting or fills up the disk drive where the transaction log lives. To removed committed transaction log records from the log, all you need to do is take a transaction log backup.
To back up the transaction log you first need to make sure you have a full backup of the database. Once the full backup has been completed, a backup the transaction log can be taken, using a TSQL command similar to the backup command in Listing 4.
Listing 4: Transaction log backup command
|
1 |
BACKUPLOGMyDatabase TODISK=N’C:\MyBackups\MyDatabase.trn’ WITHNOFORMAT,NOINIT, NAME=N’MyDatabase Log Backup’,SKIP,NOREWIND,NOUNLOAD,STATS=10; GO |
Each time I run the backup command in Listing 4, a new transaction log backup will be added to the MyDatabase.trn file, and all inactive VLF’s will be removed from the transaction log. The frequency of taking transaction log backups depend on the amount of transactions performed against a database. The more updates performed, the more frequently you should run a transaction log backup. By running the transaction log frequently enough, you might be able to keep your transaction log from growing.
Monitoring the Transaction Log Usage
In order to monitor the size of the transaction log, the team at Microsoft have provided a dynamic view named “sys.dm_db_log_space_usage”. The code in Listing 5 shows how to use this view.
Listing 5: Showing how much used log space on master database
|
1 |
USEmaster; GO SELECT*FROMsys.dm_db_log_space_usage; |
When I run the command in Listing 5 on my instance, I get the output shown in Report 2.
Report 2: Amount of space used
By reviewing this report and looking at the used_log_space_in_percent column, you can see that just a little over 55% of my log space is used on my master database.
How to identify when an autogrowth Event Occurs
SQL Server creates an autogrowth event whenever a database file automatically grows. As of SQL Server 2005, the autogrowth events are included in the default trace. If you haven’t turned off the default trace, then the autogrowth events are simple to find, using SSMS or TSQL.
To view the autogrowth events in SSMS, right click on a database name in Object Explorer. In the context menu displayed, hover over the “Reports” item in the context menu, then move the mouse to hover over the “Standard Reports” and then select the “Disk Usage” report. Upon doing this for a database, a report similar to that shown in Report 3 will be displayed. To view the autogrowth events for the database selected, click on the “+” sign next to the “Data/Log Files Autogrowth/Autoshrink” item, as shown by the red arrow in Report 3.
Report 3: Disk Space Usage Report
Clicking the “+” sign displays any autogrowths if they have occurred. Report 3, shows the autogrowth events on my SampleDB database.
Report 3: Autogrowth events on SampleDB
In Report 3 you can see both Log and Data autogrowth events. Using the SSMS method will show you only autogrowth events in the active file of the default trace for one database. If you want to review autogrowth events for all databases on a server, regardless of whether it is in active file of the default trace or an any of the default trace rollover files you can use a script similar to the one in Listing 6.
Listing 6: Reviewing autogrowth events in the default trace file
|
1 |
DECLARE@filenameNVARCHAR(1000); DECLARE@bcINT; DECLARE@ecINT; DECLARE@bfnVARCHAR(1000); DECLARE@efnVARCHAR(10); — Get the name of the current default trace SELECT@filename=CAST(valueASNVARCHAR(1000)) FROM::fn_trace_getinfo(DEFAULT) WHEREtraceid=1ANDproperty=2; — rip apart file name into pieces SET@filename=REVERSE(@filename); SET@bc=CHARINDEX(‘.’,@filename); SET@ec=CHARINDEX(‘_’,@filename)+1; SET@efn=REVERSE(SUBSTRING(@filename,1,@bc)); SET@bfn=REVERSE(SUBSTRING(@filename,@ec,LEN(@filename))); — set filename without rollover number SET@filename=@bfn+@efn — process all trace files SELECT ftg.StartTime ,te.nameASEventName ,DB_NAME(ftg.databaseid)ASDatabaseName ,ftg.Filename ,(ftg.IntegerData*8)1024.0ASGrowthMB ,(ftg.duration1000)ASDurMS FROM::fn_trace_gettable(@filename,DEFAULT)ASftg INNERJOINsys.trace_eventsASteONftg.EventClass=te.trace_event_id WHERE(ftg.EventClass=92— Date File Autogrow ORftg.EventClass=93)— Log File Autogrow ORDERBYftg.StartTime |
Knowing when, how often, and which databases have had autogrowth event occurs will help you identify when each database is growing. You can then use these time frames to determine which processes are causing your transactions logs to grow.
Как проверить журнал транзакций SQL Server с помощью интеллектуального решения?
Для эффективного открытия файла журнала и анализа всех транзакций, таких как вставка, обновление и удаление. Для этого загрузите Анализатор журналов SQL что позволяет пользователям восстанавливать измененную базу данных.
Лучшее в этом инструменте — то, что он может помочь узнать, кто изменил записи таблицы, и возможность быстрого сканирования для глубокого изучения файла журнала. Также вы можете открывать и анализировать все операции, не устанавливая MS SQL Server.
Приступим к работе с этим инструментом.
Как инструмент помогает проверить журнал транзакций SQL Server?
1. Запустите инструмент и щелкните значок Открыть кнопку, чтобы вставить файлы в панель программного обеспечения.
2. Выберите Онлайн БД вариант и выберите Имя сервера из списка или введите его. Выберите Тип аутентификации и ударил ОК.
3. Отметьте таблицы, которые вы хотите проанализировать, и нажмите на Экспорт кнопка.
4. Выберите Вставлять, Обновлять, и / или Удалить варианты и применить Дата-фильтры.
5. Перейти к База данных SQL Server в Экспорт в / как поле. Введите необходимую информацию в Учетные данные базы данных вариант.
6. Задайте место назначения или Создать новую базу данных и ударил Экспорт чтобы узнать, как проверить журнал транзакций SQL Server.
В Дата-фильтр опция позволяет пользователям выбрать определенный период времени, указав даты от и до. Программа принимает данные из указанного часового пояса и экспортирует только выборочные данные.
Это самый простой способ открытия файлов журналов среди всех остальных. Если пользователи хотят проверить бесплатные методы, перейдите к следующему способу.
Ручной метод открытия файлов журнала с помощью fn_dblog ()
Эта функция может использоваться в целях криминалистики для извлечения данных из файлов транзакций для их тщательного анализа. Пользователи могут применять эту функцию в версиях SQL 2005, 2008 R2 до 2017 для проверки журнала транзакций SQL Server. Ниже приведены шаги для этой функции:
1. Здесь вы должны просмотреть записи, используя T-SQL и использовать Обновлять команда.
2. Выберите Выбирать запрос для просмотра значений таблицы.
3. После этого вы можете увидеть измененные данные.
4. Затем запустите fn_dblog () функционировать согласно вашим требованиям.
5. Теперь вы можете просмотреть все детали внесенных изменений в журнал на вашем дисплее.
Несмотря на то, что этот метод выполняется всего за несколько шагов, он может отображать только время внесенных изменений и может стать сложным и длительным процессом.
Как проверить журнал транзакций службы SQL с помощью альтернативного ручного метода?
С помощью этого подхода пользователи могут сделать видимыми только некоторые детали из файла журнала. К ним относятся сбор аудита, история заданий, SQL Server, почта базы данных, сбор данных, события Windows и агент SQL Server.
Теперь перейдем к рабочим этапам этой техники:
1. Прежде всего откройте приложение SQL Server Management Studio, чтобы запустить этот процесс.
2. После этого перейдите в Подключиться к серверу окно и заполните детали в Имя сервера а также Аутентификация поля.
3. Нажмите Соединять после заполнения данных и переходите к проверке журнала транзакций SQL Server.
4. На этом шаге перейдите к Обозреватель объектов окно и выберите Управление вариант.
5. Там выберите Журналы SQL Server вариант из расширенного меню.
6. Теперь щелкните правой кнопкой мыши Журналы SQL Server возможность открыть другой расширенный список и нажать Вид.
7. Здесь выберите Журнал SQL Server кнопку из меню.
8. Наконец, вы сможете увидеть журналы на Окно просмотра файлов журнала.
Время и личность пользователя, который внес изменения, с помощью этого метода не раскрываются.
Это должно быть все
Важно знать, как проверять журнал транзакций SQL Server, поскольку данные, хранящиеся в файлах, могут сказать вам, была ли какая-либо операция, не связанная с информацией. Непросто проанализировать файлы, если у вас нет необходимых технических знаний для применения ручных методов
Тем не менее, вы можете использовать описанное здесь программное обеспечение, чтобы выполнить ту же задачу без каких-либо технических знаний и завершить процесс за считанные минуты.
Управление устойчивостью транзакций
Управление на уровне базы данных
Администратор базы данных управляет тем, могут ли пользователи использовать отложенные устойчивые транзакции в базе данных, с помощью следующей инструкции. Необходимо использовать для настройки параметра отложенной устойчивости инструкцию ALTER DATABASE.
ВЫКЛЮЧЕНО
При использовании этой настройки все фиксируемые в базе данных транзакции являются полностью устойчивыми независимо от настроек уровня фиксации (DELAYED_DURABILITY= ). Изменение и повторная компиляция хранимых процедур не требуются. Это позволяет гарантировать, что данные не будут подвергаться рискам из-за отложенной устойчивости.
РАЗРЕШЕНО
При использовании этой настройки устойчивость каждой транзакции определяется на уровне транзакций — DELAYED_DURABILITY = { OFF | ON }. Дополнительные сведения см. в разделах и .
ПРИНУДИТЕЛЬНО
Если выбран этот параметр, все транзакции, которые фиксируются в базе данных, являются отложенными устойчивыми. Независимо от того, указана ли транзакция как полностью устойчивая (DELAYED_DURABILITY = OFF) или данные не указаны, транзакция является отложенной устойчивой. Этот параметр полезен, если отложенная устойчивая транзакция используется для баз данных и не следует изменять код приложения.
Управление на уровне блока Atomic — скомпилированные в собственном коде хранимые процедуры
Ниже представлен код блока ATOMIC.
OFF
Транзакция является полностью устойчивой, пока действует параметр базы данных DELAYED_DURABLITY = FORCED, в этом случае фиксация является асинхронной и таким образом, устойчивой. Подробнее см. в разделе .
ON
Транзакция является устойчиво отложенной, пока действует параметр базы данных DELAYED_DURABLITY = DISABLED, в этом случае фиксация является синхронной и таким образом, полностью устойчивой. Подробнее см. в разделе .
Пример кода
Таблица 1: Устойчивость в блоках ATOMIC
| Параметр устойчивости блоков ATOMIC | Отсутствие существующих транзакций | Транзакция обрабатывается (полностью или отложенная устойчивая) |
|---|---|---|
| DELAYED_DURABILITY = OFF | Блок ATOMIC инициирует новую полностью устойчивую транзакцию. | Блок ATOMIC создает точку сохранения в существующей транзакции, а затем начинает новую транзакцию. |
| DELAYED_DURABILITY = ON | Блок ATOMIC инициирует новую отложенную устойчивую транзакцию. | Блок ATOMIC создает точку сохранения в существующей транзакции, а затем начинает новую транзакцию. |
Управление на уровне ФИКСАЦИИ — Transact-SQL
Синтаксис фиксации расширен, что обеспечивает возможность принудительной реализации отложенной устойчивости транзакций. Если для DELAYED_DURABILITY задано DISABLED или FORCED на уровне базы данных (см. выше), то этот параметр фиксации не учитывается.
OFF
Фиксация транзакции является полностью устойчивой за исключением случаев, когда применяется параметр базы данных DELAYED_DURABLITY = FORCED, в этом случае фиксация является асинхронной и, следовательно, отложенной устойчивой. Подробнее см. в разделе .
ON
Фиксация транзакции является отложенной устойчивой за исключением случаев, когда применяется параметр базы данных DELAYED_DURABLITY = DISABLED, в этом случае фиксация является синхронной и, следовательно, полностью устойчивой. Подробнее см. в разделе .
Краткое описание параметров и их взаимодействий
В следующей таблице перечислены взаимодействия параметров отложенной устойчивости на уровне базы данных и параметров на уровне фиксации. Параметры уровня базы данных всегда имеют более высокий приоритет, чем параметры уровня фиксации.
| Параметр фиксации/параметр базы данных | DELAYED_DURABILITY = DISABLED | DELAYED_DURABILITY = ALLOWED | DELAYED_DURABILITY = FORCED |
|---|---|---|---|
| DELAYED_DURABILITY = OFF Транзакции на уровне базы данных. | Транзакция является полностью устойчивой. | Транзакция является полностью устойчивой. | Транзакция является отложенной устойчивой. |
| DELAYED_DURABILITY = ON Транзакции на уровне базы данных. | Транзакция является полностью устойчивой. | Транзакция является отложенной устойчивой. | Транзакция является отложенной устойчивой. |
| DELAYED_DURABILITY = OFF Межбазовая или распределенная транзакция. | Транзакция является полностью устойчивой. | Транзакция является полностью устойчивой. | Транзакция является полностью устойчивой. |
| DELAYED_DURABILITY = ON Межбазовая или распределенная транзакция. | Транзакция является полностью устойчивой. | Транзакция является полностью устойчивой. | Транзакция является полностью устойчивой. |
Проверить настройку Turbo Boost
Для сервера 1С критически важна частота процессора — чем она выше, тем лучше.
В большинстве процессоров есть возможность динамически менять частоту в зависимости от нагрузки — это позволяет процессору работать на частоте выше номинальной. У Intel такая технология называется Turbo Boost, у AMD — Turbo Core.
Рисунок 7. Схема работы технологии Turbo Boost
Turbo Boost включается в BIOS, но чтобы он полноценно работал, необходимо в настройках электропитания операционной системы установить режим электропитания Высокая производительность. Если этого не сделать, ОС будет занижать частоту процессора для экономии электричества.
Рисунок 8. Установка режима электропитания
If you don’t care about point-in-time recovery
If this is a test database, and you don’t care about point-in-time recovery, then you should make sure that your database is in SIMPLE recovery mode.
Putting the database in SIMPLE recovery mode will make sure that SQL Server re-uses portions of the log file (essentially phasing out inactive transactions) instead of growing to keep a record of all transactions (like FULL recovery does until you back up the log). CHECKPOINT events will help control the log and make sure that it doesn’t need to grow unless you generate a lot of t-log activity between CHECKPOINT s.
Next, you should make absolute sure that this log growth was truly due to an abnormal event (say, an annual spring cleaning or rebuilding your biggest indexes), and not due to normal, everyday usage. If you shrink the log file to a ridiculously small size, and SQL Server just has to grow it again to accommodate your normal activity, what did you gain? Were you able to make use of that disk space you freed up only temporarily? If you need an immediate fix, then you can run the following:
Otherwise, set an appropriate size and growth rate. As per the example in the point-in-time recovery case, you can use the same code and logic to determine what file size is appropriate and set reasonable autogrowth parameters.
если вы заботитесь о восстановлении точки во времени
(и под моментальным восстановлением я имею в виду, что вы заботитесь о том, чтобы восстановить что-либо, кроме полной или дифференциальной резервной копии.)
предположительно ваша база данных находится в FULL режим восстановления. Если нет, то убедитесь, что он:
даже если вы принимаете регулярные полные резервные копии, файл журнала будет расти и расти, пока вы не выполните log резервное копирование — это для вашей защиты, а не для того, чтобы напрасно съедать ваше дисковое пространство. Вы должны выполнять эти резервные копии журналов довольно часто, в соответствии с вашими целями восстановления. Например, если у вас есть бизнес-правило, которое гласит, что вы можете позволить себе потерять не более 15 минут данных в случае катастрофы, у вас должно быть задание, которое создает резервную копию журнала каждые 15 минут. Вот сценарий, который будет генерировать имена файлов с отметками времени на основе текущего времени (но вы также можете сделать это с помощью планы обслуживания и т. д., просто не выбирайте ни один из вариантов сокращения в планах обслуживания, они ужасны).
отметим, что \backup_share\ должно быть на другом компьютере, который представляет собой другое базовое устройство хранения. Поддерживает до той же машине (или на другой машине, который использует тот же базовый дисков, или другой ВМ на одном физическом узле) на самом деле не помочь вам, поскольку если машина взрывается, вы потеряли свою базу и резервное копирование. В зависимости от вашей сетевой инфраструктуры может иметь смысл создавать резервные копии локально, а затем переносить их в другое место за кулисами; в любом случае вы хотите как можно быстрее удалить их с основного компьютера базы данных.
теперь, когда у вас есть регулярные резервные копии журналов, следует разумно сжать файл журнала до чего-то более разумного, чем то, что он взорван до сих пор. Это делает не значит бег!—8—> снова и снова, пока файл журнала не будет 1 мб — даже если вы часто резервное копирование журнала, он по-прежнему должен учитывать сумму любых параллельных транзакций, которые могут произойти. События автозапуска файла журнала дороги, так как SQL Server должен обнулить файлы (в отличие от файлов данных, когда включена мгновенная инициализация файла), и пользовательские транзакции должны ждать, пока это произойдет. Вы хотите делать эту процедуру расти-сокращаться-расти-сокращаться как можно меньше, и вы, конечно, не хочу, чтобы ваши пользователи платили за это.
обратите внимание, что вам может потребоваться резервное копирование журнала дважды, прежде чем возможно сокращение (спасибо Роберт)