HATA:
String or binary data would be truncated.
AÇIKLAMA:
Örneğin bir SQL Server 2008 Instance'ındaki Job History'sini SQL Server 2005 Management Studio ile açmaya çalışırsanız bu hata mesajıyla karşılaşabilirsiniz:
ÇÖZÜM:
Bu tarz garip sorunlarla karşılaşmamak için her versiyonun kendi araçlarını (SSMS, Proffiler gibi) kullanmanızda fayda var. Örneğin bu sorundan kurtulmak için yapılması gereken, SQL Server 2008 Instance'ına SQL Server 2008 Management Studio ile bağlanmanızdır.
Microsoft SQL Server ve Microsoft SQL Server ile ilgili diğer uygulamalar, araçlar ve haberlerle ilgili Türkçe içeriği bu günlükte bulabilirsiniz.
28 Temmuz 2011 Perşembe
22 Temmuz 2011 Cuma
"The report server database is an invalid version."
HATA:
"The report server database is an invalid version."
AÇIKLAMA:
Reporting Services'a bağlanmaya çalıştığınızda Windows Application Event Log'unda böyle bir hata mesajı görebilirsiniz. Event ID: 117, Type: Error.
ÇÖZÜM:
Bu hata, Reporting Services'in kurulumundan sonra, yapılandırılmasının gerçekleştirilmemesinden kaynaklanıyor. Yapılandırmayı gerçekleştirmek için Reporting Services Configuration aracını kullanmanız gerekiyor. Bu araç ile Report Manager Virtual Directory, Windows Service Identity, Database Setup gibi tüm ayarları yapmalısınız. Kırmızı yuvarlak içerisinde X kalmadığından emin olduktan sonra Reporting Services'a (örneğin SSMS ile) tekrar bağlanmayı deneyebilirsiniz.
"The report server database is an invalid version."
AÇIKLAMA:
Reporting Services'a bağlanmaya çalıştığınızda Windows Application Event Log'unda böyle bir hata mesajı görebilirsiniz. Event ID: 117, Type: Error.
ÇÖZÜM:
Bu hata, Reporting Services'in kurulumundan sonra, yapılandırılmasının gerçekleştirilmemesinden kaynaklanıyor. Yapılandırmayı gerçekleştirmek için Reporting Services Configuration aracını kullanmanız gerekiyor. Bu araç ile Report Manager Virtual Directory, Windows Service Identity, Database Setup gibi tüm ayarları yapmalısınız. Kırmızı yuvarlak içerisinde X kalmadığından emin olduktan sonra Reporting Services'a (örneğin SSMS ile) tekrar bağlanmayı deneyebilirsiniz.
20 Temmuz 2011 Çarşamba
Oracle Golden Gate & SQL Server: Extract'in takılı\asılı kalması sorunu
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
Ç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
12 Temmuz 2011 Salı
SQL Server & Oracle Golden Gate
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
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
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
Kaydol:
Kayıtlar (Atom)