CDC Özelliğini Kullanan Veritabanının Restore Edilme Senaryoları

Bu yazımızda, cdc özelliğine sahip veri tabanlarının, aynı ve farklı Instance üzerinde aynı ve farklı isimlerle oluşturulması sonrası bu özelliğin, oluşturulan database’lerde aktif olarak devam etmesi ilgili işlemleri uygulayacağız. Aynı zamanda bu konu ile ilgili karşılaşılan hatanın çözümü üzerine konuşacağız. Konu hakkında daha detaylı bilgi almak için CHANGE DATA CAPTURE NEDİR? adlı makaleyi okumanızı tavsiye ederim. -- İlk adımımız olan cdc'nin açık olduğu veri tabanlarını buluyoruz. select name,is_cdc_enabled from sys.databases   -- CDC_TestDB Database oluşturulur. CREATE DATABASE [CDC_TestDB] ON  PRIMARY ( NAME = N'CDC_TestDB', FILENAME = N'F:\CDC_TestDB.mdf' , SIZE = 5120KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ) LOG ON ( NAME = N'CDC_TestDB_Log', FILENAME = N'F:\CDC_TestDB_log.ldf' , SIZE = 3840KB , MAXSIZE = 2048GB , FILEGROWTH = 10%) GO   use [CDC_TestDB]; go -- tablo oluşturma create table Personel ( perID int constraint PK_Personel primary key Identity(1,1) ,perName varchar(20) ) --CDC_TestDB database üzerinde CDC Aktif Etme USE [CDC_TestDB] […]

CDC Özelliğini Kullanan Veritabanının Restore Edilme Senaryoları

Bu yazımızda, cdc özelliğine sahip veri tabanlarının, aynı ve farklı Instance üzerinde aynı ve farklı isimlerle oluşturulması sonrası bu özelliğin, oluşturulan database’lerde aktif olarak devam etmesi ilgili işlemleri uygulayacağız. Aynı zamanda bu konu ile ilgili karşılaşılan hatanın çözümü üzerine konuşacağız.

Konu hakkında daha detaylı bilgi almak için CHANGE DATA CAPTURE NEDİR? adlı makaleyi okumanızı tavsiye ederim.

-- İlk adımımız olan cdc'nin açık olduğu veri tabanlarını buluyoruz.

select name,is_cdc_enabled from sys.databases

 

-- CDC_TestDB Database oluşturulur.

CREATE DATABASE [CDC_TestDB] ON  PRIMARY

( NAME = N'CDC_TestDB', FILENAME = N'F:\CDC_TestDB.mdf' , SIZE = 5120KB ,

MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )

LOG ON

( NAME = N'CDC_TestDB_Log', FILENAME = N'F:\CDC_TestDB_log.ldf' , SIZE = 3840KB ,

MAXSIZE = 2048GB , FILEGROWTH = 10%)

GO


 

use [CDC_TestDB];

go

-- tablo oluşturma

create table Personel

(

perID int constraint PK_Personel primary key Identity(1,1)

,perName varchar(20)

)
--CDC_TestDB database üzerinde CDC Aktif Etme

USE [CDC_TestDB]

GO

EXEC sys.sp_cdc_enable_db
-- Oluşturduğumuz Tablonun cdc özelliği aktif edilir.

USE [CDC_TestDB]

GO

EXEC sys.sp_cdc_enable_table

@source_schema = N'dbo',

@source_name = N'Personel',

@role_name = NULL

GO
--Personel Tablosuna Bir Değer Giriyoruz

insert into Personel values('Serdar'),('Bayrak')
-- CDC Tablosundaki değişiklikleri aşağıdaki sorgu ile görebiliriz.

select * from cdc.dbo_Personel_CT
--Restore Senaryosunu denemek için oluşturduğumuz veri tabanının yedeğini alıyoruz.

backup database CDC_TestDB to disk = 'F:\CDC_TestDB.bak'

 

--Aynı Instance altında Farklı Database ismi ile Restore ediyoruz.

Restore Database [CDC_TestDB_NEW]

from disk = 'F:\CDC_TestDB.bak'

with move 'CDC_TestDB' to 'F:\CDC_TestDB1.mdf',

move 'CDC_TestDB_Log' to 'F:\CDC_TestDB_log1.ldf',keep_cdc

 

 

--Aynı Instance altında Farklı Database ismi ile ve cdc_keep seçeneği olmadan Restore ediyoruz.

Restore Database [CDC_TestDB_Not]

from disk = 'F:\Data01\CDC_TestDB.bak'

with move 'CDC_TestDB' to 'F:\CDC_TestDB2.mdf',

move 'CDC_TestDB_Log' to 'F:\CDC_TestDB_log2.ldf'

 

 

--Farkli Instance üzerinde Aynı Database ismi ile Restore Ediyoruz.

restore database CDC_TestDB from disk = 'F:\CDC_TestDB.bak' with keep_cdc

 

 

--Farkli Instance üzerinde Farklı Database ismi ile Restore Ediyorum.

restore database CDC_TestDB_Not from disk = 'F:\CDC_TestDB.bak'

with move 'CDC_TestDB' to 'F:\CDC_TestDB3.mdf',

move 'CDC_TestDB_Log' to 'F:\CDC_TestDB_log3.ldf'

 

 

--cdc temizleme ve yakalama joblarını oluşturuyoruz.

Use [CDC_TestDB]

exec sys.sp_cdc_add_job 'capture'

GO

exec sys.sp_cdc_add_job 'cleanup'

GO

 

cdc özelliği açık bir database başka bir instance ortamında restore edilirken, keep_cdc özelliği ile aktif edilmez ve bu tablolar üzerinde cdc user ve schema yetkiye sahip ve bu tabloda isim değişikliği yapmak ve tabloyu drop etmek istediğinizde size izin vermeyecektir. Bu işlemi yaptığınızda size aşağıdaki hatayı dönecektir. Çözüm için aşağıdaki adımları sırayla izleyeniz.

Eğer database’nizde cdc özelliğini aktif olarak kullanıyorsanız disable ettikten sonra açmayı unutmayınız. Bu işlemleri SQL Server’ın log mekanizması ile bağlantılı olduğundan konunun uzmanından yardım almanızda fayda bulunmaktadır.

USE [TESTDB]

drop table dbo.test_NEW

 

Problem: Msg, Level 16, State 1, Procedure sys.sp_cdc_ddl_event_internal, Line 69 [Batch Start Line] Index ‘source_object_id_idx’ on table ‘cdc.change_tables’ (specified in the FROM clause) does not exists.

 

 

Çözüm:

USE [TESTDB]

GO

exec sys.sp_cdc_disable_db

@source_schema =N'dbo',

@source_name = N'test_NEW'

@capture_instance = N'test_NEW'

GO

drop table dbo.test_NEW

veya

USE [TESTDB]

GO

exec sys.sp_cdc_disable_db

GO

drop table dbo.test_NEW

Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 2 hafta önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 1 ay önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL Server 1 ay önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

0 Yorum

Yorum Yaz

Rastgele