SQL Server Kurulumlarında Gözden Kaçanlar - 8

Kurulum yapıldıktan sonra, özellikle de kritik veritabanı uygulamalarını barındıran SQL Server sunucularında, SQL Server açısından takibini yapmanız gereken olmazsa olmaz şeyler var. Bunlardan temel olarak bazıları:

- CPU kullanımı (Ortalama İşlemci Kullanımı)
- RAM kullanımı (Plan Cache ve Data Buffer Cache Hit Ratio, Available Memory, Page Life Expectancy gibi)
- Disk performansı (Ortalama Disk Queue Length, Disk Idle, Disk Response Time gibi)
- Disk kullanımı (doluluk oranları)
- Veritabanı veri ve Transaction Log dosyaları için doluluk oranları
- SQL Error Log dosyasının içindeki hatalar
- Deadlock takibi
- Blocking takibi
- Uzun süren, maliyetli işlemlerin takibi
- (Varsa) Log Shipping, Database Mirroring, Replication gibi sistemlerin çalışırlığı, senkronizasyon sürelerindeki gecikmeler gibi (meselâ Heartbeat yöntemleri kullanarak)
- (Varsa) SQL Server Failover Clustering'teki pasif düğümlerinizin durumu (meselâ Ping'leyerek)

Bu takipler çoğu zaman 3. parti uygulamalarla gerçekleştiriliyor. Fakat bütçesi müsait olmayan firmalarda bu takiplerin birçoğu, ücretli uygulamalar olmadan da gerçekleştirilebilir. Bazılarının takibi için bazı icatlar yapmıştım, bazılarını ise şirkette kullandığımız 3. parti uygulamalarla yapıyoruz. Yavaş yavaş, bu takipleri olabildiğince 3. parti ücretli uygulamalara para ödemeden nasıl yapabileceğiniz hakkında yazılar yazmaya çalışacağım; tabii ki her şeyi 3. parti uygulama olmadan çözmek mümkün veya pratik olmayabilir, bunları da ayrıca anlatmaya çalışacağım.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7

SQL Server Kurulumlarında Gözden Kaçanlar - 7

SQL Server kurulumlarından sonra yapılması gereken şeylerden biri de TEMPDB veritabanının DATA dosyalarının sayısının CPU (CORE) sayısına göre çoğaltılmasıdır.

Örneğin 8 çekirdekli bir işlemciye sahip olan bir sunucunuz var, o zaman TEMPDB için toplam 8 tane DATA dosyası oluşturmanız uygun olacaktır. Transaction Log dosyasının sayısını ise seri şekilde işlendiğinden dolayı istisnai durumlar haricinde gerekmediği zaman çoğaltmaya gerek yoktur.

Ayrıca yapılan testlere göre işlemci sayısı 16'yı geçse bile, 16'dan fazla TEMPDB dosyası oluşturmamak gerekiyor. Yani üst sınırınız şimdilik 16.

DATA dosyalarını oluştururken tüm dosyaların boyutlarının aynı olduğundan emin olun. Örneğin sistem veritabanları için 50GB'lık bir disk ayırdıysanız ve sunucunuzda 16 CPU varsa, o zaman 16 tane dosya oluşturun ve hepsinin boyutunu da 512MB veya 1GB olarak ayarlayın. Bunu ihtiyacınıza göre değiştirebilirsiniz, fakat bir dosyanın boyutu ne olacaksa, diğerleri de aynı olmalıdır. Transaction Log dosyasının boyutu ise farklı olabilir, bunu da yine ihtiyacınıza göre ayarlarsınız. Maksat, işlemlerin dosyalara eşit şekilde yayılmasını sağlamak ve paralellikten faydalanmak ve dosyaların sürekli bir şekilde büyümesini engelleyip performans kaybının oluşmasını önlemek.

Dosyaları oluştururken dikkate almanız gereken şey ise büyüklükleri ve artış oranları. Dosyaları oluştururken varsayılan olarak 3MB değil büyüyecek şekilde bırakmayın. Bu ayarı makul bir şekilde ayarlamanız gerekiyor. Çünkü dosya büyürken yaşanan performans sıkıntılarını yaşamak istemezsiniz. Büyüme değerlerini de kontrollü bir büyüme için MB cinsinden, makul değerlerle belirlemek gerekir. Örneğin bazı durumlarda büyüme değerinin %25 olarak yapıldığını görüyoruz. Bunu şöyle düşünün, 100MB'ın %25'i 25MB; fakat 1GB'ın %25 256MB. Kestiremeyeceğiniz şekilde yaşanan büyümeler veritabanının Suspect duruma düşmesine yol açabilecek sonuçlara kadar gidebilir. Başka örneklerde de bu büyümenin 1MB gibi çok düşük bir miktarda olduğunu görebiliyoruz. Bu gibi durumlarda ise SQL Error Log'da sürekli IO ile ilgili uyarılara rastlanabilir. Ayrıca Transaction Log dosyasının büyümesi sırasında donmalar yaşanabilir, çünkü veritabanı yeni kayıtları kabul edemeyebilir.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Performance Counter'larının tekrar oluşturulması

