HATA:
2011-07-12 09:08:20 ERROR OGG-01296 Error mapping from DBA.KAYNAK_TABLOM to DBA.HEDEF_TABLOM.
veya
2011-07-12 09:08:20 WARNING OGG-01154 SQL error 100 mapping DBA.KAYNAK_TABLOM to DBA.HEDEF_TABLOM No data found.
Açıklama:
Bildiğim kadarıyla Golden Gate ile bu sorunu sadece SQL Server'da değil, Oracle Database'de de yaşayabilirsiniz. Bu sorun, kaynaktan hedefe aktarılacak kayıdın hedefte bulunmamasından kaynaklanıyor. "Bir şekilde" aktarılamayan kayıt, kaynaktaki Extract tarafından yakalanamıyor. Bu konuda üzerinde Oracle Support ile çalıştığımız bir SR mevcut, fakat henüz bir sonuca ulaşamadık. Ulaşınca onun hakkında da bilgi veririm.
Sorunu gidermek için ise benim uyguladığım yöntem oldukça doğrudan ve pratik, yaptığım şey ilk önce (eğer değilse, ki mümkünse olmasın) hedefteki Replicat'ın parametre dosyasında kullanılan aşağıdaki parametrelerin
(değerler örnektir)
grouptransops 2000
maxtransops 2000
aşağıdaki gibi değiştirilmesi:
grouptransops 1
maxtransops 1
Böylece Discard dosyası Replicat tekrar çalıştırıldığında dolup taşmayacak ve o anda sorun yaşanan kayda ulaşabileceksiniz. Sorun yaşanan Replicat'ın Discard dosyasından parametrelerini elde ettiğiniz kaydı kaynaktan hedefe elle aktarmanız gerekiyor. Bunun için benim şimdiye kadar bulduğum en pratik yöntem, sorunlu kaydı kaynaktan hedefe SQL Server'ın Import\Export Wizard'ını kullanarak aktarmak.
Bu işlemi yaptıktan sonra hedefteki Replicat'ı doğrudan çalıştırabilirsiniz. Bu işlemi bazen art arda birkaç kere yapmak gerekebiliyor, kaynaktan kaç tane kayıt kaçırıldığına bağlı olarak değişebilir.
Bu sorun besbelli ki Oracle Golden Gate'in bir BUG'ı. Sorun hakkında Case açalı 2 ay olacak neredeyse, istenilen her bilgi ve dosya paylaşılmasına rağmen maalesef bir sonuca varamadık. Bununla birlikte bu sorunu bu yazımda belirttiğim geçici çözümle geçici olarak aşabilir, en azından günü kurtarabilirsiniz.
Ahh bu arada, sorunu düzelttikten sonra, yani tüm eksik kayıtları kaynaktan hedefe attıktan sonra grouptransops ve maxtransops parametrelerini eski değerleriyle değiştirmeyi unutmayın, yoksa hedefte kayıtların işlenmesi çoook çok yavaş olur. Bu parametreler hakkında daha fazla bilgi için Oracle Golden Gate Reference Guide'a bakabilirsiniz.
Selamlar,
Ekrem
12 Temmuz 2011 Salı
6 Temmuz 2011 Çarşamba
SQL Server Replication, Sybase Replication Server, Oracle Golden Gate
Verileri etkin bir şekilde biriktirmek ve depolamak işin sadece bir tarafı, diğer tarafı da bu bilginin kullanılabilir hale getirilmesi. Bu maksatla her türlü 3. parti üründen de yararlanabilme fırsatını kolluyoruz. Dünya çapındaki yenilikleri takip ediyoruz ve işimize yarayabileceğini düşündüğümüz yazılım ve donamını test ortamlarımızda deniyoruz veya ürünler hakkında sunumlar talep ediyoruz.
Bu kapsamda geçen ayın son günlerinde Sybase Türkiye'den Evren Tokçelik (Teknik Danışman) ve Borga Kaşdoğan (Satış Yöneticisi) bize Sybase'in Replication ürünü olan Replication Server ürününü tanıttı.
Adından da anlaşılabileceği üzere Sybase Replication Server, temel olarak A noktasında bulunan verilerin heterojen (farklı RDBMS'lerden farklı RDBMS'lere) B, C .. ortamlarına aktarılması amacıyla kullanılabilecek bir Replikasyon (veri aktarımı) uygulaması. Bu uygulamanın temel olarak yaptığı şey Oracle Golden Gate veya SQL Server Replication'ın yaptığı şey olan veri aktarımı. Bazı arkadaşlarımın aklına Database Mirroring ile Log Shipping de veri aktarımı için kullanılabilir gibi bir fikir gelebilir, tabii ki öyle, ama hepsi de farklı ihtiyaçlara göre farklı durumlarda kullanılır ve bu konulara önceden zaten çok değinmiştik, o yüzden bu yazıda bu teknolojilerden bahsetmeyeceğim.
Bu yazımda daha ziyade doğrudan SQL Server Replication, Oracle Golden Gate ve Sybase Replication Server'ı karşılaştırıp size bir fikir vermek istiyorum.
Birbirine daha yakın olduklarından dolayı öncelikle SQL Server Replication ve Sybase Replication Server arasındaki ufak farklardan bahsedeyim:
Sybase Replication Server'ın, SQL Server Replication'a karşı olan en temel üstünlüğü heterojen ortamlardaki desteği. Birçok farklı RDBMS'ten birçok farklı diğer RDBMS'e veri aktarma özelliği bulunuyor, SQL Server Replication'ın ise bu konudaki desteği çok kısıtlı. Sybase Replication Server'ın bir başka özelliği ise (biz bu konuda herhangi bir POC testi yapmadık, bu nedenle vurgulamak istiyorum ki bu konuda tabiri caizse Evren ve Borga'nın yalancısıyım) SQL Server Replication'dan daha hızlı olması. Fakat elimizde bu konuda bir dokümantasyon, karşılaştırma, Benchmark vs. bulunmuyor. Bununla birlikte, SQL Server (Transactional) Replication'ın (SQL Server 2008'den itibaren) Partition Switch desteği bulunuyor, fakat Sybase Replication Server her ne kadar DDL değişikliklerini aktarma özelliğini barındırsa da, Partition Switch işlemini desteklemiyor ne yazık ki.
Bu karşılaştırma sonrasında bir iki maddede şöyle diyebilirim:
SQL SERVER Replication :
+ SQL Server Replication ek bir maliyet gerektirmiyor. Ayrıca ürün ve destek ekibi aynı olduğundan dolayı, destek konusundaki maliyetler de düşük olur.
+ Partition Switch desteği, özellikle arşivleme vb. amaçlarla tablolarında Partition yapısını kullanan firmalar için güzel oldu.
- Heterojen ortamlardaki destek çok düşük.
- (İddiaya göre) yeterince hızlı değil.
Sybase Replication Server:
+ Eğer büyük bir firmada iseniz veya küçük ama çeşitli bir ortamınız varsa heterojenliğe olan desteğin ne kadar önemli olduğunu bilirsiniz. Bu açıdan Sybase Replication Server yeterince destek sağlayabiliyor.
+ (İddiaya göre )SQL Server Replication'dan daha hızlı.
- Partition Switch desteği yok.
- Ekstra lisans maliyeti söz konusu. Bununla birlikte personelin de bu yeni ürün için eğitim ihtiyacı oluşacak. Yeterli know-how'ın oluşması da vakit alacak ve bu süreçte zorluk çekilecek.
- Sybase Replication Server ürününün şu anda Türkiye'de SQL Server ile birlikte kullanıldığına dair referans olarak gösterilebileceği bir ortam yok ne yazık ki. Bu da ürün konusunda etrafınızda danışabileceğiniz birilerini bulmanın zorluğunu işaret ediyor. Google'da aradığımda hakkında bir şey bulamadığım üründen pek haz etmiyorum açıkçası...
Önceden birçok kere SQL Server Replication kurdum ve yönettim, Oracle Golden Gate'i de bulunduğum firmada 2 senedir ben kurup yönetiyorum, her türlü sorunuyla da (ITD ve Oracle Support'un da destekleriyle) ben uğraşıyorum. Şimdi de bugüne kadar edindiğim deneyimlere göre SQL Server Replication ile Oracle Golden Gate'in karşılaştırmasını yapmak istiyorum.
Bu sefer öncelikle madde madde iki ürünün birbirlerine olan artı ve eksilerinden bahsedeyim.
Oracle Golden Gate:
+ Transaction Log Backup'lardan, Transaction Log dosyasında bulunmayan kayıtları okuyabiliyor. Şu anda piyasada bildiğimiz kadarıyla bunu yapabilen başka bir uygulama yok.
+ Index bakımı yapılan zamanlarda (5-6 saatte 850GB Transaction Log yedek dosyası oluştuğunu düşünün) biraz yavaşlasa da, genel anlamda oldukça hızlı. Gündüz çalışması esnasında çok ender 1 dakikanın üzerinde gecikme yaşıyoruz.
+ Golden Gate ürünü geçen sene sanıyorum Ekim veya Kasım ayındaydı, Oracle tarafından satın alındı. Bunun hem artı hem de eksi yanları olduğunu düşünüyorum. Sonuçta Oracle ve Microsoft'un çok iyi anlaşamadığı genel olarak bilinir, ama tabii ki ticari çıkarlar söz konusu olunca orta yolu da buluyorlar. Bu mânâda özellikle ilk satın alma sonrası zor zamanlar geçirdik, ama bu noktadan sonra artı kısmını yaşayacağımızı düşünüyorum, çünkü Oracle sonuçta çok güçlü bir firma ve bu ürünü daha güçlü desteklemesini bekliyorum.
- DDL değişikliklerini aktarmıyor.
- Partition Switch desteği yok.
- Ürünün varsayılan arayüzü Komut İstemcisinden (Command Prompt) çalışıyor. Kendi dili ve sistemi var haliyle. Bunları öğrenmek deneyimli mühendisler için bir zaman alabilir. Google'da Golden Gate için de herhangi bir bilgiye ulaşmak çok zor.
- Lisans ücretleri çok yüksek.
SQL Server Replication:
+ DDL değişikliklerini aktarabiliyor.
+ Partition Switch desteği var.
+ Ekstra lisansa gerek yok.
+ Yukarıda Sybase için belirttiğim gibi, ekstra eğitim masrafına genelde gerek kalmıyor. Ayrıca Google'da SQL Server Replication konusunda okuyamayacağınız kadar çok Microsoft dokümanına, Blog'a ve Forum mesajlarına ulaşabilirsiniz.
- Maalesef Transaction Log Backup'lardan okuma işlemi yapamıyor.
- Golden Gate'ten daha hızlı çalışmıyor.
Sonuç olarak Sybase Replication Server'ın büyük bir artısını göremedim ben. Oracle Golden Gate ile karşılaştırınca tercih etmeyi düşünmeyeceğim bir ürün. Oracle Golden Gate'i de SQL Server ile karşılaştırınca yukarıda da gördüğünüz gibi birçok eksi tarafı var, ama özellikle Transaction Log Backup'lardan veri okuyabilmesi ölümcül derecede önemli. Çünkü bu özellik olmadığında (ki diğer iki üründe yok) kaynaktan veri okuyan Agent (bu her üründe farklı isimlendiriliyor, örneğin Oracle Golden Gate için Extract) hata verdiğinde, eğer bu özellik olmazsa Transaction Log dosyası Recovery Model'i SIMPLE bile olsa, defalarca Transaction Log Backup'ı da alınsa Truncate edilemez (yani içi boşaltılamaz). Bu da üretim sisteminizi (Production) büyük tehlikeye atar. İlk etapta eğer Transaction Log diskinizde yeterince boş alan varsa ve bu dosyanın mantıksal AutoGrowth ayarı sınırsızsa ilk önce disk dolmaya başlar ve ardından herhangi yeni bir işlem yapılamaz. Daha sonra bu işin içinden çıkmak gerçekten çok baş ağrıtıcı olabiliyor, başıma gelmişti... Oracle Golden Gate bu konuda tamamen kusursuz değil, ama eğer bu ürünle de bu şekilde biraz tecrübe edinebilirseniz, bunlarla nasıl başaçıkabileceğinizi öğreniyorsunuz. Fakat ne SQL Server Replication'da ne de Sybase Replication Server'da, ancak yeniden Initial Load, Snapshot Initialization vs. yaparak sistemin prangalarını çözebilirsiniz; tabii ki patlama sorunu çözmüş olmazsınız, o tamamen ayrı bir konu.
Eğer bir gün kullanacak olursanız, ortamlarınızda yapacağınız POC testlerine sırtlarınızı tamamen dayamayın. Emin olun POC'de göreceğiniz sadece size fikir verecektir. Daha sonrasında türlü türlü sorunlarla karşılaşabilirsiniz. Tavsiyem, bu ürünler için referans isteyin ve esas kullanıcılarıyla konuşun. Size ürünü en iyi onlar anlatacaktır.
Kolay gelsin,
Ekrem
Bu kapsamda geçen ayın son günlerinde Sybase Türkiye'den Evren Tokçelik (Teknik Danışman) ve Borga Kaşdoğan (Satış Yöneticisi) bize Sybase'in Replication ürünü olan Replication Server ürününü tanıttı.
Adından da anlaşılabileceği üzere Sybase Replication Server, temel olarak A noktasında bulunan verilerin heterojen (farklı RDBMS'lerden farklı RDBMS'lere) B, C .. ortamlarına aktarılması amacıyla kullanılabilecek bir Replikasyon (veri aktarımı) uygulaması. Bu uygulamanın temel olarak yaptığı şey Oracle Golden Gate veya SQL Server Replication'ın yaptığı şey olan veri aktarımı. Bazı arkadaşlarımın aklına Database Mirroring ile Log Shipping de veri aktarımı için kullanılabilir gibi bir fikir gelebilir, tabii ki öyle, ama hepsi de farklı ihtiyaçlara göre farklı durumlarda kullanılır ve bu konulara önceden zaten çok değinmiştik, o yüzden bu yazıda bu teknolojilerden bahsetmeyeceğim.
Bu yazımda daha ziyade doğrudan SQL Server Replication, Oracle Golden Gate ve Sybase Replication Server'ı karşılaştırıp size bir fikir vermek istiyorum.
Birbirine daha yakın olduklarından dolayı öncelikle SQL Server Replication ve Sybase Replication Server arasındaki ufak farklardan bahsedeyim:
Sybase Replication Server'ın, SQL Server Replication'a karşı olan en temel üstünlüğü heterojen ortamlardaki desteği. Birçok farklı RDBMS'ten birçok farklı diğer RDBMS'e veri aktarma özelliği bulunuyor, SQL Server Replication'ın ise bu konudaki desteği çok kısıtlı. Sybase Replication Server'ın bir başka özelliği ise (biz bu konuda herhangi bir POC testi yapmadık, bu nedenle vurgulamak istiyorum ki bu konuda tabiri caizse Evren ve Borga'nın yalancısıyım) SQL Server Replication'dan daha hızlı olması. Fakat elimizde bu konuda bir dokümantasyon, karşılaştırma, Benchmark vs. bulunmuyor. Bununla birlikte, SQL Server (Transactional) Replication'ın (SQL Server 2008'den itibaren) Partition Switch desteği bulunuyor, fakat Sybase Replication Server her ne kadar DDL değişikliklerini aktarma özelliğini barındırsa da, Partition Switch işlemini desteklemiyor ne yazık ki.
Bu karşılaştırma sonrasında bir iki maddede şöyle diyebilirim:
SQL SERVER Replication :
+ SQL Server Replication ek bir maliyet gerektirmiyor. Ayrıca ürün ve destek ekibi aynı olduğundan dolayı, destek konusundaki maliyetler de düşük olur.
+ Partition Switch desteği, özellikle arşivleme vb. amaçlarla tablolarında Partition yapısını kullanan firmalar için güzel oldu.
- Heterojen ortamlardaki destek çok düşük.
- (İddiaya göre) yeterince hızlı değil.
Sybase Replication Server:
+ Eğer büyük bir firmada iseniz veya küçük ama çeşitli bir ortamınız varsa heterojenliğe olan desteğin ne kadar önemli olduğunu bilirsiniz. Bu açıdan Sybase Replication Server yeterince destek sağlayabiliyor.
+ (İddiaya göre )SQL Server Replication'dan daha hızlı.
- Partition Switch desteği yok.
- Ekstra lisans maliyeti söz konusu. Bununla birlikte personelin de bu yeni ürün için eğitim ihtiyacı oluşacak. Yeterli know-how'ın oluşması da vakit alacak ve bu süreçte zorluk çekilecek.
- Sybase Replication Server ürününün şu anda Türkiye'de SQL Server ile birlikte kullanıldığına dair referans olarak gösterilebileceği bir ortam yok ne yazık ki. Bu da ürün konusunda etrafınızda danışabileceğiniz birilerini bulmanın zorluğunu işaret ediyor. Google'da aradığımda hakkında bir şey bulamadığım üründen pek haz etmiyorum açıkçası...
Önceden birçok kere SQL Server Replication kurdum ve yönettim, Oracle Golden Gate'i de bulunduğum firmada 2 senedir ben kurup yönetiyorum, her türlü sorunuyla da (ITD ve Oracle Support'un da destekleriyle) ben uğraşıyorum. Şimdi de bugüne kadar edindiğim deneyimlere göre SQL Server Replication ile Oracle Golden Gate'in karşılaştırmasını yapmak istiyorum.
Bu sefer öncelikle madde madde iki ürünün birbirlerine olan artı ve eksilerinden bahsedeyim.
Oracle Golden Gate:
+ Transaction Log Backup'lardan, Transaction Log dosyasında bulunmayan kayıtları okuyabiliyor. Şu anda piyasada bildiğimiz kadarıyla bunu yapabilen başka bir uygulama yok.
+ Index bakımı yapılan zamanlarda (5-6 saatte 850GB Transaction Log yedek dosyası oluştuğunu düşünün) biraz yavaşlasa da, genel anlamda oldukça hızlı. Gündüz çalışması esnasında çok ender 1 dakikanın üzerinde gecikme yaşıyoruz.
+ Golden Gate ürünü geçen sene sanıyorum Ekim veya Kasım ayındaydı, Oracle tarafından satın alındı. Bunun hem artı hem de eksi yanları olduğunu düşünüyorum. Sonuçta Oracle ve Microsoft'un çok iyi anlaşamadığı genel olarak bilinir, ama tabii ki ticari çıkarlar söz konusu olunca orta yolu da buluyorlar. Bu mânâda özellikle ilk satın alma sonrası zor zamanlar geçirdik, ama bu noktadan sonra artı kısmını yaşayacağımızı düşünüyorum, çünkü Oracle sonuçta çok güçlü bir firma ve bu ürünü daha güçlü desteklemesini bekliyorum.
- DDL değişikliklerini aktarmıyor.
- Partition Switch desteği yok.
- Ürünün varsayılan arayüzü Komut İstemcisinden (Command Prompt) çalışıyor. Kendi dili ve sistemi var haliyle. Bunları öğrenmek deneyimli mühendisler için bir zaman alabilir. Google'da Golden Gate için de herhangi bir bilgiye ulaşmak çok zor.
- Lisans ücretleri çok yüksek.
SQL Server Replication:
+ DDL değişikliklerini aktarabiliyor.
+ Partition Switch desteği var.
+ Ekstra lisansa gerek yok.
+ Yukarıda Sybase için belirttiğim gibi, ekstra eğitim masrafına genelde gerek kalmıyor. Ayrıca Google'da SQL Server Replication konusunda okuyamayacağınız kadar çok Microsoft dokümanına, Blog'a ve Forum mesajlarına ulaşabilirsiniz.
- Maalesef Transaction Log Backup'lardan okuma işlemi yapamıyor.
- Golden Gate'ten daha hızlı çalışmıyor.
Sonuç olarak Sybase Replication Server'ın büyük bir artısını göremedim ben. Oracle Golden Gate ile karşılaştırınca tercih etmeyi düşünmeyeceğim bir ürün. Oracle Golden Gate'i de SQL Server ile karşılaştırınca yukarıda da gördüğünüz gibi birçok eksi tarafı var, ama özellikle Transaction Log Backup'lardan veri okuyabilmesi ölümcül derecede önemli. Çünkü bu özellik olmadığında (ki diğer iki üründe yok) kaynaktan veri okuyan Agent (bu her üründe farklı isimlendiriliyor, örneğin Oracle Golden Gate için Extract) hata verdiğinde, eğer bu özellik olmazsa Transaction Log dosyası Recovery Model'i SIMPLE bile olsa, defalarca Transaction Log Backup'ı da alınsa Truncate edilemez (yani içi boşaltılamaz). Bu da üretim sisteminizi (Production) büyük tehlikeye atar. İlk etapta eğer Transaction Log diskinizde yeterince boş alan varsa ve bu dosyanın mantıksal AutoGrowth ayarı sınırsızsa ilk önce disk dolmaya başlar ve ardından herhangi yeni bir işlem yapılamaz. Daha sonra bu işin içinden çıkmak gerçekten çok baş ağrıtıcı olabiliyor, başıma gelmişti... Oracle Golden Gate bu konuda tamamen kusursuz değil, ama eğer bu ürünle de bu şekilde biraz tecrübe edinebilirseniz, bunlarla nasıl başaçıkabileceğinizi öğreniyorsunuz. Fakat ne SQL Server Replication'da ne de Sybase Replication Server'da, ancak yeniden Initial Load, Snapshot Initialization vs. yaparak sistemin prangalarını çözebilirsiniz; tabii ki patlama sorunu çözmüş olmazsınız, o tamamen ayrı bir konu.
Eğer bir gün kullanacak olursanız, ortamlarınızda yapacağınız POC testlerine sırtlarınızı tamamen dayamayın. Emin olun POC'de göreceğiniz sadece size fikir verecektir. Daha sonrasında türlü türlü sorunlarla karşılaşabilirsiniz. Tavsiyem, bu ürünler için referans isteyin ve esas kullanıcılarıyla konuşun. Size ürünü en iyi onlar anlatacaktır.
Kolay gelsin,
Ekrem
SQL Server & Oracle Golden Gate: WARNING OGG-00091 VAM Client Report <[TruncMgr::Timer] Unable to execute procedure. The database is not published. Ex
Merhaba,
Son zamanlarda Oracle Golden Gate ile yaşadığım bir sorunu paylaşmak istiyorum sizlerle.
Bu sorunda maalesef başka çeşitli ürünlerde de yaşayabildiğim hatalı hata mesajı sorununu yaşadım. Tabii ki karşıma çıkan hata mesajının çok yanıltıcı olduğunu, sorunu tespit edince anladım.
Hata mesajı şuydu:
"WARNING OGG-00091 VAM Client Report <[TruncMgr::Timer] Unable to execute procedure. The database is not published. Execute the procedure in a database that is published for replication. Error (-2147217900): Unable to execute procedure. The database is not published. Execute the procedure in a database that is published for replication."
Bu hatayı, kaynak sunucuda Extract'ı başlattıktan kısa bir süre sonra Extract'ın Report dosyasında (dirrpt klasöründeki) görüyordum. Bununla birlikte Extract ABENDED veya STOPPED durumlarına gelmiyor, hâlâ RUNNING görünüyordu.
Sorunu yeniden oluşturmak için şöyle bir yol izleyebilirsiniz:
- Yeni bir Extract ekleyin (ADD EXTRACT).
- Extract'ın parametre dosyasını ihtiyacınıza göre düzenleyin, yalnız ODBC adını başka bir veritabanına giden bir ODBC adı olarak verin (evet, bizim durumumuzdaki sorun buydu). Örneğin Extract işlemini yapacağınız veritabanı XXX, ama o Extract'ın parametre dosyasında kullanılan ODBC'deki veritabanı YYY.
- Başarılı bir şekilde DBLOGIN SOURCEDB ile o ODBC'ye bağlanın.
- Yine başarılı bir şekilde ADD TRANDATA ile, Extended Logging'i etkinleştirmek istediğiniz tablolar bu işlemi gerçekleştirin.
- Extract'ı çalıştırın.
Yukarıdaki işlemleri gerçekleştirdikten sonra Extract'ın Report dosyasında bu hatayı göreceksiniz.
Biz bu hata konusunda Oracle Support ile birlikte çalıştık ve neredeyse 1 ay sonra, o da kazayla başka bir şeye bakarken sorunun bu olduğunu gördük. Gördüğünüz gibi hata mesajının sorunun kendisiyle doğrudan hiçbir ilgisi yok. Hata mesajına bakınca gidip CDC'yi veya başka bilumum şeyi kontrol etmek geliyor akla, ama ODBC adını Extract parametre dosyasında doğru mu yanlış mı yazdığınızı kontrol etmek gelmiyor maalesef.
Kolay gelsin,
Ekrem
Son zamanlarda Oracle Golden Gate ile yaşadığım bir sorunu paylaşmak istiyorum sizlerle.
Bu sorunda maalesef başka çeşitli ürünlerde de yaşayabildiğim hatalı hata mesajı sorununu yaşadım. Tabii ki karşıma çıkan hata mesajının çok yanıltıcı olduğunu, sorunu tespit edince anladım.
Hata mesajı şuydu:
"WARNING OGG-00091 VAM Client Report <[TruncMgr::Timer] Unable to execute procedure. The database is not published. Execute the procedure in a database that is published for replication. Error (-2147217900): Unable to execute procedure. The database is not published. Execute the procedure in a database that is published for replication."
Bu hatayı, kaynak sunucuda Extract'ı başlattıktan kısa bir süre sonra Extract'ın Report dosyasında (dirrpt klasöründeki) görüyordum. Bununla birlikte Extract ABENDED veya STOPPED durumlarına gelmiyor, hâlâ RUNNING görünüyordu.
Sorunu yeniden oluşturmak için şöyle bir yol izleyebilirsiniz:
- Yeni bir Extract ekleyin (ADD EXTRACT).
- Extract'ın parametre dosyasını ihtiyacınıza göre düzenleyin, yalnız ODBC adını başka bir veritabanına giden bir ODBC adı olarak verin (evet, bizim durumumuzdaki sorun buydu). Örneğin Extract işlemini yapacağınız veritabanı XXX, ama o Extract'ın parametre dosyasında kullanılan ODBC'deki veritabanı YYY.
- Başarılı bir şekilde DBLOGIN SOURCEDB ile o ODBC'ye bağlanın.
- Yine başarılı bir şekilde ADD TRANDATA ile, Extended Logging'i etkinleştirmek istediğiniz tablolar bu işlemi gerçekleştirin.
- Extract'ı çalıştırın.
Yukarıdaki işlemleri gerçekleştirdikten sonra Extract'ın Report dosyasında bu hatayı göreceksiniz.
Biz bu hata konusunda Oracle Support ile birlikte çalıştık ve neredeyse 1 ay sonra, o da kazayla başka bir şeye bakarken sorunun bu olduğunu gördük. Gördüğünüz gibi hata mesajının sorunun kendisiyle doğrudan hiçbir ilgisi yok. Hata mesajına bakınca gidip CDC'yi veya başka bilumum şeyi kontrol etmek geliyor akla, ama ODBC adını Extract parametre dosyasında doğru mu yanlış mı yazdığınızı kontrol etmek gelmiyor maalesef.
Kolay gelsin,
Ekrem
25 Mayıs 2011 Çarşamba
More VRP
Uzun bir aradan sonra, henüz bugün tanımını aldığımız More VRP yazılımından bahsetmek istiyorum sizlere. Bu uygulamadan size, bize sunumu yapan Michael Rozhkovsky gibi ayrıntılı bir şekilde bahsetmeyeceğim tabii ki. Fakat Veritabanı Yöneticiliği yapan ve kritik noktalarda görevli kişilerin bu konuda bilgisi olmasını istediğim için bu uygulamadan kısa da olsa bahsetmek istedim.
More VRP, temel olarak bir Kriz Yönetim uygulaması ve yine temel olarak yaptığı şey ise İşlem Yönetimi (Transaction Management). Bu uygulamanın henüz piyasada bir eşi benzeri olmadığını da vurgulamak isterim, en azından firmanın bize verdiği bilgi bu yönde. Uygulamanın Türkiye'deki distribütörü ise Aktek Bilgi İletişim Tek. San. Tic. A.Ş.
Uygulamanın izleme modülüyle, sistemde çalışan tüm işlemleri görebiliyorsunuz. CPU, IO masraflarını ve bu işlemlere ait birçok ayrıntıyı anlık bilgilerle izleyebiliyorsunuz. Ayrıca bu arayüzü birçok grafiklerle de süslemişler.
Bu bahsettiğim şeyler elbette bu uygulamayı eşsiz yapan bir özellik değil, bu uygulamayı eşsiz yapan ve patenti sadece bu firmada bulunan ve tabii ki bizi de büyüleyen özelliği ise, seçtiğiniz sorguların CPU ve IO masraflarını anlık olarak daraltabilmeniz.
Bir örnek vermek gerekirse: örneğin ortamınızda iki tane sorgu çalışıyor, biri CPU kaynağının %30'unu, diğeri de %50'sini harcıyor diyelim. Bu sorgulardan herhangi birini seçerek, o anda harcıyor olduğu kaynakların değerini %30'dan %10'a anlık olarak çekebiliyorsunuz. Bu işlem saniyeler içerisinde gerçekleşiyor. Dediğim gibi, bu teknolojinin patenti sadece merkezi İsrail'de olan bu firmaya ait.
Uygulamanın Console denilen bölümü ayrı bir sunucuya kuruluyor. Bu sunucu öyle ahım şahım bir şey olmak zorunda değil. 4GB RAM'i olan PC gibi bir makine olabilir. Console ise takip edilecek sunucularla bir Agent vasıtasıyla haberleşiyor. Agent ise bir CPU'nun sadece %0.5'i kadar kaynak tüketiyor en fazla. Çünkü tüm işi yapan Console. Bu yüzden üretim sunucularınıza ek yük getirecek bir durum da söz konusu değil.
Ayrıca sistem Cluster\RAC yapılarını da destekliyor. Failover anlarında geçişler otomatik ve yöneticilere hissettirilmeden yapılıyor. RDBMS tarafındaki kesintilerin sonuna kadar hissedilmesi ise tabii ki ayrı bir konu.
Yine bize verilen bilgilere göre bu uygulamayı İsrail'de çok büyük Telekom ve Banka firmaları da dahil 400 firma kullanıyor, dünya çapında ise 600 firma. Önceden Oracle Golden Gate ile ilgili böyle bir facia yaşadığımız için haliyle hemen Türkiye'de bu ürünü SQL Server üretim ortamlarında kullanan olup olmadığını sordum, Aktek'ten arkadaşlar bana olumsuz yanıt verdiler. Onlar da 1 senedir bu uygulamayı Türkiye'de temsil ediyorlarmış ve bu süreçte birçok firmada POC (Proff of Concept) çalışması yapmışlar, fakat henüz üretim ortamında ürünü kullanan yok.
Açıkçası ürün benim oldukça ilgimi çekti. Kriz durumlarında sorun yaratan sorguları, SP'leri vb. dizginleyebilmek ve sorunu çözünceye kadar bu işlemleri belli sınırlar içinde tutabilmek oldukça mantıklı ve makul. Sorun çözülünce sınırlamaları kaldırmak da çok kolay.
Tabii ki ürünün başka birçok özellikleri de var, örneğin ne kadar isterseniz o kadar geçmişe dönük sorguları ve masraflarını saklayabilmek, yanyana sürüm yükseltme (Side by Side Upgrade) sonrasında iki sunucuyu karşılaştırıp kazanım ve kayıpları gösterebilmek, bir gün öncesi ve sonrası veya başka tarih aralıklarında gerçekleşen sistem değişikliklerini veritabanı bazında listeleyebilmek, değişen Execution Plan'ları çok rahat bir şekilde belirleyebilmek gibi...
Son olarak şunu söylemeliyim ki ürün sadece SQL Server ile çalışmıyor. Oracle, DB2 gibi RDBMS'leri de destekliyor. Ayrıca OS olarak da Platform Bağımsız bir ürün.
SQL Server'a özel olarak ise, SQL Server'ın sadece 2005 ve 2008 özelliklerini destekliyor şu anda. SQL Server 2008 R2 desteği henüz yok. SQL Server 2000 için ise Microsoft ile iş birliği yapmak istemişler, fakat Microsoft SQL Server 2000'i biz bile desteklemiyoruz artık demiş, gerisini siz düşünün.
Umarım ürün hakkında az çok fikir edinebilmenize yardımcı olur bu bilgiler.
Ekrem Önsoy
More VRP, temel olarak bir Kriz Yönetim uygulaması ve yine temel olarak yaptığı şey ise İşlem Yönetimi (Transaction Management). Bu uygulamanın henüz piyasada bir eşi benzeri olmadığını da vurgulamak isterim, en azından firmanın bize verdiği bilgi bu yönde. Uygulamanın Türkiye'deki distribütörü ise Aktek Bilgi İletişim Tek. San. Tic. A.Ş.
Uygulamanın izleme modülüyle, sistemde çalışan tüm işlemleri görebiliyorsunuz. CPU, IO masraflarını ve bu işlemlere ait birçok ayrıntıyı anlık bilgilerle izleyebiliyorsunuz. Ayrıca bu arayüzü birçok grafiklerle de süslemişler.
Bu bahsettiğim şeyler elbette bu uygulamayı eşsiz yapan bir özellik değil, bu uygulamayı eşsiz yapan ve patenti sadece bu firmada bulunan ve tabii ki bizi de büyüleyen özelliği ise, seçtiğiniz sorguların CPU ve IO masraflarını anlık olarak daraltabilmeniz.
Bir örnek vermek gerekirse: örneğin ortamınızda iki tane sorgu çalışıyor, biri CPU kaynağının %30'unu, diğeri de %50'sini harcıyor diyelim. Bu sorgulardan herhangi birini seçerek, o anda harcıyor olduğu kaynakların değerini %30'dan %10'a anlık olarak çekebiliyorsunuz. Bu işlem saniyeler içerisinde gerçekleşiyor. Dediğim gibi, bu teknolojinin patenti sadece merkezi İsrail'de olan bu firmaya ait.
Uygulamanın Console denilen bölümü ayrı bir sunucuya kuruluyor. Bu sunucu öyle ahım şahım bir şey olmak zorunda değil. 4GB RAM'i olan PC gibi bir makine olabilir. Console ise takip edilecek sunucularla bir Agent vasıtasıyla haberleşiyor. Agent ise bir CPU'nun sadece %0.5'i kadar kaynak tüketiyor en fazla. Çünkü tüm işi yapan Console. Bu yüzden üretim sunucularınıza ek yük getirecek bir durum da söz konusu değil.
Ayrıca sistem Cluster\RAC yapılarını da destekliyor. Failover anlarında geçişler otomatik ve yöneticilere hissettirilmeden yapılıyor. RDBMS tarafındaki kesintilerin sonuna kadar hissedilmesi ise tabii ki ayrı bir konu.
Yine bize verilen bilgilere göre bu uygulamayı İsrail'de çok büyük Telekom ve Banka firmaları da dahil 400 firma kullanıyor, dünya çapında ise 600 firma. Önceden Oracle Golden Gate ile ilgili böyle bir facia yaşadığımız için haliyle hemen Türkiye'de bu ürünü SQL Server üretim ortamlarında kullanan olup olmadığını sordum, Aktek'ten arkadaşlar bana olumsuz yanıt verdiler. Onlar da 1 senedir bu uygulamayı Türkiye'de temsil ediyorlarmış ve bu süreçte birçok firmada POC (Proff of Concept) çalışması yapmışlar, fakat henüz üretim ortamında ürünü kullanan yok.
Açıkçası ürün benim oldukça ilgimi çekti. Kriz durumlarında sorun yaratan sorguları, SP'leri vb. dizginleyebilmek ve sorunu çözünceye kadar bu işlemleri belli sınırlar içinde tutabilmek oldukça mantıklı ve makul. Sorun çözülünce sınırlamaları kaldırmak da çok kolay.
Tabii ki ürünün başka birçok özellikleri de var, örneğin ne kadar isterseniz o kadar geçmişe dönük sorguları ve masraflarını saklayabilmek, yanyana sürüm yükseltme (Side by Side Upgrade) sonrasında iki sunucuyu karşılaştırıp kazanım ve kayıpları gösterebilmek, bir gün öncesi ve sonrası veya başka tarih aralıklarında gerçekleşen sistem değişikliklerini veritabanı bazında listeleyebilmek, değişen Execution Plan'ları çok rahat bir şekilde belirleyebilmek gibi...
Son olarak şunu söylemeliyim ki ürün sadece SQL Server ile çalışmıyor. Oracle, DB2 gibi RDBMS'leri de destekliyor. Ayrıca OS olarak da Platform Bağımsız bir ürün.
SQL Server'a özel olarak ise, SQL Server'ın sadece 2005 ve 2008 özelliklerini destekliyor şu anda. SQL Server 2008 R2 desteği henüz yok. SQL Server 2000 için ise Microsoft ile iş birliği yapmak istemişler, fakat Microsoft SQL Server 2000'i biz bile desteklemiyoruz artık demiş, gerisini siz düşünün.
Umarım ürün hakkında az çok fikir edinebilmenize yardımcı olur bu bilgiler.
Ekrem Önsoy
Kaydol:
Kayıtlar (Atom)