Aracılığıyla paylaş


Değişiklik verilerini yakalamayı yönetme ve izleme

Şunlar için geçerlidir:SQL ServerAzure SQL Yönetilen Örneği

Bu konu başlığı altında, SQL Server ve Azure SQL Yönetilen Örneği için değişiklik verisi yakalamanın nasıl yönetilip izleneceği açıklanmaktadır.

Farklı bir iş mekanizması kullanan Azure SQL Veritabanı için bkz. Azure SQL Veritabanı ile CDC.

İşi yakalama işlemi

sp_MScdc_capture_jobparametresiz saklı yordamı çalıştırılarak yakalama işi başlatılır. Bu saklı yordam, yakalama işi için maxtrans, maxscans, continuousve pollinginterval için yapılandırılmış değerleri msdb.dbo.cdc_jobs'den ayıklayarak başlar. Bu yapılandırılmış değerler daha sonra sp_cdc_scansaklı yordamına parametre olarak iletilir. Bu, günlük taraması gerçekleştirmek için sp_replcmds çağırmak için kullanılır.

İş parametrelerini kaydet

Yakalama işinin davranışını anlamak için yapılandırılabilir parametrelerin sp_cdc_scantarafından nasıl kullanıldığını anlamanız gerekir.

maxtrans parametresi

maxtrans parametresi, günlüğün tek bir tarama döngüsünde işlenebilen işlem sayısı üst sınırını belirtir. Tarama sırasında işlenecek işlem sayısı bu sınıra ulaşırsa, geçerli taramaya ek işlem dahil değildir. Tarama döngüsü tamamlandıktan sonra, işlenen işlem sayısı her zaman maxtransdeğerinden küçük veya buna eşit olur.

maxscans parametresi

maxscans parametresi, günlüğü boşaltmaya çalışırken ya dönüş (sürekli = 0) ya da bir bekleme yürütme (sürekli = 1) durumundan önce denenen en fazla tarama döngüsü sayısını belirtir.

continuous parametresi

continuous parametresi, günlüğü boşalttıktan veya en fazla tarama döngüsü sayısını yürüttükten sonra sp_cdc_scan'in kontrolü bırakıp bırakmayacağını (tek seferlik mod) denetler. Ayrıca sp_cdc_scan açıkça durdurulana kadar (sürekli mod) çalışmaya devam edip etmeyeceğini de denetler.

Tek çekim modu

Tek seferlik modda, yakalama işi sp_cdc_scan, günlüğü boşaltmayı ve döndüğünü bildirmek için en fazla maxscans tarama gerçekleştirmeyi talep eder. maxtrans'a ek olarak günlükte yer alan tüm işlemler daha sonraki taramalarda işlenecektir.

Tek seferlik mod, işlenecek işlemlerin hacminin bilindiği denetimli testlerde kullanılır ve işin bittiğinde otomatik olarak kapanmasının avantajları vardır. Üretim kullanımı için tek seferlik mod önerilmez. Bunun nedeni, tarama döngüsünün ne sıklıkta çalıştırileceğini yönetmek için iş zamanlamasına bağlı olmasıdır.

Tek seferlik modda çalışırken, aşağıdaki hesaplamayı kullanarak yakalama işinin beklenen aktarım hızı üzerinde saniye başına işlemlerle ifade edilen bir üst sınır hesaplayabilirsiniz:

(maxtrans * maxscans) / number of seconds between scans

Günlüğü taramak ve değişiklik tablolarını doldurmak için gereken süre 0'dan önemli ölçüde farklı olmasa bile, tek bir tarama için izin verilen maksimum işlem sayısı günlük işlemeyi ayıran saniye sayısıyla çarpılarak işin ortalama aktarım hızı elde edilen değeri aşamaz.

Günlük taramasını düzenlemek için tek seferlik mod kullanılacaksa, günlük işleme arasındaki saniye sayısı iş zamanlamasına göre yönetilmelidir. Bu tür bir davranış istendiğinde, yakalama işini sürekli modda çalıştırmak günlük taramasını yeniden zamanlamanın daha iyi bir yoludur.

Sürekli mod ve yoklama aralığı

Sürekli modda, yakalama işi sp_cdc_scan'ın sürekli çalışmasını istemektedir. Bu, saklı yordamın yalnızca maxtrans ve maxscans için değil, aynı zamanda günlük işleme (yoklama aralığı) arasındaki saniye sayısı için bir değer sağlayarak kendi bekleme döngüsünü yönetmesini sağlar. Sürekli modda, yakalama süreci etkin kalır ve günlük taraması sırasında bir WAITFOR yürütür.