Tam olarak ne gibi durumlarda gerçekleşiyor bilemiyorum, fakat bazı SQL Server kurulumlarından sonra sunucuda SQL Server Performance Counter'ları belki kurulumda hiç oluşturulmamış oluyor ve biz olmadıklarını sonradan fark ediyoruz, belki de herhangi bazı işlemler yüzünden bu Performance Counter'ları bir şekilde silinebiliyor.

Daha geçen gün, yine bir müşterimizde böyle bir sorun ile karşılaştım. SQL Server 2008 Failover Cluster'ın kurulu olduğu 2 düğümlü bir sistemde, makinelerden birinde SQL Server Performance Counter'ları vardı; fakat diğerinde sadece SQL Server Agent ve SQL Server Integration Services'a ait 4-5 tane Performance Counter vardı.

Bu durumda SQL Server (2005 veya 2008) Performance Counter'larını tekrar oluşturmak gerekiyor. SQL Server Performance Counter'ları ilgili SQL Server Instance'ının "BINN" klasöründeki "sqlctr.ini" isimli dosyada bulunur. Counter'ları tekrar oluşturmak için aşağıdaki yolu izleyebilirsiniz.

- Bir Command Prompt penceresi açarak Performance Counter'ları olmayan SQL Server Instance'ının "BINN" klasörüne ulaşmanız gerekiyor, örneğin: "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn".
- Halihazırda var olan (eğer varsa) sayaçlar kaldırılır. Bunun için varsayılan bir SQL Server Instance'ı (Default Instance) için aşağıdaki kod:

unlodctr MSSQLSERVER

Bir Named Instance için de aşağıdaki kod çalıştırılmalı:

unlodctr MSSQL$namedInstance

- Sonrasında ise yine ilgili SQL Server Instance'ının "BINN" klasöründe aşağıdaki kod çalıştırılmalı:

lodctr sqlctr.ini

Eğer bu komutu çalıştırdıktan sonra herhangi bir sonuç dönmüyorsa, bu komutun başarılı olarak çalıştırıldığı anlamına gelir. Ayarların etkinleştirilebilmesi için ise ilgili SQL Server servisinin yeniden başlatılması gerekir. Bu işlemden sonra SQL Server Performance Counter'larının görünmesi gerekir.

Bazı durumlarda ise "sqlctr.ini" dosyası bir şekilde bozulmuş olabiliyor. Böyle bir durumda ise, bu dosyanın sağlam bir halini, aynı versiyondaki başka bir SQL Server Instance'ının "BINN" klasöründen alıp kopyalayabilirsiniz. Böyle bir durumda ise "sqlctr.ini" dosyasındaki aşağıdaki parametreyi SQL Server Instance'ınızın adına göre düzenlemelisiniz. Aşağıdaki örnekte SQL Server Instance'ı Default Instance'tır.

[info] drivername=MSSQLServer
trusted=
symbolfile=sqlctr.h

SQL Server Kurulumlarında Gözden Kaçanlar - 6

Bazı SQL Server sunucuları veya servisleri çok uzun süre kapatıl(a)mayabiliyor. Bu durumda ise, SQL Server Error Log çok şişebiliyor ve bu da bazı sıkıntılara neden olabiliyor. Örneğin dosyanın açılması, okunması zor oluyor, pratik olmuyor. Bu nedenle ben, yeni kurulan sunucularda SQL Error Log'larının haftada bir yenilenmesi (Cycle) için bir Job oluştururum ve bu Job, aşağıdaki kodu çalıştırarak SQL Error Log'unu haftada bir kere yeniler.

EXEC sp_cycle_errorlog

Bu sayede SQL Server Error Log dosyaların boyutları hafifler ve açması, içinde bir şeyler araması ve bulması ve yönetimi kolay olur.

