У меня есть база данных 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.
источник
Вы пытались настроить базу данных, чтобы не публиковать?
а затем резервное копирование журнала, чтобы увидеть, что происходит?
Изменить 1: Что возвращает следующий t-sql?
источник
У меня была точно такая же проблема. БД SQL Express никогда не была частью репликации. В прошлом он был восстановлен с помощью некоторых команд DBCC checkdb. И через некоторое время мы обнаружили, что
показал «РЕПЛИКАЦИЯ» как причину и лог-файл растет.
Мы удалили репликацию, используя этот tsql:
Это решило проблему, и мы могли бы сжать журнал.
источник
Я бы попробовал следующее:
После чего вы можете попробовать добавить репликацию и удалить репликацию для отдельной таблицы в базе данных, как это предлагается в посте ниже.
Когда-то у нас была база данных, которая переключалась в режим репликации, хотя распределение и репликация не были настроены на SQL Server.
Я не смог найти оригинальный сценарий, который использовал для своей проблемы, поэтому я запустил поиск и наткнулся на эту запись в MSDN:
log_reuse_wait_desc = репликация, журнал транзакций не перестанет расти
Существует некоторая неопределенная первопричина для этой проблемы, и это происходит во всем мире.
Удачной охоты!
источник
Если вы попробовали все остальное, то, возможно, можно было бы (сначала убедиться, что у вас есть хорошая резервная копия!) Отсоединить базу данных, переименовать файл журнала (чтобы SQL Server не смог его найти), а затем повторно присоединить базу данных. Я считаю, что это заставит SQL Server создать новый файл журнала. Не перестану ли я думать, что база данных реплицируется, я понятия не имею, но, по крайней мере, это возможно.
источник