Not

Yoklama aralığının değeri 0'dan büyük olduğunda, yinelenen tek seferlik iş için aktarım hızı üzerindeki üst sınır sürekli modda iş işlemi için de geçerlidir. Yani, (maxtrans * maxscans) ifadesi sıfır olmayan bir yoklama aralığına bölündüğünde, bu, yakalama işi tarafından işlenebilecek ortalama işlem sayısına bir üst sınır koyar.

İş özelleştirmeyi yakalama

Yakalama işi için, yeni bir taramanın hemen başlayıp başlamayacağını veya bir bekleme süresi koyulup koyulmayacağını belirlemek üzere, sabit bir yoklama aralığına güvenmek yerine ek mantık uygulayabilirsiniz. Seçim yalnızca günün saatine, belki de yoğun etkinlik zamanlarında çok uzun uykuları zorunlu kılmaya ve hatta günlerin işlenmesini tamamlamanın ve gece çalıştırmalarına hazırlanmanın önemli olduğu günün sonunda 0'lık bir yoklama aralığına geçmeye dayanabilir. Yakalama işlemi ilerleme durumu, gece yarısına kadar işlenen tüm işlemlerin ne zaman tarandığını ve değişiklik tablolarına ne zaman yatırıldığını belirlemek için de izlenebilir. Bu, yakalama işinin sona ermesine izin verir ve zamanlanmış günlük bir yeniden başlatma ile yeniden başlatılmasını sağlar. Davranışı özelleştirmek için, sp_cdc_scan çağıran iş adımını sp_cdc_scaniçin kullanıcı tarafından yazılmış sarmalayıcıya yapılan bir çağrıyla değiştirebilirsiniz.

Temizleme işi

Bu bölümde, değişiklik verilerini yakalama temizleme işinin nasıl çalıştığı hakkında bilgi sağlanır.

Temizleme işinin yapısı

Değişiklik verilerini yakalama, değişiklik tablosu boyutunu yönetmek için saklama tabanlı bir temizleme stratejisi kullanır. SQL Server ve Azure SQL Yönetilen Örneği'nde temizleme mekanizması, ilk veritabanı tablosu etkinleştirildiğinde oluşturulan bir SQL Server Agent Transact-SQL işinden oluşur. Tek bir temizleme işi, tüm veritabanı değişiklik tabloları için temizlemeyi işler ve tanımlanan tüm yakalama örneklerine aynı bekletme değerini uygular.

Temizlik işlemi, sp_MScdc_cleanup_jobparametresiz saklı yordam çalıştırılarak başlatılır. Temizleme işi için yapılandırılmış bekletme ve eşik değerlerini ayıklayarak bu saklı yordam msdb.dbo.cdc_jobs'dan başlar. Saklama değeri, değişiklik tabloları için yeni bir düşük filigran hesaplamak amacıyla kullanılır. Yeni düşük su işaretini tarih saat değeri olarak elde etmek için belirtilen dakika sayısı, tran_end_time tablosundaki maksimum cdc.lsn_time_mapping değerinden çıkarılır. CDC.lsn_time_mapping tablosu daha sonra bu tarih saat değerini karşılık gelen bir lsn değerine dönüştürmek için kullanılır. Aynı işlem zamanı tablodaki birden çok giriş tarafından paylaşılıyorsa, en küçük lsn'e sahip olan girişe karşılık gelen lsn yeni alt filigran olarak seçilir. Bu lsn değeri, veritabanındaki değişiklik tablolarından girişleri kaldırmak için sp_cdc_cleanup_change_tables'e geçirilir.

Not

Yeni alt filigranı hesaplama temeli olarak son işlemin işleme süresini kullanmanın avantajı, değişikliklerin belirtilen süre boyunca değişiklik tablolarında kalmasına izin veriyor olmasıdır. Yakalama işlemi geride kaldığında bile bu durum oluşur. Geçerli düşük eşikle aynı işlem zamanına sahip olan tüm girdiler, değişiklik tablolarında, mevcut düşük eşik için paylaşılan işlem zamanına sahip en küçük lsn seçilerek temsil edilmeye devam eder.

