İşlem Günlüğü küçülmez, DB çoğaldığını düşünür


13

Kaspersky Security Center'ı çalıştıran bir SQL Server 2008 R2 Express veritabanı var ve yüklemenin hangi koşullarda gerçekleştiğine dair hiçbir fikrim yok, ancak veritabanı çoğaltıldığını ve işlem günlüğünde herhangi bir alan bırakmayacağını düşünüyor gibi görünüyor. Örneğin:

USE master;

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

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

İadeler:

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

Ayrıca Replication, SSMS'de listelenen hiçbir şey yoktur .

Şimdiye kadar Google sonuçlarından toplanan birkaç ifadeyi denedim:

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

Ama bu DB çoğaltılmakta olduğunu düşünmeyi durdurmak için almakta hiç şansım olmadı.

Tam sys.databasesbilgi:

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

Ayrıca:

DBCC OPENTRAN;
No active open transactions.

DBCC SQLPERF(LOGSPACE);
KAV 171066  99.55339    0

EXEC sp_replcounters;
KAV 0   0   0   0x00000000000000000000  0x00000000000000000000

Ayrıca tam veri ve günlük yedeklemeleri yaptım.

Ben çok benzer durumlarla birkaç yazı rastlamak ve verilen çözüm çoğaltma Yayınlama ve Dağıtım kurmak ve sonra tekrar kaldırmak oldu. Ancak, bu Express Edition, bu seçenekler benim için bile görünmüyor.

Biz öncelikle bir Linux mağazasıyız ve bu sahip olduğumuz tek SQL Server örneği. Gerçek lisans almayı başaramayan tek şey bizim tek yolumuz olabilir: Express olmayan bir örneğe yedeklemeyi geri yüklemek ve ardından bir Yayını kaldırmak, sonra da tekrar Express'e geri yüklemek için.

Yanıtlar:


5

Yayınlanmış bir veritabanını geri yükleme çözümü

Benzer bir sorunla karşılaştık: Yayımlanmış bir veritabanı Sunucu1'de depolanır. Her gün bu veritabanı Server2 üzerinde yedeklenecek ve geri yüklenecektir.

  • Sık sık hata mesajları aldık:

    REPLICATION nedeniyle günlük dolu

  • log_reuse_wait_descolarak ayarlandı REPLICATION.
  • Bu veritabanı Server2'de yayımlanmadığından çoğaltma kaldırılamadı.

Çözüm

Veritabanını geri yükledikten sonra yayını etkinleştirin ve kaldırın:

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

Bu veritabanında kesinti olması kabul edilebilir mi? Bu, muhtemelen çoğaltılmış bir veritabanından geri yüklenmiştir veya büyük olasılıkla yanlış bir şekilde kaldırılmış bir abone olmuştur. Ekspresden standart veya daha yüksek bir sürüme yedeklemeyi ve ardından çoğaltmayı yeniden ayarlayıp kaldırmayı deneyebilirsiniz. Ardından standarttan yedekleyebilir ve ifade etmek için geri yükleyebilirsiniz. Veritabanında daha yüksek sürümdeyken hiçbir özelliği etkinleştirmediğiniz sürece, sürüm düşürmede bir sorun olmamalıdır. Durumu ortadan kaldıracağından emin olmak ve kesinti süresini en aza indirmek için hepsini komut dosyası haline getirmek için bunu gerçek bir kesinti önceden test edebilirsiniz. Kullanabileceğiniz başka bir sunucunuz yoksa, değerlendirme kopyasını alın ve yerel makinenize, bir VM'ye, kabul edilebilirse orijinal makineye veya bulabileceğiniz herhangi bir yere kurun.


Duruş süresi, AV için merkezi bir güncelleme / lisans sunucusu çalıştırdığı için veritabanında önemli bir sorun değildir. [Ayrıca fark etmeden önce de birkaç gün kaldı] Ancak, yorumlarda belirttiğim gibi, öncelikle bir Linux mağazamız ve bu bizim tek MSSQL örneğimiz. Ayrıca yedekleme 180GB + 'dır, bu nedenle harici bir sağlayıcıya göndermek de bir seçenek değildir.
Sammitch

Aynı kutuya başka bir örnek yükleyebilir ve bu veritabanının yedeğini alan izin vererek geri yükleyebilirsiniz. Alternatif olarak, bir yedek alabilir ve veritabanını ekspresden ayırabilir ve değerlendirme kopyasına ekleyebilir ve bir yayın kurmaya / kaldırmaya çalışabilirsiniz. En kötü durumda, orijinali vidalarsınız ve düşürmeniz ve yedeklemeyi geri yüklemeniz gerekir. En iyi durumda, işe yarar, değerlendirmeden ayırın ve değerlendirmeyi ifade etmek ve ardından kaldırmak için yeniden takın.
2_14

1

Veritabanını yayınlanmayacak şekilde ayarlamayı denediniz mi?

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

ve sonra ne olacağını görmek için günlüğü yedekleyin?

Düzenleme 1: Aşağıdaki t-sql ne döndürür?

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

1

Aynı sorunu yaşadım. SQL Express DB hiçbir zaman bir çoğaltma parçası değildi. Geçmişte bazı DBCC checkdb komutlarıyla onarılmıştı. Ve bir zamanlar bunu keşfettik

SELECT name, log_reuse_wait_desc 
FROM sys.databases 

neden "REPLICATION" ve logfile büyüyen gösterdi.

Bu tsql kullanarak çoğaltmayı kaldırdık:

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

exec sp_removedbreplication @db

Bu çözüldü ve kütüğü küçültebilirdik.


0

Aşağıdakileri deneyeceğim:

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

Bundan sonra, çoğaltma eklemeyi ve veritabanındaki tek bir tablo için çoğaltmayı kaldırmayı deneyebilirsiniz.

SQL Server'da dağıtım ve çoğaltma ayarlanmamış olsa bile, bir kerede çoğaltma moduna geçen bir veritabanımız vardı.

Sorunum için kullandığım orijinal komut dosyasını bulamadım, bu yüzden bir arama yaptım ve MSDN'de bu girişe rastladım:

log_reuse_wait_desc = çoğaltma, işlem günlüğü büyümeyi durdurmaz

Bu sorunun bazı belirsiz nedenleri var ve bu tüm dünyada gerçekleşiyor.

İyi avlar!


-1

Her şeyi denediyseniz, veritabanını ayırmak, günlük dosyasını yeniden adlandırmak (böylece SQL Server bulamaz) ve sonra veritabanını yeniden eklemek mümkün olabilir (önce iyi bir yedek olduğundan emin olun!). Bunun SQL Server'ı yeni bir günlük dosyası oluşturmaya zorlayacağına inanıyorum. Veritabanının çoğaltıldığını düşünmeyi bırakıp bırakmayacağımı bilmiyorum, ama en azından mümkün görünüyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.