Журнал транзакций не сжимается, БД думает, что реплицирует

13

У меня есть база данных SQL Server 2008 R2 Express, на которой работает Kaspersky Security Center, и я не знаю, при каких обстоятельствах произошла установка, но кажется, что база данных реплицируется и не освобождает место в журнале транзакций. например:

USE master;

SELECT 
    name, log_reuse_wait, log_reuse_wait_desc, is_cdc_enabled 
FROM 
    sys.databases 
WHERE 
    name = 'KAV';

SELECT DATABASEPROPERTYEX('KAV', 'IsPublished');

возвращает:

name | log_reuse_wait | log_reuse_wait_desc | is_cdc_enabled
-----|----------------|---------------------|---------------
KAV  | 6              | REPLICATION         | 0 
DATABASEPROPERTYEX('KAV', 'IsPublished')
----------------------------------------
0 [not published]

Также в Replicationразделе SSMS ничего не указано .

До сих пор я пробовал пару утверждений, почерпнутых из результатов Google:

USE KAV;
EXEC sp_repldone null, null, 0,0,1;
EXEC sp_removedbreplication KAV;

Но мне не повезло заставить эту БД перестать думать, что она копируется.

Полная sys.databasesинформация:

+-----------------------------------+------------------------------------------------------------+
| name                              | KAV                                                        |
| database_id                       | 5                                                          |
| source_database_id                | NULL                                                       |
| owner_sid                         | 0x0105000000000005150000004EB006B0C3554AB049CEA01BE8030000 |
| create_date                       | 2013-07-04 10:31:28.947                                    |
| compatibility_level               | 90                                                         |
| collation_name                    | Latin1_General_CI_AS                                       |
| user_access                       | 0                                                          |
| user_access_desc                  | MULTI_USER                                                 |
| is_read_only                      | 0                                                          |
| is_auto_close_on                  | 0                                                          |
| is_auto_shrink_on                 | 0                                                          |
| state state_desc                  | ONLINE                                                     |
| is_in_standby                     | 0                                                          |
| is_cleanly_shutdown               | 0                                                          |
| is_supplemental_logging_enabled   | 0                                                          |
| snapshot_isolation_state          | 1                                                          |
| snapshot_isolation_state_desc     | ON                                                         |
| is_read_committed_snapshot_on     | 1                                                          |
| recovery_model                    | 1                                                          |
| recovery_model_desc               | FULL                                                       |
| page_verify_option                | 2                                                          |
| page_verify_option_desc           | CHECKSUM                                                   |
| is_auto_create_stats_on           | 1                                                          |
| is_auto_update_stats_on           | 1                                                          |
| is_auto_update_stats_async_on     | 0                                                          |
| is_ansi_null_default_on           | 1                                                          |
| is_ansi_nulls_on                  | 1                                                          |
| is_ansi_padding_on                | 1                                                          |
| is_ansi_warnings_on               | 1                                                          |
| is_arithabort_on                  | 1                                                          |
| is_concat_null_yields_null_on     | 1                                                          |
| is_numeric_roundabort_on          | 0                                                          |
| is_quoted_identifier_on           | 1                                                          |
| is_recursive_triggers_on          | 0                                                          |
| is_cursor_close_on_commit_on      | 0                                                          |
| is_local_cursor_default           | 1                                                          |
| is_fulltext_enabled               | 1                                                          |
| is_trustworthy_on                 | 0                                                          |
| is_db_chaining_on                 | 0                                                          |
| is_parameterization_forced        | 0                                                          |
| is_master_key_encrypted_by_server | 0                                                          |
| is_published                      | 0                                                          |
| is_subscribed                     | 0                                                          |
| is_merge_published                | 0                                                          |
| is_distributor                    | 0                                                          |
| is_sync_with_backup               | 0                                                          |
| service_broker_guid               | 19C05AF5-8686-4C27-BF7E-93E240DA953B                       |
| is_broker_enabled                 | 0                                                          |
| log_reuse_wait                    | 6                                                          |
| log_reuse_wait_desc               | REPLICATION                                                |
| is_date_correlation_on            | 0                                                          |
| is_cdc_enabled                    | 0                                                          |
| is_encrypted                      | 0                                                          |
| is_honor_broker_priority_on       | 0                                                          |
+-----------------------------------+------------------------------------------------------------+

Также:

DBCC OPENTRAN;
No active open transactions.

DBCC SQLPERF(LOGSPACE);
KAV 171066  99.55339    0

EXEC sp_replcounters;
KAV 0   0   0   0x00000000000000000000  0x00000000000000000000

Я также только что выполнил полное резервное копирование данных и журналов.

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

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

