Arkadaşlar farkındayım bu aralar hep Replication (veri aktarma) uygulamaları ve özellikle de Oracle Golden Gate'in SQL Server ile çalışmasından, sorunlarından vs. bahsediyorum. Bunun nedeni, bu ürünün çalıştığım firmada servis yöneticisi olmam ve bu ürünün sorunlarıyla uğraşıyor olmam. Bu sorunlarla boğuşurken, Google'da arattırıldığında Golden Gate ile kaynaklara ulaşmadaki zorluğu gördüğümden dolayı ve Türkiye'de bu ürünün (her ne kadar sınırlı olsa da) kullanımının artmasından dolayı, Türkçe içerik oluşturmak için paylaşımda bulunmak istiyorum.
Çok uzun süredir bu ürünün kaynak sunuculardaki Extract'larının asılı kalma sorunuyla boğuşuyoruz. Bu konuda Oracle Development Vice President'i Alok ile de hem yüzyüze, hem de telekonferans şeklinde birkaç toplantı yaptık. Ayrıca tabii ki bu konuda bir SR (Service Request - Çağrı Kaydı)'ımız da var ve Oracle Support ile sorun üstünde çalışmalarımız devam ediyor.
Önce biraz sorunu tanımlayayım, ondan sonra da neden bu sorun hakkında paylaşımda bulunduğumu aktarayım.
Sorun, kaynaktaki Extract Process'lerinin çalışıyor olarak görünmelerine (RUNNING) rağmen aslında Transaction Log veya Transaction Log Backup dosyalarından kayıt okuyamalarıdır. Tabii ki kayıt okunamadığı için de, tablolara yapılan yeni işlemler hedef sunucuya aktarılamıyor. Bu sorunu farketmek normal şartlar altında zor, ancak kullanıcılar yeni veri gelmiyor diye şikâyet ettiğinde farkedebiliyorsunuz çünkü her şey çalışıyor görünüyor.
Bu sorunu sizlerle paylaşıyorum, çünkü bu sorun hakkında internette bir şeye ulaşmanız zor. Ayrıca geldiğimiz noktaya gelinceye kadar biz çok vakit ve emek harcadık, siz de Amerika'yı tekrar keşfetmek için vakit harcamayın.
Henüz sorun ile ilgili bir yama (Patch) çıkarılabilmiş değil, fakat en son yaptığımız toplantıda Oracle bu sorun konusunda çok yol aldıklarını ve sorunu gidermek için bir test versiyonu yaptıklarını söylüyorlardı. Yakında deneyeme başlarız sanırım. Bu, bize özel bir sürüm olacak; genel için ise bu sürümü 2012 senesinin başında yayınlayabileceklerini söylediler.
Örneğin eğer sorunlu Extract'a SEND STATUS komutunu gönderdiğinizde aşağıdaki gibi bir sonuç alıyorsanız:
GGSCI (SUNUCU_ADI) 79> SEND E_XXX01 STATUS
Sending STATUS request to EXTRACT E_XXX01 ...
EXTRACT E_XXX01 (PID 24612)
Current status: Recovery complete: At EOF
Current read position:
LSN: 0x0017a155:0001d552:0009
Timestamp: 2011-07-20 10:11:08.403333
Current write position:
Sequence #: 376
RBA: 5696650
Timestamp: 2011-07-20 15:11:18.633000
Extract Trail: ./dirdat/I1
O zaman bu sorunu yaşıyorsunuz demektir. Görüldüğü üzere "Current status" verisi Recovery'nin tamamlandığını, dosya sonuna gelindiğini söylüyor; fakat bu komutu çalıştırdığımda saat 15:11 olmasına rağmen "Current read position" sabah saat 10:11'de kalmış. Eğer siz de böyle bir sonuç alıyorsanız, Extract'ınızın takılı\asılı kalma sorunu var demektir.
Sorunu geçici olarak aşmanın yolu ise çoğu sorunu aşmak için kullandığımız yöntem ile aynı: "kapat / aç". Evet, sorunu aşmak için sorun yaşanan Extract Process'ini STOP EXTRACT komutu ile durdurup, START EXTRACT komutuyla başlatmanız yetiyor.
Ben bu sorunun geçici çözümünü otomatikleştirdim. Bunu burada ayrıntılı olarak anlatmayacağım, çünkü muhtemelen çok az kişinin başına gelebilecek bir sorun. Eğer birisi gerçekten bu sorunu yaşarsa, o zaman benimle irtibat kurabilir. Önceden de bahsettiğim gibi, maksadım internet ortamında Golden Gate'in SQL Server ile çalışması konusunda bilgiye ulaşabilmeniz, en azından yazdıklarım ilk etapta size fikir verir.
Çok özetlemek gerekirse, oluşturduğum otomatik çözüm şöyle çalışıyor:
- Kaynak ile hedef arasında bir "Heartbeat" sistemi oluşturdum. Her 15 saniyede bir, kaynaktan hedefe Timestamp bilgisi gönderiliyor.
- Şayet hedefteki en son Timestamp, o anki saatten 10dk. gerideyse, o zaman SQL Error Log'una ilgili Extract ile bir kayıt kaydediliyor.
- HP OpenView hedefteki bu kaydı algılıyor (bunun yerine başka bir uygulama veya yöntem de kullanılabilir) ve kaynaktaki yazdığım uygulamayı çalıştırıyor.
- Yazdığım uygulama, SEND STATUS komutu ile Extract'ın Timestamp bilgisini o anki saat ile karşılaştırıyor ve eğer 10 dakika fark varsa, o zaman "Current status" bilgisine bakıyor, eğer hem Current Read Position'ın Timestamp'i 10 dk gerideyse ve Current status de "Recovery complete: At EOF" ise, o zaman ilgili Extract, STOP EXTRACT komutuyla durduruluyor. Hemen ardından tekrar SEND STATUS komutları gönderiliyor ilgili Extract'a ve "ERROR: EXTRACT E_INT01 not currently running." sonucu geldiğinde de START EXTRACT komutuyla ilgili Extract başlatılıyor.
Programa bir log'lama sistemi de eklediğim için, yeniden başlatmalar hakkında ayrıntılı bilgi de edinebiliyorum. Şayet olur da bir gün bu sorun ile karşılaşırsanız haber verin, uygulamamı paylaşabilirim.
Sorunuçta dediğim gibi, bu geçici bir çözüm ve Oracle kalıcı çözüm için çalışıyor. Ama bizim gibi günü kurtarmak zorundaysanız, o zaman böyle bir şeye muhakkak ihtiyacınız var demektir.
Selamlar,
Ekrem
Hiç yorum yok:
Yorum Gönder