Ayrıca, varsayılan olarak SQL Server sadece 6 tane SQL Server Error Log tutar. 6 tanesinden sonra yeni SQL Server Error Log'lar ise, eskilerinin üzerine yazılmaya başlar.

Bu sayıyı arttırmak için SQL Server Management Studio'da aşağıdaki yolu izleyebilirsiniz:
- Object Explorer'dan ilgili SQL Server Instance'ının altından "Management"ı genişletin.
- "SQL Server Logs" öğesinin üzerinde farenin sağ tuşuna tıklayın ve "Configure" öğesine tıklayarak "Configure SQL Server Error Logs" penceresine ulaşın.
- "Maximum number of error log files:" parametresinin değerini ihtiyacınıza göre ayarlayın.

Not:Log sayısını belirlerken, diskteki boş yerinizi de göz önüne almanız önemlidir.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 5

Bir SQL Server kurulumu yaptıktan sonra, özellikle de Log Shipping kullanılacaksa veya sık yedek alınabilecek bir sunucuysa (Transaction Log yedekleri gibi) o zaman muhakkak "msdb" sistem veritabanındaki yedeklemeyle ilgili kayıtları tutan tabloların düzenli bir şekilde silinmesinde fayda vardır. Aksi takdirde "msdb" veritabanı zamanla büyüyecektir, çünkü "msdb" veritabanında en çok büyüyen tablolar yedekleme ile ilgili tablolardır.

Bu amaçla, kurulum yaptığınız ve/veya yapacağınız sunucularda çalıştırılmak üzere standart bir Script oluşturup, bu Script'i de bir Job ile, SQL Server Agent* vasıtasıyla çalıştırabilirsiniz.

Bu Script'i hazırlarken temel olarak kullanabileceğiniz bir sistem Stored Procedure (SP)'ü bulunmaktadır. Bu SP "sp_delete_backuphistory" isimli SP'dir. Bu SP hakkında daha fazla bilgi almak için Books Online'dan şu adrese bakabilirsiniz: http://msdn.microsoft.com/en-us/library/ms188328.aspx

Örnek: Aşağıdaki kod ile, 1 aydan daha eski yedekleme kayıtlarının tarihçesini "msdb" veritabanındaki ilgili tablolardan temizlemiş olursunuz.
DECLARE @tarih datetime SET @tarih = DATEADD(month, -1, getdate()) EXEC sp_delete_backuphistory @tarih