Sammitch
источник

Ответы:

5

Решение для восстановления опубликованной базы данных

Мы столкнулись с похожей проблемой: опубликованная база данных хранится на сервере Server1. Каждый день эта база данных будет архивироваться и восстанавливаться на сервере Server2.

  • Мы часто получаем сообщения об ошибках:

    Журнал заполнен из-за репликации

  • log_reuse_wait_descбыл установлен в REPLICATION.
  • Невозможно удалить репликацию, поскольку эта база данных не была опубликована на сервере Server2.

Решение

После восстановления базы данных включите публикацию и удалите ее:

USE MyDatabase
GO
-- 1.) enable publication for MyDatabase
EXEC sp_replicationdboption 
  @dbname = 'MyDatabase', 
  @optname = N'publish', 
  @value = N'true';
GO
-- 2.) remove publication from database. Use the PUBLICATION-name (not database name)
sp_removedbreplication 'Publ_MyDatabase','both'

-- 3.) disable publication for MyDatabase
EXEC sp_replicationdboption 
  @dbname = 'MyDatabase', 
  @optname = N'publish', 
  @value = N'false';
GO

-- Verify: log_reuse_wait_desc should have changed from REPLICATION to NOTHING
SELECT name, log_reuse_wait_desc, * FROM sys.databases WHERE name = 'MyDatabase'
Матиас Эльфляйн
источник
1

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

Your_comment_is_not_funny
источник
Время простоя не является серьезной проблемой для базы данных, поскольку она просто использует централизованный сервер обновлений / лицензирования для нашего AV. [Кроме того, он был недоступен в течение нескольких дней, прежде чем я заметил] Однако, как я уже упоминал в комментариях, мы в основном магазин Linux, и это наш единственный экземпляр MSSQL. Кроме того, резервная копия имеет размер 180 ГБ +, поэтому ее отправка внешнему поставщику также невозможна.
Саммит
Вы можете установить другой экземпляр на тот же ящик и восстановить резервную копию этой базы данных, если позволяет пространство. Кроме того, вы можете сделать резервную копию, а затем отсоединить базу данных от экспресс-печати и прикрепить ее к пробной копии и попытаться настроить / удалить публикацию. В худшем случае, вы облажаетесь с оригиналом и должны его уронить и восстановить резервную копию. В лучшем случае, это работает, вы отсоединяетесь от оценки и снова присоединяете ее к выражению, а затем удаляете оценку.
Your_comment_is_not_funny
1

Вы пытались настроить базу данных, чтобы не публиковать?

use master
exec sp_replicationdboption @dbname = N'<DATABASENAME>', @optname = N'publish', @value = N'false'
GO

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

Изменить 1: Что возвращает следующий t-sql?

-- Run on publisher database for Pub, subscriber information

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

SELECT  sa.name AS ArticleName,
        sp.name AS PublicationName,
        d.datasource AS Distributor,
        s.dest_db AS Destination_DB,
        srv.srvname AS SubscriptionServer
FROM    dbo.syspublications sp  
LEFT JOIN
        dbo.sysarticles sa 
        on sp.pubid = sa.pubid 
LEFT JOIN
        dbo.syssubscriptions s 
        on sa.artid = s.artid 
LEFT JOIN
        master.dbo.sysservers srv 
        on s.srvid = srv.srvid 
OUTER APPLY 
        (
        SELECT  datasource
        FROM    master.dbo.sysservers
        WHERE   srvstatus & 8 <> 0
        ) d
Pixelated
источник
1

У меня была точно такая же проблема. БД SQL Express никогда не была частью репликации. В прошлом он был восстановлен с помощью некоторых команд DBCC checkdb. И через некоторое время мы обнаружили, что

SELECT name, log_reuse_wait_desc 
FROM sys.databases 

показал «РЕПЛИКАЦИЯ» как причину и лог-файл растет.

Мы удалили репликацию, используя этот tsql:

declare @db as varchar(100) = 'dbname'

exec sp_removedbreplication @db

Это решило проблему, и мы могли бы сжать журнал.

baitronic
источник
0

Я бы попробовал следующее:

USE <database_name_here>
GO
EXEC sp_repldone 
    @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1

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

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

Я не смог найти оригинальный сценарий, который использовал для своей проблемы, поэтому я запустил поиск и наткнулся на эту запись в MSDN:

log_reuse_wait_desc = репликация, журнал транзакций не перестанет расти

Существует некоторая неопределенная первопричина для этой проблемы, и это происходит во всем мире.

Удачной охоты!

Джон ака hot2use
источник
-1

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

paulH
источник