Temizleme gerçekleştirildiğinde, tüm yakalama örnekleri için alt referans noktası başlangıçta tek bir işlemde güncelleştirilir. Ardından, değişiklik tablolarından ve cdc.lsn_time_mapping tablosundan eski girdileri kaldırmaya çalışır. Yapılandırılabilir eşik değeri, tek bir deyimde kaç girişin silindiğini sınırlar. Silme işleminin herhangi bir tabloda gerçekleştirilememesi, işlemin kalan tablolarda denenmesini engellemez.

Temizlik işi özelleştirme

Temizleme işi için özelleştirme olasılığı, hangi değişiklik tablosu girdilerinin atılması gerektiğini belirlemek için kullanılan stratejidedir. Teslim edilen temizleme işinde desteklenen tek strateji zamana dayalı stratejidir. Bu durumda, yeni düşük filigran, izin verilen saklama süresi işlenen son işlemin işleme süresinden çıkarılarak hesaplanır. Temel temizleme yordamları zaman yerine lsn dayandığından, değişiklik tablolarında tutulacak en küçük lsn'i belirlemek için çeşitli stratejiler kullanılabilir. Bunlardan yalnızca bazıları kesinlikle zamana dayalıdır. Örneğin, değişiklik tablolarına erişim gerektiren aşağı akış işlemleri çalıştırılamıyorsa, istemcilerle ilgili bilgiler, bir güvenlik önlemi sağlamak için kullanılabilir. Ayrıca, varsayılan strateji tüm veritabanlarının değişiklik tablolarını temizlemek için aynı lsn uygulasa da, yakalama örneği düzeyinde temizlemek için temel temizleme yordamı da çağrılabilir.

İşlemi izleme

Değişiklik verilerini yakalama işlemini izlemek, değişikliklerin doğru yazılıp yazılmadığını ve değişiklik tablolarında makul bir gecikme süresiyle karar vermenizi sağlar. İzleme, oluşabilecek hataları belirlemenize de yardımcı olabilir. SQL Server, değişiklik veri yakalamasını izlemenize yardımcı olacak iki dinamik yönetim görünümü içerir: sys.dm_cdc_log_scan_sessions ve sys.dm_cdc_errors.

Boş sonuç kümeleriyle oturumları tanımlama

0 kimliğine sahip satır hariç, sys.dm_cdc_log_scan_sessions içindeki her satır bir günlük tarama oturumunu temsil eder. Bir günlük tarama oturumu, sp_cdc_scan’in bir kez yürütülmesine eşdeğerdir. Oturum sırasında tarama değişiklikleri döndürebilir veya boş bir sonuç döndürebilir. Sonuç kümesi boşsa, sys.dm_cdc_log_scan_sessions içindeki empty_scan_count sütunu 1 olarak ayarlanır. Yakalama işinin sürekli çalışıyor olması gibi ardışık boş sonuç kümeleri varsa, var olan son satırdaki empty_scan_count artırılır. Örneğin, sys.dm_cdc_log_scan_sessions değişiklikleri döndüren taramalar için zaten 10 satır içeriyorsa ve bir satırda beş boş sonuç varsa, görünüm 11 satır içerir. Son satırın empty_scan_count sütunundaki değeri 5'tir. Boş tarama yapılan oturumları belirlemek için aşağıdaki sorguyu çalıştırın:

SELECT * from sys.dm_cdc_log_scan_sessions where empty_scan_count <> 0

Gecikme süresini belirleme

sys.dm_cdc_log_scan_sessions yönetim görünümü, her yakalama oturumu için gecikme süresini kaydeden bir sütun içerir. Gecikme süresi, kaynak tabloda işlenen bir işlem ile değişiklik tablosunda işlenen son yakalanan işlem arasındaki geçen süre olarak tanımlanır. Gecikme sütunu yalnızca etkin oturumlar için doldurulur. empty_scan_count sütununda 0'dan büyük bir değere sahip oturumlar için gecikme sütunu 0 olarak ayarlanır. Aşağıdaki sorgu, en son oturumlar için ortalama gecikme süresini döndürür:

SELECT latency FROM sys.dm_cdc_log_scan_sessions WHERE session_id = 0

Yakalama işleminin işlemleri ne kadar hızlı veya yavaş işlediğini belirlemek için gecikme verilerini kullanabilirsiniz. Bu veriler en çok yakalama işlemi sürekli çalıştığında kullanışlıdır. Yakalama işlemi bir zamanlamaya göre çalışıyorsa, kaynak tabloda işlenen işlemler ile yakalama işleminin zamanlandığı saatte çalışması arasındaki gecikme nedeniyle gecikme süresi yüksek olabilir.