* SQL Server Express Edition'larda SQL Server Agent bulunmamaktadır. Bu durumda, oluşturacağınız Script'i bir dosyaya kaydedebilir, bu dosyayı SQLCMD ile (SQL Server'ın Command Prompt aracı), Windows Scheduler ile de zamanlayarak çalıştırabilirsiniz.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 4

Varsayılan SQL Server kurulumundan sonra yapılmasında fayda olabilecek diğer SQL Server Server ayarlarından başka diğer bazıları:

- optimize for ad hoc workloads: Bu ayar, Plan Cache'in daha verimli kullanılmasını sağlar. Sunucuya birçok Ad Hoc sorgular geliyor olabilir, fakat bunlar sadece bir kere kullanılıyor ve daha da kullanılmıyor olabilir. Bu nedenle Plan Cache verimli kullanılmıyor olabilir. Eğer "optimize for ad hoc workloads" parametresini etkinleştirirseniz, o zaman ilk defa çalıştırılan bir Batch için geçici, özet bir plan oluşturulur Plan Cache'te ve eğer aynı Batch ikinci kere gelirse, bu sefer planın tamamı Plan Cache'te tutulur ve bu sayede hafıza yönetimi daha verimli bir şekilde yapılmış olur.

Örnek:
EXEC sp_configure "optimize for ad hoc workloads", 1
RECONFIGURE

- remote admin connections: Yine SQL Server 2005 ile birlikte gelen yeni bir özellik vardır, Dedicated Administrator Connection (DAC). DAC sayesinde, bir SQL Server Instance'ında donma, yetersiz hafıza veya CPU işlem yoğunluğu gibi sorunlar olduğunda ilgili Instance'a bağlanmamız mümkündür. Bu sayede kısıtlı da olsa sorunu çözebilecek belli müdahalelerde bulunabiliriz. Fakat DAC özelliği varsayılan olarak sadece SQL Server Instance'ının kurulu olduğu makine üstünden kullanılabilir. Yani DAC'ye uzaktaki bir makineden varsayılan olarak bağlanılamaz. Şayet "remote admin connections" parametresinin değeri "1" yapılırsa, o zaman bu mümkündür.

Örnek:
EXEC sp_configure "remote admin connections", 1
RECONFIGURE

Varsayılan bir SQL Server 2005 (ve üstü) kurulumlarda yukarıda belirttiğim SQL Server Configuration parametreleri etkin değildir ve bunlar SQL Server Instance'ınızın performansını ve işlevselliğini olumsuz şekilde etkileyebilir. Ben ortamımda yaptığım kurulumlardan sonra bu özellikleri etkinleştiriyorum, eğer sizin ortamınıza da uygunsa siz de bu ayarları yapmayı düşünebilirsiniz.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 3

Varsayılan SQL Server kurulumundan sonra yapılmasında fayda olabilecek diğer SQL Server Server ayarlarından diğer bazıları:

- - max degree of parallelism: OLTP sistemler için bu parametrenin değerini "1" yapmakta, yani işlemleri seri şekilde çalışmasında fayda var. Şayet paralel çalışması gereken (Index işlemleri vb.) işlemleriniz varsa, o zaman o işlemlerde ilgili Hint'leri (örneğin Index Rebuild işlemi için MAXDOP=4 gibi) kullanmanızda fayda var.

Örnek:
EXEC sp_configure "max degree of parallelism", 1
RECONFIGURE

- max server memory (MB): İnternet ortamındaki forumlarda veya başka sosyal ortamlarda insanlardan şunu çok duyarsınız "SQL Server sunucudaki tüm RAM'i kullanıyor ve diğer uygulamalar sıkıntı çekiyorlar!". Çünkü SQL Server'ın varsayılan "max server memory (MB)" ayarı, sunucudaki tüm RAM'in kullanılmasına göre ayarlıdır. O yüzden SQL Server birden değil, ama işlem yoğunluğuna göre yavaş yavaş veya hızlı hızlı tüm RAM'i kullanmaya meyillidir. Şayet "max server memory (MB)" parametresini elle ayarlarsanız, bunu sınırlayabilirsiniz. Örneğin sunucunuzda 8GB RAM varsa ve SQL Server'ın sadece 4GB RAM kullanmasını istiyorsanız o zaman "max server memory (MB)" parametresinin değerini "4096" yapabilirsiniz.

Örnek:
EXEC sp_configure "max server memory (MB)", 4096
RECONFIGURE

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 2

Bir SQL Server Instance'ının kurulumundan sonra yapmanız gereken şeylerden biri de SQL Server Configuration ayarlarıdır. Bu ayarların çoğunu "sp_configure" isimli SP ile yapabilirsiniz.

Örneğin OLTP bir sistem için ben aşağıdaki ayarları yapıyorum:
- awe enabled: Sunucunuzun işlemci mimarisi 32Bit ise (eğer hâlâ varsa?) ve sunucuda 4GB'tan fazla RAM varsa, o zaman SQL Server bu özelliği (boot.ini dosyasına PAE* parametresini de ekleyerek) etkinleştirmek isteyebilirsiniz. Bu sayede SQL Server'ın Buffer Cache'inin 2GB'tan fazla RAM kullanmasını sağlayabilirsiniz. Aksi halde SQL Server sadece 2GB RAM kullanacaktır, sunucuda 32GB RAM olsa da.

Örnek:
EXEC sp_configure "awe enabled", 1
RECONFIGURE

- blocked process threshold (s): SQL Server 2005 ile birlikte SQL Server Profiler aracına Blocking takibi yapılabilmesi için "Blocked Process Report" isimli bir Event eklendi. Bu Event, "Errors and Warnings" başlığının altında bulunmaktadır. Bu Event kullanıldığında, Blocking takibi, "sp_configure" ile ayarlayacağınız "blocked process threshold (s)" parametresine verilen zaman bilgisine göre yapılmış olacak. Örneğin bu parametreye "5" değerini verirseniz, o zaman 5 saniyeyi geçen Blocking sorunları "Blocked Process Report" isimli Event tarafından Profiler Trace'te yakalanacaktır.

Örnek:
EXEC sp_configure "blocked process threshold (s)", 5
RECONFIGURE

Not: Devamı yarın...

* PAE parametresi hakkında ayrıntılı bilgi: KB283037 (İngilizce)

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 1

SQL Server kurulumlarının birçok kurumda SQL Server DBA'leri tarafından yapılmadığını gözlemledim. Bu kurulumlar genelde ya yazılımcılar tarafından ya da genel olarak sistem alt yapı bölümünde çalışan personel tarafından yapılıyor. Tabii hal böyle olunca, SQL Server'ın verimli ve sağlıklı çalışabilmesi için yapılması gereken birçok ayar gözden kaçıyor.

Sizlerle paylaşıyor olacağım bu kurulum ipuçlarını nihai doğru olarak almanızı beklemiyorum, bunlar benim kendi ortamıma uygun olduğu için uyguladığım pratikler. Sizlerin ortamlarının daha farklı ihtiyaçları olabilir. Bu nedenle sizlerle paylaşacağım ipuçlarının açıklamalarını da elimden geldiğince yapacağım. Sizin ortamınız için iyi gelip gelmeyeceğine de bu sayesi sizler karar verebileceksiniz.

Bu başlık silsilesiyle, ipuçlarını ayrı ayrı paylaşacağım; belki daha sonra tek bir yazı altında toparlarım.

Sunucunun mimarisine göre, kurulum yapılmadan önce SQL Server servis hesabı olarak kullanılacak hesaba Local Security Policy'de "Perform volume maintenance" hakkı verilmelidir. (Control Panel->Administrative Tools->Local Security Policy->Local Policies->User Rights Assignment)

Perform volume maintenance: Bu hak sayesinde, SQL Server için Instant File Initialization özelliğini açmış olacaksınız. Bu özellik sayesinde:
- Bir veritabanı oluştururken,
- Varolan bir veritabanına veri dosyası eklerken (bu özellik Transaction Log dosyalarında işe yaramıyor),
- Autogrowth dahil, varolan bir dosyanın boyutunu büyütürken,
- Bir veritabanını Restore ederken.

İşlemi anında gerçekleştirmiş oluyorsunuz. Aksi takdirde, yani bu özellik kullanılmadığında ise, yukarıda belirttiğim işlemler gerçekleşirken, dosya boyutu kadar sıfır, dosyanın içine yazılıyor ve dosyalar bu şekilde oluşturuluyor. Haliyle de örneğin 50GB'lık bir dosyayı yukarıda sıraladığım şekilde oluşturmak istediğinizde uzun süre beklemek durumunda kalabiliyorsunuz.
Özellikle de üretim sunucularınızda gerçekleştirmek istediğiniz işlemleri en kısa zamanda gerçekleştirmek istersiniz. Kimse bu işlemlerde vakit kaybetmek istemez. Özellikle bazı durumlar oldukça kritik olabiliyor ve bu durumlarda bu özelliğin nimetlerinden faydalanmayı kesinlikle istersiniz.

Şayet SQL Server kurulumunu zaten yaptıysanız ve bu özelliği daha sonra etkinleştirmek isterseniz, SQL Server servis hesabına bu hakkı verdikten sonra, bu özelliğin etkinleşmesi için SQL Server Database Engine servisini kapatıp tekrar başlatmanız gerekmektedir.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

Golden Gate: ERROR OGG-00868 Oracle GoldenGate Capture for ODBC, EXTRACT.prm: Supplemental logging is disabled for database 'veritabanı_adı'. To enable logging, perform the following: 1) Set 'trunc. log on chkpt.' to false. 2) Create a full backup of the database. Please refer to the "Oracle GoldenGate For Windows and UNIX Administration Guide" for details.

