При обновлении бухгалтерии, на этапе сохранения, получил следующую ошибку:
Каталог не обнаружен ‘v8srvr://sql/acc_main/configsave/e0666db2-45d6-49b4-a200-061c6ba7d569.6b9d6525-ee94-4e13-b73d-82d3e8e8441d’
по причине: Каталог не обнаружен ‘ConfigSavee0666db2-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 — название базы Бух)
Код SQL
USE acc_main
ALTER DATABASE acc_main SET RECOVERY SIMPLE
DBCC SHRINKFILE (acc_main, 50);
ALTER DATABASE acc_main SET RECOVERY FULL
Результат выполнения:
Тоже самое можно сделать вручную:
Шаг 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 — имя базы данных):
Код SQL
BACKUP LOG BaseDB TO DISK = '<D:BackupBase_Log.trn'
DBCC SHRINKFILE (BaseDB_Log, 20) WITH NO_INFOMSGS
Все
Содержание:
1. Журнал транзакций в 1С
2. Ошибка Журнал транзакций переполнен
1. Журнал транзакций в 1С
В данной статье будет описана возможная ошибка в системе 1С, а именно – в СУБД, которая связана с переполнением журнала транзакций в 1С. Далее будут приведены возможные методы устранения данной неполадки, среди которых уменьшение журнала транзакций для базы данных.
Сначала следует выяснить, что такое журнал транзакций в 1С. Журнал транзакций является одной из основных составляющих в базе данных. При помощи журнала транзакций для базы данных создаётся резервная копия, которая в случае сбоя системы вернёт базу в нужное состояние, которое изначально было согласовано.
При помощи журнала транзакций можно выполнить такие действия:
1. Восстановление транзакций;
2. Восстановление транзакций, которые не были окончены;
3. Поддерживать повторения транзакций;
4. Производить восстановление базы данных, из-за системного сбоя.
2. Ошибка Журнал транзакций переполнен
В СУБД 1С может появляться ошибка, которая содержит следующий текст: «Журнал транзакций для базы данных «zup» заполнен». Также, в тексте ошибки может приводиться столбец и таблица, к которым следует обратиться.
Такая ошибка возникает в тех случаях, когда в журнале транзакций находится слишком много данных, то есть, он переполнен.
Рассмотрим два возможных способа для устранения ошибки «Журнал транзакций для базы данных переполнен»:
· В первом способе будем следовать такому алгоритму:
1. Проверить наличие и величину свободного места на дисках, в случае, когда места нет – соответственно, нет места и для записи лога;
2. Если место есть, то ошибка «Журнал транзакций для базы переполнен» является ошибкой MicrosoftSQLServer, то есть – лог с транзакциями был полностью заполнен, но не очищен. Это можно исправить при помощи очистки, которая является стандартной, но эта опция не всегда может помочь устранить неполадку. В случае, если она не сработала – стоит использовать следующий код SQLServer:
код SQLServer
В данном коде: 20 – это величина лога в Мб, а «myDataBase» — название нужной базы с данными.
· Следующий способ – это сразу приступить к уменьшению размера журнала с транзакциями.
Так как с журналом транзакций в SQLServer часто проводится много довольно весомых манипуляций, которые связаны с модификацией данных в СУБД, то такие действия приводят к увеличению размеров файловых данных внутри журнала с транзакциями. В данном случае очень важно вовремя удалять не нужные записи из журнала транзакций SQL, в связи с созданием более актуальных. Если не проводить удаления вовремя, то прошлые файлы в журнале транзакций начинают заполнять всё место на диске и далее станет невозможно работать с СУБД.
Так что, в своём роде, данный способ – это предотвращение ошибки «Журнал транзакций переполнен» в 1С.
В таком случае, удаляем те записи, которые больше не нужны, при помощи команды «BACKUPLOG», следующий шаг – это сделать меньше файл из журнала транзакций MSSQL– при помощи команды «DBCCSHRINKFILE». Таким образом, нужный нам код, для предотвращения ошибки, будет выглядеть таким образом:
Предотвращение ошибки Журнал транзакций переполнен
В данной статье были приведены общие данные о том, что такое журнал транзакций, а также проведена диагностика ошибки «Журнал транзакций переполнен» в 1С. Далее было описано, как устранить данную ошибку и дан способ для предотвращения данной неполадки.
Специалист компании «Кодерлайн»
Айдар Фархутдинов
title | description | author | ms.author | ms.date | ms.service | ms.subservice | ms.topic | helpviewer_keywords | |||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Troubleshoot full transaction log error 9002 |
Learn about possible responses to a full transaction log in SQL Server and how to avoid the problem in the future. |
MashaMSFT |
mathoma |
09/14/2021 |
sql |
supportability |
troubleshooting |
|
[!INCLUDE SQL Server]
Option 1: Run the steps directly in an executable notebook via Azure Data Studio
[!NOTE]
Before attempting to open this notebook, check that Azure Data Studio is installed on your local machine. To install, go to Learn how to install Azure Data Studio.
[!div class=»nextstepaction»]
Open Notebook in Azure Data Studio
Option 2: Follow the step manually
This topic discusses possible responses to a full transaction log and suggests how to avoid it in the future.
When the transaction log becomes full, [!INCLUDEssDEnoversion] issues a 9002 error. The log can fill when the database is online, or in recovery. If the log fills while the database is online, the database remains online but can only be read, not updated. If the log fills during recovery, the [!INCLUDEssDE] marks the database as RESOURCE PENDING. In either case, user action is required to make log space available.
[!NOTE]
This article is focused on SQL Server. For more specific information on this error in Azure SQL Database and Azure SQL Managed Instance, see Troubleshooting transaction log errors with Azure SQL Database and Azure SQL Managed Instance. Azure SQL Database and Azure SQL Managed Instance are based on the latest stable version of the Microsoft SQL Server database engine, so much of the content is similar though troubleshooting options and tools may differ.
Common reasons for a full transaction log
The appropriate response to a full transaction log depends on what conditions caused the log to fill. Common causes include:
- Log not being truncated
- Disk volume is full
- Log size is set to a fixed maximum value or autogrow is disabled
- Replication or availability group synchronization that is unable to complete
How to resolve a full transaction log
The following specific steps will help you find the reason for a full transaction log and resolve the issue.
1. Truncate the Log
A very common solution to this problem is to ensure transaction log backups are performed for your database which will ensure the log is truncated. If no recent transaction log history is indicated for the database with a full transaction log, the solution to the problem is straightforward: resume regular transaction log backups of the database.
Log truncation explained
There’s a difference between truncating a transaction log and shrinking a transaction log. Log Truncation occurs normally during a transaction log backup, and is a logical operation which removes committed records inside the log, whereas log shrinking reclaims physical space on the file system by reducing the file size. Log truncation occurs on a virtual-log-file (VLF) boundary, and a log file may contain many VLFs. A log file can be shrunk only if there’s empty space inside the log file to reclaim. Shrinking a log file alone can’t solve the problem of a full log file, instead, you must discover why the log file is full and can’t be truncated.
[!WARNING]
Data that is moved to shrink a file can be scattered to any available location in the file. This causes index fragmentation and might slow the performance of queries that search a range of the index. To eliminate the fragmentation, consider rebuilding the indexes on the file after shrinking. For more information, see Shrink a database.
What is preventing log truncation?
To discover what is preventing log truncation in a given case, use the log_reuse_wait
and log_reuse_wait_desc
columns of the sys.databases
catalog view. For more information, see sys.databases (Transact-SQL). For descriptions of factors that can delay log truncation, see The Transaction Log (SQL Server).
The following set of T-SQL commands will help you identify if a database transaction log isn’t truncated and the reason for it. The following script will also recommend steps to resolve the issue:
SET NOCOUNT ON DECLARE @SQL VARCHAR (8000), @log_reuse_wait tinyint, @log_reuse_wait_desc nvarchar(120), @dbname sysname, @database_id int, @recovery_model_desc varchar (24) IF ( OBJECT_id (N'tempdb..#CannotTruncateLog_Db') is not null) BEGIN DROP TABLE #CannotTruncateLog_Db END --get info about transaction logs in each db. Use a DMV which supports all supported versions IF ( OBJECT_id (N'tempdb..#dm_db_log_space_usage') is not null) BEGIN DROP TABLE #dm_db_log_space_usage END SELECT * INTO #dm_db_log_space_usage FROM sys.dm_db_log_space_usage where 1=0 DECLARE log_space CURSOR FOR SELECT NAME FROM sys.databases OPEN log_space FETCH NEXT FROM log_space into @dbname WHILE @@FETCH_STATUS = 0 BEGIN set @SQL = ' insert into #dm_db_log_space_usage ( database_id, total_log_size_in_bytes, used_log_space_in_bytes, used_log_space_in_percent, log_space_in_bytes_since_last_backup ) select database_id, total_log_size_in_bytes, used_log_space_in_bytes, used_log_space_in_percent, log_space_in_bytes_since_last_backup from ' + @dbname +'.sys.dm_db_log_space_usage' BEGIN TRY exec (@SQL) END TRY BEGIN CATCH SELECT ERROR_MESSAGE() AS ErrorMessage; END CATCH; FETCH NEXT FROM log_space into @dbname END CLOSE log_space DEALLOCATE log_space --select the affected databases SELECT sdb.name as DbName, sdb.log_reuse_wait, sdb.log_reuse_wait_desc, log_reuse_wait_explanation = CASE WHEN log_reuse_wait = 1 THEN 'No checkpoint has occurred since the last log truncation, or the head of the log has not yet moved beyond' WHEN log_reuse_wait = 2 THEN 'A log backup is required before the transaction log can be truncated.' WHEN log_reuse_wait = 3 THEN 'A data backup or a restore is in progress (all recovery models). Please wait or cancel backup' WHEN log_reuse_wait = 4 THEN 'A long-running active transaction or a defferred transaction is keeping log from being truncated. You can attempt a log backup to free space or complete/rollback long transaction' WHEN log_reuse_wait = 5 THEN 'Database mirroring is paused, or under high-performance mode, the mirror database is significantly behind the principal database. (Full recovery model only)' WHEN log_reuse_wait = 6 THEN 'During transactional replication, transactions relevant to the publications are still undelivered to the distribution database. Investigate the status of agents involved in replication or Changed Data Capture (CDC). (Full recovery model only.)' WHEN log_reuse_wait = 7 THEN 'A database snapshot is being created. This is a routine, and typically brief, cause of delayed log truncation.' WHEN log_reuse_wait = 8 THEN 'A transaction log scan is occurring. This is a routine, and typically a brief cause of delayed log truncation.' WHEN log_reuse_wait = 9 THEN 'A secondary replica of an availability group is applying transaction log records of this database to a corresponding secondary database. (Full recovery model only.)' WHEN log_reuse_wait = 13 THEN 'If a database is configured to use indirect checkpoints, the oldest page on the database might be older than the checkpoint log sequence number (LSN).' WHEN log_reuse_wait = 16 THEN 'An In-Memory OLTP checkpoint has not occurred since the last log truncation, or the head of the log has not yet moved beyond a VLF.' ELSE 'None' END, sdb.database_id, sdb.recovery_model_desc, lsu.used_log_space_in_bytes/1024 as Used_log_size_MB, lsu.total_log_size_in_bytes /1024 as Total_log_size_MB, 100 - lsu.used_log_space_in_percent as Percent_Free_Space INTO #CannotTruncateLog_Db FROM sys.databases AS sdb INNER JOIN #dm_db_log_space_usage lsu ON sdb.database_id = lsu.database_id WHERE log_reuse_wait > 0 SELECT * FROM #CannotTruncateLog_Db DECLARE no_truncate_db CURSOR FOR SELECT log_reuse_wait, log_reuse_wait_desc, DbName, database_id, recovery_model_desc FROM #CannotTruncateLog_Db; OPEN no_truncate_db FETCH NEXT FROM no_truncate_db into @log_reuse_wait, @log_reuse_wait_desc, @dbname, @database_id, @recovery_model_desc WHILE @@FETCH_STATUS = 0 BEGIN if (@log_reuse_wait > 0) select '-- ''' + @dbname + ''' database has log_reuse_wait = ' + @log_reuse_wait_desc + ' --' as 'Individual Database Report' if (@log_reuse_wait = 1) BEGIN select 'Consider running the checkpoint command to attempt resolving this issue or further t-shooting may be required on the checkpoint process. Also, examine the log for active VLFs at the end of file' as Recommendation select 'USE ''' + @dbname+ '''; CHECKPOINT' as CheckpointCommand select 'select * from sys.dm_db_log_info(' + CONVERT(varchar,@database_id)+ ')' as VLF_LogInfo END else if (@log_reuse_wait = 2) BEGIN select 'Is '+ @recovery_model_desc +' recovery model the intended choice for ''' + @dbname+ ''' database? Review recovery models and determine if you need to change it. https://learn.microsoft.com/sql/relational-databases/backup-restore/recovery-models-sql-server' as RecoveryModelChoice select 'To truncate the log consider performing a transaction log backup on database ''' + @dbname+ ''' which is in ' + @recovery_model_desc +' recovery model. Be mindful of any existing log backup chains that could be broken' as Recommendation select 'BACKUP LOG [' + @dbname + '] TO DISK = ''some_volume:some_folder' + @dbname + '_LOG.trn ''' as BackupLogCommand END else if (@log_reuse_wait = 3) BEGIN select 'Either wait for or cancel any active backups currently running for database ''' +@dbname+ '''. To check for backups, run this command:' as Recommendation select 'select * from sys.dm_exec_requests where command like ''backup%'' or command like ''restore%''' as FindBackupOrRestore END else if (@log_reuse_wait = 4) BEGIN select 'Active transactions currently running for database ''' +@dbname+ '''. To check for active transactions, run these commands:' as Recommendation select 'DBCC OPENTRAN (''' +@dbname+ ''')' as FindOpenTran select 'select database_id, db_name(database_id) dbname, database_transaction_begin_time, database_transaction_state, database_transaction_log_record_count, database_transaction_log_bytes_used, database_transaction_begin_lsn, stran.session_id from sys.dm_tran_database_transactions dbtran left outer join sys.dm_tran_session_transactions stran on dbtran.transaction_id = stran.transaction_id where database_id = ' + CONVERT(varchar, @database_id) as FindOpenTransAndSession END else if (@log_reuse_wait = 5) BEGIN select 'Database Mirroring for database ''' +@dbname+ ''' is behind on synchronization. To check the state of DBM, run the commands below:' as Recommendation select 'select db_name(database_id), mirroring_state_desc, mirroring_role_desc, mirroring_safety_level_desc from sys.database_mirroring where mirroring_guid is not null and mirroring_state <> 4 and database_id = ' + convert(sysname, @database_id) as CheckMirroringStatus select 'Database Mirroring for database ''' +@dbname+ ''' may be behind: check unsent_log, send_rate, unrestored_log, recovery_rate, average_delay in this output' as Recommendation select 'exec msdb.sys.sp_dbmmonitoraddmonitoring 1; exec msdb.sys.sp_dbmmonitorresults ''' + @dbname+ ''', 5, 0; waitfor delay ''00:01:01''; exec msdb.sys.sp_dbmmonitorresults ''' + @dbname+ '''; exec msdb.sys.sp_dbmmonitordropmonitoring' as CheckMirroringStatusAnd END else if (@log_reuse_wait = 6) BEGIN select 'Replication transactions still undelivered from publisher database ''' +@dbname+ ''' to Distribution database. Check the oldest non-distributed replication transaction. Also check if the Log Reader Agent is running and if it has encoutered any errors' as Recommendation select 'DBCC OPENTRAN (''' + @dbname + ''')' as CheckOldestNonDistributedTran select 'select top 5 * from distribution..MSlogreader_history where runstatus in (6, 5) or error_id <> 0 and agent_id = find_in_mslogreader_agents_table order by time desc ' as LogReaderAgentState END else if (@log_reuse_wait = 9) BEGIN select 'Always On transactions still undelivered from primary database ''' +@dbname+ ''' to Secondary replicas. Check the Health of AG nodes and if there is latency is Log block movement to Secondaries' as Recommendation select 'select availability_group=cast(ag.name as varchar(30)), primary_replica=cast(ags.primary_replica as varchar(30)),primary_recovery_health_desc=cast(ags.primary_recovery_health_desc as varchar(30)), synchronization_health_desc=cast(ags.synchronization_health_desc as varchar(30)),ag.failure_condition_level, ag.health_check_timeout, automated_backup_preference_desc=cast(ag.automated_backup_preference_desc as varchar(10)) from sys.availability_groups ag join sys.dm_hadr_availability_group_states ags on ag.group_id=ags.group_id' as CheckAGHealth select 'SELECT group_name=cast(arc.group_name as varchar(30)), replica_server_name=cast(arc.replica_server_name as varchar(30)), node_name=cast(arc.node_name as varchar(30)),role_desc=cast(ars.role_desc as varchar(30)), ar.availability_mode_Desc, operational_state_desc=cast(ars.operational_state_desc as varchar(30)), connected_state_desc=cast(ars.connected_state_desc as varchar(30)), recovery_health_desc=cast(ars.recovery_health_desc as varchar(30)), synchronization_health_desc=cast(ars.synchronization_health_desc as varchar(30)), ars.last_connect_error_number, last_connect_error_description=cast(ars.last_connect_error_description as varchar(30)), ars.last_connect_error_timestamp, primary_role_allow_connections_desc=cast(ar.primary_role_allow_connections_desc as varchar(30)) from sys.dm_hadr_availability_replica_cluster_nodes arc join sys.dm_hadr_availability_replica_cluster_states arcs on arc.replica_server_name=arcs.replica_server_name join sys.dm_hadr_availability_replica_states ars on arcs.replica_id=ars.replica_id join sys.availability_replicas ar on ars.replica_id=ar.replica_id join sys.availability_groups ag on ag.group_id = arcs.group_id and ag.name = arc.group_name ORDER BY cast(arc.group_name as varchar(30)), cast(ars.role_desc as varchar(30))' as CheckReplicaHealth select 'select database_name=cast(drcs.database_name as varchar(30)), drs.database_id, drs.group_id, drs.replica_id, drs.is_local,drcs.is_failover_ready,drcs.is_pending_secondary_suspend, drcs.is_database_joined, drs.is_suspended, drs.is_commit_participant, suspend_reason_desc=cast(drs.suspend_reason_desc as varchar(30)), synchronization_state_desc=cast(drs.synchronization_state_desc as varchar(30)), synchronization_health_desc=cast(drs.synchronization_health_desc as varchar(30)), database_state_desc=cast(drs.database_state_desc as varchar(30)), drs.last_sent_lsn, drs.last_sent_time, drs.last_received_lsn, drs.last_received_time, drs.last_hardened_lsn, drs.last_hardened_time,drs.last_redone_lsn, drs.last_redone_time, drs.log_send_queue_size, drs.log_send_rate, drs.redo_queue_size, drs.redo_rate, drs.filestream_send_rate, drs.end_of_log_lsn, drs.last_commit_lsn, drs.last_commit_time, drs.low_water_mark_for_ghosts, drs.recovery_lsn, drs.truncation_lsn, pr.file_id, pr.error_type, pr.page_id, pr.page_status, pr.modification_time from sys.dm_hadr_database_replica_cluster_states drcs join sys.dm_hadr_database_replica_states drs on drcs.replica_id=drs.replica_id and drcs.group_database_id=drs.group_database_id left outer join sys.dm_hadr_auto_page_repair pr on drs.database_id=pr.database_id order by drs.database_id' as LogMovementHealth select 'For more information see https://learn.microsoft.com/troubleshoot/sql/availability-groups/error-9002-transaction-log-large' as OnlineDOCResource END else if (@log_reuse_wait in (10, 11, 12, 14)) BEGIN select 'This state is not documented and is expected to be rare and short-lived' as Recommendation END else if (@log_reuse_wait = 13) BEGIN select 'The oldest page on the database might be older than the checkpoint log sequence number (LSN). In this case, the oldest page can delay log truncation.' as Finding select 'This state should be short-lived, but if you find it is taking a long time, you can consider disabling Indirect Checkpoint temporarily' as Recommendation select 'ALTER DATABASE [' +@dbname+ '] SET TARGET_RECOVERY_TIME = 0 SECONDS' as DisableIndirectCheckpointTemporarily END else if (@log_reuse_wait = 16) BEGIN select 'For memory-optimized tables, an automatic checkpoint is taken when transaction log file becomes bigger than 1.5 GB since the last checkpoint (includes both disk-based and memory-optimized tables)' as Finding select 'Review https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/' as ReviewBlog select 'use ' +@dbname+ ' CHECKPOINT' as RunCheckpoint END FETCH NEXT FROM no_truncate_db into @log_reuse_wait, @log_reuse_wait_desc, @dbname, @database_id, @recovery_model_desc END CLOSE no_truncate_db DEALLOCATE no_truncate_db
[!IMPORTANT]
If the database was in recovery when the 9002 error occurred, after resolving the problem, recover the database by using ALTER DATABASE database_name SET ONLINE.
LOG_BACKUP log_reuse_wait
The most common actions you can consider here is to review your database recovery model and backup the transaction log of your database.
Consider the database’s recovery model
The transaction log may be failing to truncate with LOG_BACKUP log_reuse_wait category, because you have never backed it up. In many of those cases, your database is using FULL or BULK_LOGGED recovery model, but you did not back up transaction logs. You should consider each database recovery model carefully: perform transaction log backups on all databases in FULL or BULK LOGGED recovery models to minimize occurrences of error 9002. For more information, see Recovery Models.
Back up the log
Under the FULL or BULK_LOGGED recovery model, if the transaction log has not been backed up recently, backup might be what is preventing log truncation. You must back up the transaction log to allow log records to be released and the log truncated. If the log has never been backed up, you must create two log backups to permit the [!INCLUDEssDE] to truncate the log to the point of the last backup. Truncating the log frees logical space for new log records. To keep the log from filling up again, take log backups regularly and more frequently. For more information, see Recovery Models.
A complete history of all SQL Server backup and restore operations on a server instance is stored in the msdb
system database. To review the complete backup history of a database, use the following sample script:
SELECT bs.database_name , backuptype = CASE WHEN bs.type = 'D' and bs.is_copy_only = 0 THEN 'Full Database' WHEN bs.type = 'D' and bs.is_copy_only = 1 THEN 'Full Copy-Only Database' WHEN bs.type = 'I' THEN 'Differential database backup' WHEN bs.type = 'L' THEN 'Transaction Log' WHEN bs.type = 'F' THEN 'File or filegroup' WHEN bs.type = 'G' THEN 'Differential file' WHEN bs.type = 'P' THEN 'Partial' WHEN bs.type = 'Q' THEN 'Differential partial' END + ' Backup' , bs.recovery_model , BackupStartDate = bs.Backup_Start_Date , BackupFinishDate = bs.Backup_Finish_Date , LatestBackupLocation = bf.physical_device_name , backup_size_mb = bs.backup_size/1024./1024. , compressed_backup_size_mb = bs.compressed_backup_size/1024./1024. , database_backup_lsn -- For tlog and differential backups, this is the checkpoint_lsn of the FULL backup it is based on. , checkpoint_lsn , begins_log_chain FROM msdb.dbo.backupset bs LEFT OUTER JOIN msdb.dbo.backupmediafamily bf ON bs.[media_set_id] = bf.[media_set_id] WHERE recovery_model in ('FULL', 'BULK-LOGGED') AND bs.backup_start_date > DATEADD(month, -2, sysdatetime()) --only look at last two months ORDER BY bs.database_name asc, bs.Backup_Start_Date desc;
A complete history of all SQL Server backup and restore operations on a server instance is stored in the msdb
system database. For more information on backup history, see Backup History and Header Information (SQL Server).
Create a transaction log backup
Example of how to back up the log:
BACKUP LOG [dbname] TO DISK = 'some_volume:some_folderdbname_LOG.trn'
-
Back Up a Transaction Log (SQL Server)
-
xref:Microsoft.SqlServer.Management.Smo.Backup.SqlBackup%2A (SMO)
[!IMPORTANT]
If the database is damaged, see Tail-Log Backups (SQL Server).
ACTIVE_TRANSACTION log_reuse_wait
The steps to troubleshoot ACTIVE_TRANSACTION reason include discovering the long running transaction and resolving it (in some case using the KILL command to do so).
Discover long-running transactions
A very long-running transaction can cause the transaction log to fill. To look for long-running transactions, use one of the following:
- sys.dm_tran_database_transactions.
This dynamic management view returns information about transactions at the database level. For a long-running transaction, columns of particular interest include the time of the first log record (database_transaction_begin_time), the current state of the transaction (database_transaction_state), and the log sequence number (LSN) of the begin record in the transaction log (database_transaction_begin_lsn).
- DBCC OPENTRAN.
This statement lets you identify the user ID of the owner of the transaction, so you can potentially track down the source of the transaction for a more orderly termination (committing it rather than rolling it back).
Kill a transaction
Sometimes you just have to end the transaction; you may have to use the KILL statement. Please use this statement very carefully, especially when critical processes are running that you don’t want to kill. For more information, see KILL (Transact-SQL)
AVAILABILITY_REPLICA log_reuse_wait
When transaction changes at primary Availability replica are not yet hardened on the secondary replica, the transaction log on the primary replica cannot be truncated. This can cause the log to grow, and can occur whether the secondary replica is set for synchronous or asynchronous commit mode. For information on how to troubleshoot this type of issue see Error 9002. The transaction log for database is full due to AVAILABILITY_REPLICA error
CHECKPOINT log_reuse_wait
No checkpoint has occurred since the last log truncation, or the head of the log has not yet moved beyond a virtual log file (VLF). (All recovery models)
This is a routine reason for delaying log truncation. If delayed, consider executing the CHECKPOINT
command on the database or examining the log VLFs.
USE dbname; CHECKPOINT select * from sys.dm_db_log_info(db_id('dbname'))
For more information on log_reuse_wait factors
For more details see Factors that can delay log truncation
2. Resolve full disk volume
In some situations the disk volume that hosts the transaction log file may fill up. You can take one of the following actions to resolve the log-full scenario that results from a full disk:
Free disk space
You might be able to free disk space on the disk drive that contains the transaction log file for the database by deleting or moving other files. The freed disk space allows the recovery system to enlarge the log file automatically.
Move the log file to a different disk
If you cannot free enough disk space on the drive that currently contains the log file, consider moving the file to another drive with sufficient space.
[!IMPORTANT]
Log files should never be placed on compressed file systems.
See Move Database Files for information on how to change the location of a log file.
Add a log file on a different disk
Add a new log file to the database on a different disk that has sufficient space by using ALTER DATABASE <database_name> ADD LOG FILE
. Multiple log files for a single database should be considered a temporary condition to resolve a space issue, not a long-term condition. Most databases should only have one transaction log file. Continue to investigate the reason why the transaction log is full and cannot be truncated. Consider adding temporary additional transaction log files as an advanced troubleshooting step.
For more information see Add Data or Log Files to a Database.
Utility script for recommended actions
These steps can be partly automated by running this T-SQL script which will identify logs files that using a large percentage of disk space and suggest actions:
DECLARE @log_reached_disk_size BIT = 0 SELECT name LogName, physical_name, CONVERT(bigint, size)*8/1024 LogFile_Size_MB, volume_mount_point, available_bytes/1024/1024 Available_Disk_space_MB, (CONVERT(bigint, size)*8.0/1024)/(available_bytes/1024/1024 )*100 file_size_as_percentage_of_disk_space, db_name(mf.database_id) DbName FROM sys.master_files mf CROSS APPLY sys.dm_os_volume_stats (mf.database_id, file_id) WHERE mf.[type_desc] = 'LOG' AND (CONVERT(bigint, size)*8.0/1024)/(available_bytes/1024/1024 )*100 > 90 --log is 90% of disk drive ORDER BY size DESC if @@ROWCOUNT > 0 BEGIN set @log_reached_disk_size = 1 -- Discover if any logs have are close to or completely filled disk volume they reside on. -- Either Add A New File To A New Drive, Or Shrink Existing File -- If Cannot Shrink, Go To Cannot Truncate Section DECLARE @db_name_filled_disk sysname, @log_name_filled_disk sysname, @go_beyond_size bigint DECLARE log_filled_disk CURSOR FOR SELECT db_name(mf.database_id), name FROM sys.master_files mf CROSS APPLY sys.dm_os_volume_stats (mf.database_id, file_id) WHERE mf.[type_desc] = 'LOG' AND (convert(bigint, size)*8.0/1024)/(available_bytes/1024/1024 )*100 > 90 --log is 90% of disk drive ORDER BY size desc OPEN log_filled_disk FETCH NEXT FROM log_filled_disk into @db_name_filled_disk , @log_name_filled_disk WHILE @@FETCH_STATUS = 0 BEGIN SELECT 'Transaction log for database "' + @db_name_filled_disk + '" has nearly or completely filled disk volume it resides on!' AS Finding SELECT 'Consider using one of the below commands to shrink the "' + @log_name_filled_disk +'" transaction log file size or add a new file to a NEW volume' AS Recommendation SELECT 'DBCC SHRINKFILE(''' + @log_name_filled_disk + ''')' AS Shrinkfile_Command SELECT 'ALTER DATABASE ' + @db_name_filled_disk + ' ADD LOG FILE ( NAME = N''' + @log_name_filled_disk + '_new'', FILENAME = N''NEW_VOLUME_AND_FOLDER_LOCATION' + @log_name_filled_disk + '_NEW.LDF'', SIZE = 81920KB , FILEGROWTH = 65536KB )' AS AddNewFile SELECT 'If shrink does not reduce the file size, likely it is because it has not been truncated. Please review next section below. See https://learn.microsoft.com/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql' AS TruncateFirst SELECT 'Can you free some disk space on this volume? If so, do this to allow for the log to continue growing when needed.' AS FreeDiskSpace FETCH NEXT FROM log_filled_disk into @db_name_filled_disk , @log_name_filled_disk END CLOSE log_filled_disk DEALLOCATE log_filled_disk END
3. Change log size limit or enable Autogrow
Error 9002 can be generated if the transaction log size has been set to an upper limit or Autogrow is not allowed. In this case, enabling autogrow or increasing the log size manually can help resolve the issue. Use this T-SQL command to find such log files and follow the recommendations provided:
SELECT DB_NAME(database_id) DbName, name LogName, physical_name, type_desc , CONVERT(bigint, SIZE)*8/1024 LogFile_Size_MB , CONVERT(bigint,max_size)*8/1024 LogFile_MaxSize_MB , (SIZE*8.0/1024)/(max_size*8.0/1024)*100 percent_full_of_max_size, CASE WHEN growth = 0 THEN 'AUTOGROW_DISABLED' ELSE 'Autogrow_Enabled' END as AutoGrow FROM sys.master_files WHERE file_id = 2 AND (SIZE*8.0/1024)/(max_size*8.0/1024)*100 > 90 AND max_size not in (-1, 268435456) OR growth = 0 if @@ROWCOUNT > 0 BEGIN DECLARE @db_name_max_size sysname, @log_name_max_size sysname, @configured_max_log_boundary bigint, @auto_grow int DECLARE reached_max_size CURSOR FOR SELECT db_name(database_id), name, CONVERT(bigint, SIZE)*8/1024, growth FROM sys.master_files WHERE file_id = 2 AND ( (SIZE*8.0/1024)/(max_size*8.0/1024)*100 > 90 AND max_size not in (-1, 268435456) OR growth = 0 ) OPEN reached_max_size FETCH NEXT FROM reached_max_size into @db_name_max_size , @log_name_max_size, @configured_max_log_boundary, @auto_grow WHILE @@FETCH_STATUS = 0 BEGIN IF @auto_grow = 0 BEGIN SELECT 'The database "' + @db_name_max_size+'" contains a log file "' + @log_name_max_size + '" whose autogrow has been DISABLED' as Finding SELECT 'Consider enabling autogrow or increasing file size via these ALTER DATABASE commands' as Recommendation SELECT 'ALTER DATABASE ' + @db_name_max_size + ' MODIFY FILE ( NAME = N''' + @log_name_max_size + ''', FILEGROWTH = 65536KB)' as AutoGrowth END ELSE BEGIN SELECT 'The database "' + @db_name_max_size+'" contains a log file "' + @log_name_max_size + '" whose max limit is set to ' + convert(varchar(24), @configured_max_log_boundary) + ' MB and this limit has been reached!' as Finding SELECT 'Consider using one of the below ALTER DATABASE commands to either change the log file size or add a new file' as Recommendation END SELECT 'ALTER DATABASE ' + @db_name_max_size + ' MODIFY FILE ( NAME = N''' + @log_name_max_size + ''', MAXSIZE = UNLIMITED)' as UnlimitedSize SELECT 'ALTER DATABASE ' + @db_name_max_size + ' MODIFY FILE ( NAME = N''' + @log_name_max_size + ''', MAXSIZE = something_larger_than_' + CONVERT(varchar(24), @configured_max_log_boundary) +'MB )' as IncreasedSize SELECT 'ALTER DATABASE ' + @db_name_max_size + ' ADD LOG FILE ( NAME = N''' + @log_name_max_size + '_new'', FILENAME = N''SOME_FOLDER_LOCATION' + @log_name_max_size + '_NEW.LDF'', SIZE = 81920KB , FILEGROWTH = 65536KB )' as AddNewFile FETCH NEXT FROM reached_max_size into @db_name_max_size , @log_name_max_size, @configured_max_log_boundary, @auto_grow END CLOSE reached_max_size DEALLOCATE reached_max_size END ELSE SELECT 'Found no files that have reached max log file size' as Findings
Increase log file size or enable Autogrow
If space is available on the log disk, you can increase the size of the log file. The maximum size for log files is two terabytes (TB) per log file.
If autogrow is disabled, the database is online, and sufficient space is available on the disk, do either of these:
- Manually increase the file size to produce a single growth increment. These are general recommendations on log size growth and size.
- Turn on autogrow by using the ALTER DATABASE statement to set a non-zero growth increment for the FILEGROWTH option. See Considerations for the autogrow and autoshrink settings in SQL Server
[!NOTE]
In either case, if the current size limit has been reached, increase the MAXSIZE value.
See also
ALTER DATABASE (Transact-SQL)
Manage the Size of the Transaction Log File
Transaction Log Backups (SQL Server)
sp_add_log_file_recover_suspect_db (Transact-SQL)
MSSQLSERVER_9002
How a log file structure can affect database recovery time — Microsoft Tech Community
Ошибка СУБД Microsoft SQL Server Native Client 11.0: «Журнал транзакций для базы данных переполнен». Причина: «LOG_BACKUP». HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1
Описание ошибки:
В это публикации будет рассмотрена не только сама ошибка СУБД о переполнении журнала транзакций, но описание того, как уменьшить (очистить, сократить) журнал транзакций.
Найденные решения:
Эту ситуацию можно было отнести к части обслуживающих операций. Но дает знать о себе переполнение журнала транзакций СУБД в самые неподходящие моменты. Например, часто, при обновлении баз данных, поскольку частое выполнение операций по модификации данных базы приводит к увеличению размеров журнала транзакций. Старые записи журнала транзакций в некоторый момент могут стать не востребованными и могут быть удалены. Таким образом освобождается место для новых записей. Если вовремя не удалять старые записи журнала транзакций, то его файл может занять все свободное дисковое пространство и работа с базой данных станет невозможной, сопровождаемая приведенной ошибкой.
Рассмотрим
Еще примеры того, как сократить журнал регистрации см. в публикации посвященной непосредственно этому вопросу в разделе часто задаваемых вопросов.
Рассмотрим один из примеров того, как сократить журнал транзакций.
Запускается SQL Server Management Studio. В ветке «Базы данных» дерева «Обозревателя объектов» находим базу данных по названию. Вызываем контекстное меню правой кнопкой мыши и в нем выбираем пункт «Создать запрос» и вводим текст:
BACKUP LOG [name_db] WITH TRUNCATE_ONLY
go
DBCC SHRINKFILE ([log_file])
go
, где [name_db] — имя (название) базы данных СУБД. В примере — «Бухгалтерия»;
, а [log_file] имя или путь к файлу журнала (лога) транзакций формата *.ldf. О том, как определить его название и местоположение см. ниже, в примере — «Бухгалтерия_log.ldf»
Прежде чем «Выполнить» запрос нажатием соответствующей кнопки потребуется определить имя файла журнала транзакций. Можно просто искать его по названию базы и расширению на дисках сервера. А можно посмотреть в свойствах базы.
Для этого через то же контекстное меню, что уже вызывали ранее, переходим в «Свойства» базы данных SQL.
В открывшемся окне «Свойств базы данных» переходим на страницу «Файлы». И смотрим «Путь» и «Имя файла» журнала транзакций в колонках таблицы «Файлы базы данных». Эти сведения и используем для заполнения в запросе для параметра [log_file].
Так же можно на будущее настроить автоматическое сжатие журнала транзакций. Это изложено в документации на сайте SQL: настройка авторасширения и автосжатия в SQL Server
Оцените, помогло ли Вам предоставленное описание решения ошибки?
© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.
04-08-2021
Журавлев А.С.
(Сайт azhur-c.ru)
При обновлении бухгалтерии, на этапе сохранения, получил следующую ошибку:
Каталог не обнаружен ‘v8srvr://sql/acc_main/configsave/e0666db2-45d6-49b4-a200-061c6ba7d569.6b9d6525-ee94-4e13-b73d-82d3e8e8441d’
по причине: Каталог не обнаружен ‘ConfigSavee0666db2-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 — название базы Бух)
Код SQL
USE acc_main
ALTER DATABASE acc_main SET RECOVERY SIMPLE
DBCC SHRINKFILE (acc_main, 50);
ALTER DATABASE acc_main SET RECOVERY FULL
Результат выполнения:
Тоже самое можно сделать вручную:
Шаг 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 — имя базы данных):
Код SQL
BACKUP LOG BaseDB TO DISK = '<D:BackupBase_Log.trn'
DBCC SHRINKFILE (BaseDB_Log, 20) WITH NO_INFOMSGS
Все
Содержание:
1. Журнал транзакций в 1С
2. Ошибка Журнал транзакций переполнен
1. Журнал транзакций в 1С
В данной статье будет описана возможная ошибка в системе 1С, а именно – в СУБД, которая связана с переполнением журнала транзакций в 1С. Далее будут приведены возможные методы устранения данной неполадки, среди которых уменьшение журнала транзакций для базы данных.
Сначала следует выяснить, что такое журнал транзакций в 1С. Журнал транзакций является одной из основных составляющих в базе данных. При помощи журнала транзакций для базы данных создаётся резервная копия, которая в случае сбоя системы вернёт базу в нужное состояние, которое изначально было согласовано.
При помощи журнала транзакций можно выполнить такие действия:
1. Восстановление транзакций;
2. Восстановление транзакций, которые не были окончены;
3. Поддерживать повторения транзакций;
4. Производить восстановление базы данных, из-за системного сбоя.
2. Ошибка Журнал транзакций переполнен
В СУБД 1С может появляться ошибка, которая содержит следующий текст: «Журнал транзакций для базы данных «zup» заполнен». Также, в тексте ошибки может приводиться столбец и таблица, к которым следует обратиться.
Такая ошибка возникает в тех случаях, когда в журнале транзакций находится слишком много данных, то есть, он переполнен.
Рассмотрим два возможных способа для устранения ошибки «Журнал транзакций для базы данных переполнен»:
· В первом способе будем следовать такому алгоритму:
1. Проверить наличие и величину свободного места на дисках, в случае, когда места нет – соответственно, нет места и для записи лога;
2. Если место есть, то ошибка «Журнал транзакций для базы переполнен» является ошибкой MicrosoftSQLServer, то есть – лог с транзакциями был полностью заполнен, но не очищен. Это можно исправить при помощи очистки, которая является стандартной, но эта опция не всегда может помочь устранить неполадку. В случае, если она не сработала – стоит использовать следующий код SQLServer:
код SQLServer
В данном коде: 20 – это величина лога в Мб, а «myDataBase» — название нужной базы с данными.
· Следующий способ – это сразу приступить к уменьшению размера журнала с транзакциями.
Так как с журналом транзакций в SQLServer часто проводится много довольно весомых манипуляций, которые связаны с модификацией данных в СУБД, то такие действия приводят к увеличению размеров файловых данных внутри журнала с транзакциями. В данном случае очень важно вовремя удалять не нужные записи из журнала транзакций SQL, в связи с созданием более актуальных. Если не проводить удаления вовремя, то прошлые файлы в журнале транзакций начинают заполнять всё место на диске и далее станет невозможно работать с СУБД.
Так что, в своём роде, данный способ – это предотвращение ошибки «Журнал транзакций переполнен» в 1С.
В таком случае, удаляем те записи, которые больше не нужны, при помощи команды «BACKUPLOG», следующий шаг – это сделать меньше файл из журнала транзакций MSSQL– при помощи команды «DBCCSHRINKFILE». Таким образом, нужный нам код, для предотвращения ошибки, будет выглядеть таким образом:
Предотвращение ошибки Журнал транзакций переполнен
В данной статье были приведены общие данные о том, что такое журнал транзакций, а также проведена диагностика ошибки «Журнал транзакций переполнен» в 1С. Далее было описано, как устранить данную ошибку и дан способ для предотвращения данной неполадки.
Специалист компании «Кодерлайн»
Айдар Фархутдинов
Ошибка СУБД Microsoft SQL Server Native Client 11.0: «Журнал транзакций для базы данных переполнен». Причина: «LOG_BACKUP». HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1
Описание ошибки:
В это публикации будет рассмотрена не только сама ошибка СУБД о переполнении журнала транзакций, но описание того, как уменьшить (очистить, сократить) журнал транзакций.
Найденные решения:
Эту ситуацию можно было отнести к части обслуживающих операций. Но дает знать о себе переполнение журнала транзакций СУБД в самые неподходящие моменты. Например, часто, при обновлении баз данных, поскольку частое выполнение операций по модификации данных базы приводит к увеличению размеров журнала транзакций. Старые записи журнала транзакций в некоторый момент могут стать не востребованными и могут быть удалены. Таким образом освобождается место для новых записей. Если вовремя не удалять старые записи журнала транзакций, то его файл может занять все свободное дисковое пространство и работа с базой данных станет невозможной, сопровождаемая приведенной ошибкой.
Рассмотрим
Еще примеры того, как сократить журнал регистрации см. в публикации посвященной непосредственно этому вопросу в разделе часто задаваемых вопросов.
Рассмотрим один из примеров того, как сократить журнал транзакций.
Запускается SQL Server Management Studio. В ветке «Базы данных» дерева «Обозревателя объектов» находим базу данных по названию. Вызываем контекстное меню правой кнопкой мыши и в нем выбираем пункт «Создать запрос» и вводим текст:
BACKUP LOG [name_db] WITH TRUNCATE_ONLY
go
DBCC SHRINKFILE ([log_file])
go
, где [name_db] — имя (название) базы данных СУБД. В примере — «Бухгалтерия»;
, а [log_file] имя или путь к файлу журнала (лога) транзакций формата *.ldf. О том, как определить его название и местоположение см. ниже, в примере — «Бухгалтерия_log.ldf»
Прежде чем «Выполнить» запрос нажатием соответствующей кнопки потребуется определить имя файла журнала транзакций. Можно просто искать его по названию базы и расширению на дисках сервера. А можно посмотреть в свойствах базы.
Для этого через то же контекстное меню, что уже вызывали ранее, переходим в «Свойства» базы данных SQL.
В открывшемся окне «Свойств базы данных» переходим на страницу «Файлы». И смотрим «Путь» и «Имя файла» журнала транзакций в колонках таблицы «Файлы базы данных». Эти сведения и используем для заполнения в запросе для параметра [log_file].
Так же можно на будущее настроить автоматическое сжатие журнала транзакций. Это изложено в документации на сайте SQL: настройка авторасширения и автосжатия в SQL Server
Оцените, помогло ли Вам предоставленное описание решения ошибки?
© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.
04-08-2021
Журавлев А.С.
(Сайт azhur-c.ru)
Сжатие (шринк) журнала транзакций в MS SQL
Краткое описание моделей восстановления MS SQL
Довольно популярная ошибка СУБД в кругах 1Сников «Журнал транзакций для базы данных заполнен», если информационная база развернута в клиент-серверном варианте с использованием MS SQL и все настройки были оставлены по-умолчанию (см. рисунок 1).
Рисунок 1. Ошибка переполнения журнала транзакций |
Конечно, MS SQL умеет автоматически усекать журнал транзакций (физически размер файла журнала транзакций не уменьшается), но бывают исключения, при которых происходит задержка усечения (начинается физическое увеличение размера файла журнала транзакций).
Для борьбы с переполнением журнала транзакций предусмотрены следующие вариант настройки СУБД:
- создание резервной копии журнала;
- освобождение места на диске, чтобы журнал мог автоматически расти;
- перемещение файла журнала на диск с достаточным объемом свободного места;
- увеличение размера файла журнала;
- добавление файла журнала на другой диск;
- завершение или уничтожение длительной транзакции.
Но, бесконечно свободного места на жестком диске не бывает, а усечение не уменьшает размер файла физического журнала, поэтому для уменьшения физического размера файла журнала необходимо выполнить его сжатие (шринк).
Рассмотрим операцию сжатия файла журнала транзакций.
Первым делом, необходимо выяснить причину, по которой происходит задержка усечения журнала транзакций (Факторы, могущие вызвать задержку усечения журнала), может быть просто нужно увеличить размер файла журнала транзакций, так как не хватает его из-за длительной транзакции.
Второй шаг — выполнить создание резервной копии файла журнала транзакций (Как создать резервную копию журнала транзакций (среда SQL Server Management Studio)).
Третий шаг — сжатие файла журнала транзакций (операция выполняется через среду SQL Server Management Studio):
1) Разверните узел Базы данных и щелкните правой кнопкой мыши базу данных, которую нужно сжать. Укажите пункты Задачи и Сжать, затем выберите пункт Файлы (см. рисунок 2);
Рисунок 2. Задача сжатия файла |
2) Выберите тип файла и имя файла (см. рисунок 3).
Далее выберите способ сжатия:
- Освободить неиспользуемое место — выбор этого параметра приводит к освобождению всего неиспользуемого пространства файла для ОС и уменьшению размера файла до последнего размещенного экстента. Это уменьшает размер файла без перемещения каких-либо данных.
- Реорганизовать файлы перед освобождением неиспользуемого места — при выборе этого режима необходимо указать значение Сжать файл до.
- Очистить файл путем переноса данных в другие файлы той же файловой группы — выбор этого режима перемещает все данные из указанного файла в другие файлы данной файловой группы. Пустой файл удалить нельзя. Этот режим эквивалентен выполнению процедуры DBCC SHRINKFILE с параметром EMPTYFILE.
Рисунок 3. Настройка сжатия журнала транзакций |
3) Нажмите кнопку ОК.
Ошибка должна исчезнуть.
Eugeneer
21.09.11 — 10:15
Забился диск. Интернет прошуршал. Никаокго решения не нашел. Одно есть у Евгения http://help1c.com/faq/hits/12.html
Но не помогает, ругается что нет такого метода T_runcate_only
SQL 2005. Перезагрузки сервера, скуля, остановки сервера 1С не помогают.
Лог чистится не хочет.
GoldenDawn
101 — 21.09.11 — 19:59
(98)а сегодня не уехал потому что паяльник уже греют? )))
Кириллка
102 — 21.09.11 — 20:02
Маня, будь мужиком, блеать. Признай, что ты чайнег
Специально нашел для чайнега:
#define DB_E_ERRORSINCOMMAND ((HRESULT)0x80040E14L)
Это код твоей ошибки, объявлена она в oledberr.h
Т.е. еще раз, эррогировать на HRESULT=80040E14 нет смысла, потомочто в HRESULT=80040E14 написано по-программистски (ну т.е. не для тебя, так как ты не программист) «Ошибка в команде, ахтунг, за разъяснениями вызывайте GetErrorInfo»
fisher
103 — 21.09.11 — 20:03
(98) Когда срочно надо освободить место, то всякие реорганизации плохой выбор, т.к. они тоже места потребовать могут. В итоге долго выполняются и могут ошибкой завершиться.
Реорганизации и шринки для лога и самой базы отдельные. Скорее всего ты базу реорганизовал, а не лог.
Eugeneer
104 — 21.09.11 — 20:04
(102) если бы ты не булы тупым то уже бы давно открыл ссылку и прочитал бы
Журнал транзакций заполнен. HRESULT=80040E14
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных «zup» заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу 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 “DataBase” 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
Решение:
1. Посмотрите сколько свободного места осталось на дисках, может его нет и логу некуда записаться…
2. Это ошибка Microsoft SQL Server — переполняется лог транзакций и не очищается. Урезать его возможно различными способами, в том числе и с помощью стандартной оснастки, но не всегда данная операция получается, и размер файла лога остается прежним. Как вариант предлагаю следующее решение из двух строчек:
Кириллка
105 — 21.09.11 — 20:04
+102 программисты платформы вызвали GetErrorInfo и получили от провайдера «Журнал транзакций для базы данных <имябазы> заполнен….»
Eugeneer
106 — 21.09.11 — 20:04
Внимательно читаем и смотрим —
Это ошибка Microsoft SQL Server
Eugeneer
107 — 21.09.11 — 20:05
Я еще в сабже написал ссылку и сказал что ошибка описана по ссылке и у меня таже проблема. Но ты оказался туп и этого не заметил.
Кириллка
108 — 21.09.11 — 20:06
(104)Маня, ты серьезно считаешь, что еси будешь меня называть тупым, кто-то в это поверит??
Eugeneer
109 — 21.09.11 — 20:06
Так вот «обратитесь к столбцу log_reuse_wait_desc таблицы» сообщает нам что там есть незавершенная транзакция. Это и является ПРОБЛЕМОЙ.
Eugeneer
110 — 21.09.11 — 20:07
(108) нет. я сичтаю что ты тупость проявляешь сам своими постами корчЯ из себя знатока и умника.
Eugeneer
111 — 21.09.11 — 20:09
а оскорбляешь именно ты меня. а не я тебя. уже сколько десятков постов, а ты даже сабж не изучил.
Кириллка
112 — 21.09.11 — 20:09
Маня, еще раз:
— HRESULT=80040E14 это не ошибка Microsoft SQL Server;
— это код ошибки, которую выкинул oledb-провайдер на то, что скуль не смог увеличить размер лог-файла по той причине, что места на диске ему не хватило. Потому что ты криво настроил модель восстановления (бекап раз в полгода). Потому что ты взялся за то, чего не умел никогда. Потому что у тебя руки из опы. Могу долго продолжать …
Eugeneer
113 — 21.09.11 — 20:10
и я тебе Киррилка не Маня. Будешь маней называть своих родственников. Я тебя впервые вижу и слышу. Для теюя я Евгений Владимирович.
fisher
114 — 21.09.11 — 20:11
(106) Ошибка программы и ошибка в программе — чуточку разные вещи.
Eugeneer
115 — 21.09.11 — 20:11
(112) иди накуй. вот что я тебе могу сказать.
Кириллка
116 — 21.09.11 — 20:11
(113)бугага, Маня, не смеши меня.
Eugeneer
117 — 21.09.11 — 20:12
(116) Пидриллка шел бы ты уже. по добру.
Ленинград
118 — 21.09.11 — 20:13
мдээээээээээ
bizon2008
119 — 21.09.11 — 20:13
(104)Смотрим в книгу, видим фигу? Там же ясно написано кто ошибку тебе писал «Microsoft OLE DB Provider for SQL Server» и где надо подробности было смотреть «обратитесь к столбцу log_reuse_wait_desc таблицы
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1″
Иди учись делать бекапы.
bizon2008
120 — 21.09.11 — 20:16
Евгений Владимирович зарубите себе на носу. Ни один сервер БД не скажет тебе свою ошибку. Он данные выдает. А ошибки он пишет в логи.
Наймите DBA, и жить станет проще.
Кириллка
121 — 21.09.11 — 20:16
Маня, а ты на своем сайте дашь ссылочку на эту ветку, чтоб народ видел, как ты абасцрался прилюдно?
fisher
122 — 21.09.11 — 20:19
Почему это он абасцрался? Он честно признался, что не является специалистом в данной теме. Потом, правда, начал агрессивно заблуждаться.
GoldenDawn
123 — 21.09.11 — 20:20
(121)нет
сейчас манин друг придет и даст ценный совет
маня пропиарит друга
друг пропиарит маню
и никакой рекламы
Кириллка
124 — 21.09.11 — 20:20
Маня, ты так и не понял-поди, что у тебя произошло? Если понял, вещай — мы скорректируем если че
Ленинград
125 — 21.09.11 — 20:20
(121) а я веточку засейваю
GoldenDawn
126 — 21.09.11 — 20:23
топикстартер правильно всё делает
новый сервак купят за лям
потом сотрудников наберут на поддержку «1с которая тормозит без поддержки»
а сам будет сидеть админом на скуле и смотреть на лог
Eugeneer
127 — 21.09.11 — 20:23
(121) да я абацрался. но на тебя. Так что не воняй.
Eugeneer
128 — 21.09.11 — 20:24
(126) я не выполняю обязанности админа. Но если с базой что то происходит то ковырять естественно кроме меня некому. админ который админ в этом вообще ноль.
Кириллка
129 — 21.09.11 — 20:24
(127)для пущей окраски ты должен был еще описать каким калом ты на меня абасцрался. Как-то уныло у тебя получилось. Попробуй еще разок :))
Eugeneer
130 — 21.09.11 — 20:26
(129) ну ты и извращенец. За сим откланиваюсь. Ветка запахла очень сильно. Не выветрить.
Кириллка
131 — 21.09.11 — 20:26
(128)так вы там два брата-акробата чтоли? Печалька..
aleks-id
132 — 21.09.11 — 20:28
/*жует попкорн*/
Кириллка
133 — 21.09.11 — 20:30
(130)Маня, будь мужиком, блеать. Останься и реабилитируйся в глазах общественности — докажи, что ты чего-то стоишь.
Krendel
134 — 21.09.11 — 20:32
Лень читать. Скока на исправлении этой ошибки маня заработал? хоть часиков 10 выставил на курение манов по скл?
pectopatop
135 — 21.09.11 — 20:43
(134) Маня поднял 10 левелов Репутации на этом
pectopatop
136 — 21.09.11 — 20:44
(135) + и произвел 3 тонны огородных удобрений
zmaximka
137 — 21.09.11 — 20:52
да уж. и эти люди хотят от ста тыщь и покупают логан
aleks-id
138 — 21.09.11 — 20:54
(137) зато он знает про рекурсию )))
GoldenDawn
139 — 21.09.11 — 21:20
мажоры хуле…
базнес = связи
К списку
В случае, если вы видите данное сообщение Журнал транзакций для базы данных «BASE» переполнен. Причина: «LOG_BACKUP, то Вам необходимо уменьшить размер лога транзакций MS SQL Server. Для этого выполните следующие действия:
- Откройте приложение SQL Server Management Studio;
- Подключитесь к серверу MS SQL;
- Выберите необходимую Базу данных, кликните правой кнопкой мыши, в контекстном меню выберите пункт Свойства;
- В открывшемся окне выберите пункт Параметры;
- Для пункта Модель восстановления выставите значение Простая;
- Сохраните изменения, нажав кнопку ОК;
- Выберите необходимую базу данных, кликните правой кнопкой мыши, в контекстном меню выберите пункт Задачи ► Сжать ► Файлы;
- В открывшемся окне для пункта Тип файла выставите значение Журнал;
- Активируйте опцию Реорганизовать страницы, перед тем как освободить неиспользуемое место;
- В поле Сжать файл до введите значение 0;
- Нажмите кнопку OK для выполнения процесса сжатия;
- В свойствах базы данных, в открывшемся окне выберите пункт Параметры;
- Для пункта Модель восстановления выставите значение Полная;
- Сохраните изменения, нажав кнопку ОК.