Yakalama işlemi verimliliğinin bir diğer önemli ölçüsü de aktarım hızıdır. Bu, her oturum sırasında işlenen saniye başına ortalama komut sayısıdır. Oturumun aktarım hızını belirlemek için command_count sütunundaki değeri süre sütunundaki değere bölün. Aşağıdaki sorgu, en son oturumlar için ortalama aktarım hızını döndürür:

SELECT command_count/duration AS [Throughput] FROM sys.dm_cdc_log_scan_sessions WHERE session_id = 0

Örnekleme verilerini toplamak için veri toplayıcı kullanma

SQL Server veri toplayıcısı, herhangi bir tablo veya dinamik yönetim görünümünden verilerin anlık görüntülerini toplamanıza ve bir performans veri ambarı oluşturmanıza olanak tanır. Veritabanında değişiklik veri yakalama etkinleştirildiğinde, sys.dm_cdc_log_scan_sessions görünümünün ve sys.dm_cdc_errors görünümünün anlık görüntülerini daha sonra çözümlemek üzere düzenli aralıklarla almak yararlı olur. Aşağıdaki yordam, sys.dm_cdc_log_scan_sessions yönetim görünümünden örnek verileri toplamak için bir veri toplayıcı ayarlar.

Veri toplamayı yapılandırma

  1. Veri toplayıcıyı etkinleştirin ve bir yönetim veri ambarı yapılandırın. Daha fazla bilgi için bkz. Veri Toplamayı Yönetme.

  2. Değişiklik verisi yakalama için özel bir toplayıcı oluşturmak üzere aşağıdaki kodu yürütür.

    USE msdb;  
    
    DECLARE @schedule_uid uniqueidentifier;  
    
    -- Collect and upload data every 5 minutes  
    SELECT @schedule_uid = (  
    SELECT schedule_uid from sysschedules_localserver_view
    WHERE name = N'CollectorSchedule_Every_5min')  
    
    DECLARE @collection_set_id int;  
    
    EXEC dbo.sp_syscollector_create_collection_set  
    @name = N' CDC Performance Data Collector',  
    @schedule_uid = @schedule_uid,
    @collection_mode = 0,
    @days_until_expiration = 30,
    @description = N'This collection set collects CDC metadata',  
    @collection_set_id = @collection_set_id output;  
    
    -- Create a collection item using statistics from
    -- the change data capture dynamic management view.  
    DECLARE @parameters xml;  
    DECLARE @collection_item_id int;  
    
    SELECT @parameters = CONVERT(xml,
        N'<TSQLQueryCollector>  
            <Query>  
              <Value>SELECT * FROM sys.dm_cdc_log_scan_sessions</Value>  
              <OutputTable>cdc_log_scan_data</OutputTable>  
            </Query>  
          </TSQLQueryCollector>');  
    
    EXEC dbo.sp_syscollector_create_collection_item  
    @collection_set_id = @collection_set_id,  
    @collector_type_uid = N'302E93D1-3424-4BE7-AA8E-84813ECF2419',  
    @name = ' CDC Performance Data Collector',  
    @frequency = 5,
    @parameters = @parameters,  
    @collection_item_id = @collection_item_id output;
    
    GO  
    
  3. SQL Server Management Studio'da önce Yönetim'i genişletin ve ardından Veri Toplama'yı genişletin. CDC Performans Veri Toplayıcısı sağ tıklayın ve ardından Veri Toplama Kümesini Başlatöğesine tıklayın.

  4. 1. adımda yapılandırdığınız veri ambarında custom_snapshots.cdc_log_scan_data tablosunu bulun. Bu tablo, günlük tarama oturumlarından verilerin geçmiş anlık görüntüsünü sağlar. Bu veriler gecikme süresini, aktarım hızını ve zaman içindeki diğer performans ölçülerini analiz etmek için kullanılabilir.

Betik yükseltme modu

Bir örneğe toplu güncelleştirmeler veya hizmet paketleri uyguladığınızda, yeniden başlatıldığında örnek Betik Yükseltme moduna girebilir. Bu modda, SQL Server iç CDC tablolarını analiz etmek ve yükseltmek için bir adım çalıştırabilir ve bu da yakalama tablolarında dizinler gibi nesnelerin yeniden oluşturmasına neden olabilir. Söz konusu veri miktarına bağlı olarak, bu adım biraz zaman alabilir veya etkin CDC veritabanları için yüksek işlem günlüğü kullanımına neden olabilir.