HATA:
ERROR OGG-00868 Oracle GoldenGate Capture for ODBC, EXTRACT.prm: Supplemental logging is disabled for database 'veritabanı_adı'. To enable logging, perform the following: 1) Set 'trunc. log on chkpt.' to false. 2) Create a full backup of the database. Please refer to the "Oracle GoldenGate For Windows and UNIX Administration Guide" for details.

AÇIKLAMA:
Bu hata oluştuğunda, ilgili Extract ABENDING duruma geliyor ve (eğer otomatik başlatma parametresi etkin değilse) duruyor. Hiçbir şey yapmanıza gerek kalmadan doğrudan Extract'ı başlatırsanız (START EXTRACT) o zaman Extract tekrar sağlıklı bir şekilde başlıyor ve Replication devam ediyor.

Biz bu sorun ile karşılaştığımızda, sorun tam da bu şekilde açıkladığım gibiydi. Yani aslında veritabanının "Supplemental Logging"inin Disabled duruma getirildiği falan yoktu. Fakat yine de Golden Gate bu hatayı vererek ABENDING duruma düşüp kapanıyordu zaman zaman. Bu konuda Oracle'a SR (Service Request) açtık ve onlar da bu konuda bir yama çıkardılar. Yeni versiyonu kullandıktan sonra bu hata ile karşılaşmadık.

