HATA:
Error 14274: Cannot add, update, or delete a job (or its steps or schedules) that originated from an MSX server. The job was not saved.
AÇIKLAMA:
SQL Server 2000 Instance'ınızın üstünde çalıştığı Windows İşletim Sisteminin bilgisayar adını değiştirdikten sonra Job'larla çalışırken böyle bir sorun ile karşılaşabilirsiniz. Sorunun nedeni ve çözümü Microsoft KB'sinde (http://support.microsoft.com/kb/281642) anlatılıyor. O yüzden daha fazla açıklama girmeyeceğim, ama çözümü bir de Türkçe yazayım.
ÇÖZÜM:
- Bilgisayarın adını eski haline getirin.
- Job'ları tekrar oluşturabilmek için Script'lerini çıkarın ve Job'ları silin.
- Bilgisayarın adını yeni adıyla değiştirin.
- 2. adımda oluşturduğunuz Job Script'leriyle Job'ları tekrar oluşturun.
15 Ağustos 2011 Pazartesi
28 Temmuz 2011 Perşembe
"String or binary data would be truncated."
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.
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.
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
Kaydol:
Kayıtlar (Atom)