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 section Replication de 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 cesse de penser qu'elle est répliquée.
Plein sys.databases Info:
+-----------------------------------+------------------------------------------------------------+
| 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 rencontré plusieurs articles avec très des situations similaires, et la solution proposée a été de configurer la publication et la distribution de la réplication, 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 vraie 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 à 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 recevons fréquemment des messages d'erreur:
JOURNAL plein en raison de la RÉPLICATION
log_reuse_wait_desca été défini surREPLICATION.- 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. Vous avez des options limitées avec express comme vous l'avez observé.
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 pourrions réduire le journal.
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'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 première non spécifique à ce problème et cela se produit partout dans le monde.
Bonne chasse!