Siz de sorunu çözmek için yeni bir versiyon kullanmayı deneyebilirsiniz. Örneğin: 11.1.1.1.2_01

Ekrem

Golden Gate: ERROR OGG-00146 Oracle GoldenGate Capture for ODBC, EXTRACT.prm: VAM function VAMInitialize returned unexpected result: error 600 - VAM Client Report .

HATA:
ERROR OGG-00146 Oracle GoldenGate Capture for ODBC, EXTRACT.prm: VAM function VAMInitialize returned unexpected result: error 600 - VAM Client Report .

AÇIKLAMA:
Bu sorun üstünde Oracle Support ile çok uzun süre çalıştık. Sorunun ne olduğunu bulamadılar, bir gün şansa biz bulduk. Bu sorun oluştuğunda ilk başlarda Extract'ın parametre dosyasında ALTARCHIVELOGDEST parametresini kullanıyor ve sorunu geçici savuşturuyorduk. Bu geçici çözümü de şansa bulmuştuk yine.

ALTARCHIVELOGDEST parametresi oldukça masraflı bir parametre. Bu parametre kullanıldığında, Transaction Log Backup kayıtlarında ve Online Transaction Log dosyasında bulunamayan LSN; tüm Transaction Log Backup dosyaları taranarak bir şekilde bulunuyordu. Daha sonra öğrendik ki, normal şartlar altında Golden Gate, SQL Server'ın sistem veritabanı olan MSDB veritabanındaki Backupset ve BackupMediaFamily tablolarını kullanarak bulmaya çalışıyor aradığı LSN'leri. Bir şekilde eğer alınan Transaction Log Backup'ın kaydı bu tablolarda yoksa, o zaman Golden Gate bu hatayı alarak duruyor. ALTARCHIVELOGDEST parametresi kullanıldığında ise Golden Gate'in LSN arama yöntemi değişiyor ve sistem tabloları yerine tüm yedek dosyalarını tek tek açarak ilgili LSN'i bulmaya çalışıyor, bu nedenle işlem çok uzun sürüyor. Tabii ki ilgili yedek klasöründe kaç tane dosya olduğu ve bu dosyaların büyüklüğüyle de doğrudan ilgili bir konu bu.

Bizim durumumuzda sistem tablolarındaki boşlukların nedeni ise, yine SQL Server'ın Backup tarihçesinin temizlenmesi için kullanılan Sistem SP'sinin çalışırken Transaction Log yedeği alındığında bu işlemin sistem tablolarına işlenmesinin engellenmesiydi. Yani temizlik işlemi yapılırken şayet Transaction Log yedeği alınırsa, o zaman Transaction Log yedeği alınıyor, fakat Deadlock oluşuyor ve bu işlem MSDB'deki sistem tablolarına işlenemiyordu.

Görüldüğü üzre bu sorun doğrudan SQL Server'da oluşan Deadlock nedeniyle kaynaklanıyor ve sorunun doğrudan Golden Gate ile ilgisi yok. Golden Gate, sorunun sonucundan etkileniyor. Biz bir şekilde Deadlock oluşmasını engelledik, şayet siz de bu sorunu yaşıyorsanız ve Deadlock oluşmasını engelleyebilirseniz, o zaman Golden Gate'teki bu sorundan da kurtulmuş olursunuz.

Ekrem

Golden Gate: "Invalid character value for cast specification"

HATA: "Invalid character value for cast specification"

AÇIKLAMA / ÇÖZÜM: Ben bu hata ile ilk önce Replicat tarafında karşılaşmıştım. Golden Gate'in "logdump" isimli araçıyla sorunu didiklerken, Replicat tarafında eklenmeye çalışılan tarih alanı değerinin 1757.58.35 gibi bir abuk değer olduğunu fark etmiştim. Bu sorunu da sadece sıkıştırılmış tablolarda yaşıyordum.

Daha sonra bu sorunu düzelttiklerini söylemişlerdi ve yeni bir versiyonu kullanmamı önermişlerdi. Yeni versiyonu kurmuştum ve daha sonra da aynı sorunla bu sefer kaynakta, Extract'larda karşılaşmıştım. Bu sefer sorunu sadece sıkıştırılmış tablolarda değil, tüm tablolarda yaşıyordum. Bu sefer de farklı bir versiyona yönlendirmişlerdi ve sorun bu şekilde çözümlenmişti.

Ekrem