Le journal des transactions ne diminuera pas, DB pense qu'il se réplique

J'ai une base de données SQL Server 2008 R2 Express exécutant Kaspersky Security Center, et je n'ai aucune idée des circonstances dans lesquelles l'installation s'est produite, mais la base de données semble penser qu'elle est répliquée et ne libérera aucun espace du journal des transactions. par exemple:

USE master;

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

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

Retour:

name | log_reuse_wait | log_reuse_wait_desc | is_cdc_enabled
-----|----------------|---------------------|---------------
KAV  | 6              | REPLICATION         | 0 

DATABASEPROPERTYEX('KAV', 'IsPublished')
----------------------------------------
0 [not published]

De plus, rien n'est répertorié dans la Replicationsection SSMS.

Jusqu'à présent, j'ai essayé quelques déclarations tirées des résultats de Google:

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

Mais je n'ai pas eu de chance pour que cette base de données arrête de penser qu'elle est répliquée.

sys.databasesInformation complète :

+-----------------------------------+------------------------------------------------------------+
| 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                                                          |
+-----------------------------------+------------------------------------------------------------+

Aussi:

DBCC OPENTRAN;
No active open transactions.

DBCC SQLPERF(LOGSPACE);
KAV 171066  99.55339    0

EXEC sp_replcounters;
KAV 0   0   0   0x00000000000000000000  0x00000000000000000000

Je viens également d'effectuer des sauvegardes complètes des données et des journaux.

J'ai parcouru quelques articles avec des situations très similaires, et la solution proposée a été de configurer la réplication de publication et de distribution, puis de la supprimer à nouveau. Cependant, ceci étant Express Edition, ces options ne m'apparaissent même pas.

Nous sommes principalement une boutique Linux et c'est la seule instance SQL Server que nous ayons. Si tout le reste échoue, l'obtention d'une véritable licence peut être notre seul recours: restaurer une sauvegarde sur une instance non-Express et essayer de configurer puis supprimer une publication, puis enfin restaurer sur Express.

Solution pour restaurer une base de données publiée

Nous avons rencontré un problème similaire: une base de données publiée est stockée sur Server1. Chaque jour, cette base de données sera sauvegardée et restaurée sur Server2.

• Nous avons souvent reçu des messages d'erreur:

  JOURNAL plein en raison de la RÉPLICATION

• log_reuse_wait_desca été défini sur REPLICATION.
• La réplication n'a pas pu être supprimée, car cette base de données n'a pas été publiée sur Server2.

Solution

Après avoir restauré la base de données, activez la publication et supprimez-la:

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'

Est-il acceptable d'avoir des temps d'arrêt sur cette base de données? Cela a probablement été restauré à partir d'une base de données répliquée ou il s'agissait peut-être d'un abonné qui a été incorrectement supprimé, bien que cela soit peu probable. Vous pouvez essayer de faire une sauvegarde à partir d'Express et de restaurer vers une édition standard ou supérieure, puis de configurer à nouveau la réplication et de la supprimer. Ensuite, vous pouvez sauvegarder à partir de la norme et restaurer pour exprimer. Tant que vous n'activez aucune fonctionnalité sur la base de données lors de l'édition supérieure, il ne devrait pas y avoir de problème de rétrogradation. Vous pouvez tester cela avant une panne réelle pour vous assurer qu'il supprimera le statut et le script tout pour minimiser les temps d'arrêt. Si vous n'avez pas d'autre serveur que vous pouvez utiliser, récupérez la copie d'évaluation et installez-la sur votre machine locale, une machine virtuelle, la machine d'origine si elle est acceptable, ou n'importe où vous pouvez trouver.

Avez-vous essayé de configurer la base de données pour qu'elle ne soit pas publiée?

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

puis sauvegarder le journal pour voir ce qui se passe?

Edit 1: Que renvoie le t-sql suivant?

-- 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

J'ai eu exactement le même problème. La base de données SQL Express n'a jamais fait partie d'une réplication. Dans le passé, il a été réparé avec certaines commandes DBCC checkdb. Et à un moment donné, nous avons découvert que

SELECT name, log_reuse_wait_desc 
FROM sys.databases 

a montré "REPLICATION" comme raison et le fichier journal grandissant.

Nous avons supprimé la réplication à l'aide de ce tsql:

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

exec sp_removedbreplication @db

Cela l'a résolu et nous avons pu réduire le journal.

J'essaierais ce qui suit:

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

Après quoi, vous pouvez essayer d'ajouter une réplication et de supprimer une réplication pour une table individuelle dans la base de données, comme suggéré dans la publication plus bas.

Nous avions une base de données à un moment donné qui est passée en mode de réplication même si la distribution et la réplication n'avaient pas été configurées sur SQL Server.

Je n'ai pas pu trouver le script d'origine que j'avais utilisé pour mon problème, j'ai donc lancé une recherche et suis tombé sur cette entrée sur MSDN:

log_reuse_wait_desc = réplication, le journal des transactions ne cessera de croître

Il existe une cause profonde non spécifique à ce problème et cela se produit partout dans le monde.

Bonne chasse!

Si vous avez essayé tout le reste, il serait peut-être possible (en vous assurant d'abord d'avoir une bonne sauvegarde!) De détacher la base de données, de renommer le fichier journal (afin que SQL Server ne puisse pas le trouver), puis de rattacher la base de données. Je pense que cela forcera SQL Server à créer un nouveau fichier journal. Je ne sais pas si cela cessera également de penser que la base de données est répliquée, mais cela semble au moins possible.