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

İş ilanı (SQL Server DBA)

Selam arkadaşlar, Sizinle bir iş ilanı paylaşmak istiyorum, ilgilenenler CV'lerini doğrudan bana (enaksanamun AT gmail . com) gönderebilirler. Ben de ilgili kişilerle paylaşacağım.

Genel Nitelikler: Üniversitelerin ilgili bölümlerinden mezun İngilizce bilen Minimum 3 yıl veritabanı yönetimi tecrübesi olan Veritabanı recovery deneyimi bulunan “Disaster recovery site” uygulama deneyimi olan İleri seviyede SQL bilgisi bulunan Veritabanı tasarım bilgisine sahip Performans izleme ve optimizasyon bilgisi olan Takım çalışmasına yatkın İletişim becerisine sahip Askerliğini tamamlamış

İş Tanımı: Firmamıza MS Sql Server 2005 & 2008 sunucularının , · Kurulumu yönetimi, · Sunucu ve disk donanımlarının planlanması · Backup ve recovery planlarının hazırlanıp uygulanması · Performans izleme ve optimizasyon çalışmalarının yapılması · “Disaster recovery site” planlanması ve uygulanması · Gerekmesi halinde recovery planlarının uygulanması Konularında görev alacak “Veri Tabanı Yöneticisi” arayışımız bulunmaktadır.

HATA: The database owner SID recorded in the master database differs from the database owner SID recorded in database 'veritabanı_adı'. You should correct this situation by resetting the owner of database 'veritabanı_adı' using the ALTER AUTHORIZATION statement. AÇIKLAMA: Bir kullanıcı sistemde bir SP çalıştırmak istediğinde böyle bir hata ile karşılaştığını söylemişti. Bahsi geçen veritabanında TRUSTWORTHY özelliği açıktı. Bu sorunla önceden de karşılaştığımız için sorunun veritabanı sahibinden kaynaklandığını biliyordum. ÇÖZÜM: Veritabanının sahibini aşağıdaki gibi bir kod ile "sa" yaptığınızda sorun çözülür: USE [veritabani_adi] GO EXEC sp_changedbowner 'sa' GO

"Cannot generate SSPI context. (Microsoft SQL Server)"

HATA: Cannot generate SSPI context. (Microsoft SQL Server)

AÇIKLAMA: Bu hatayı değişik durumlarda alabilirsiniz. Hemen biraz önce bir kullanıcı bana bu hatayı aldığını söyledi. En son ne zaman sağlıklı bağlandığını, o zamandan bu yana ne değişiklik olduğunu falan sordum ve o arada bana Windows Domain şifresinin değiştiğini söyledi. Kilit ipucu buydu işte. Çünkü şifresini değiştirdikten sonra yeni şifre ile hiç Windows'una giriş yapmamıştı ve bu nedenden dolayı Windows Authentication işlemi yapılırken o anki şifresiyle Active Directory'deki şifresi eşleştirilemiyordu ve SQL Server'a giriş yapamıyor ve bu hatayı alıyordu.

ÇÖZÜM: Kullanıcıya Windows'undan Log Off olup sonra Log In işlemlerini uygulaması gerektiğini söyledim, fakat kullanıcı bana o anda makinesinde birçok uygulama açık olduğunu ve bunun sıkıntılı olacağını söyledi. Ben de kendisine SQL Server Management Studio'yu SHIFT tuşu basılıyken farenin sağ tuşuna basıp başka bir kullanıcı olarak (Run as a different user) SSMS'i açabileceğini ve bu sayede yeni şifresini kullanabileceğini ve Authentication işleminin başarıyla yapılabileceğini ve hatayı almayacağını anlattım. Uygulayınca da sorun çözümlenmiş oldu. Bu şekilde de sizele bu sorun için iki çözüm paylaşmış oldum, umarım işinize yarar =)

"Product: SQL Server System CLR Types -- SQL Server System CLR Types requires the .NET Framework version 2.0 or 3.0 or 3.5 or 4.0. Ensure that this r"

HATA: Product: SQL Server System CLR Types -- SQL Server System CLR Types requires the .NET Framework version 2.0 or 3.0 or 3.5 or 4.0. Ensure that this requirement is fulfilled before installing SQL Server System CLR Types.

AÇIKLAMA:
SQL Server 2008 (SP1 + CU2) sunucularımızdan birine SP2 kurmaya çalışırken bu hatayı aldım. Sunucuda haliyle .Net kurulumu zaten vardı. Bu kurulumu onarmak istediğimde de başka bir hata alınca, en akıllıcasının sunucuyu yeniden başlatmak olduğunu düşündüm ve voila!

ÇÖZÜM:
Sunucuyu yeniden başlatınca bu sorun düzeliyor. Eğer olur da düzelmezse, .Net kurulumunu onarmayı denemenizi tavsiye edebilirim.

"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."

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.

"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.

"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.

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

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

Üretim sunucularımızdan birisi

Gerçekten sağlam üretim sunucularımız var ;)




Ekrem

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

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

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

Could not load package "UpdatePreApprovalCampaignSSIS" because of error 0xC0014062.

HATA: Could not load package "paketin adı" because of error 0xC0014062.
Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80040E4D (Login failed for user 'kullanıcı adı'.). The SQL statement that was issued has failed.

AÇIKLAMA:
Bir SSIS paketi yüklemeye çalıştığınızda böyle bir hata ile karşılaşabilirsiniz.

Çözüm:
Kullanıcının ("Login failed for user" bölünde yazan kullanıcının) ilgili sunucuda Login'i ve yeterli hakları bulunduğundan emin olun. Örneğin "msdb" veritabanının altındaki SSIS rollerini de kontrol edebilirsiniz.

ÖNEMLİ: SQL Server 2008 Online Index Rebuild'deki davranış değişikliği!

Arkadaşlar dün yeni bir şey daha öğrenmiş olduk, fakat bu öğrendiğimiz şeyi geç öğrenmenin bedelini de ödedik.

SQL Server 2008'e geçtiğimizden beri Index bakımı yapılan zamanlarda Transaction Log yedeklerimizin eskiye nazaran çok büyüdüğünü gözlemledik ve Transaction Log yedeklerimizi aldığımız disk artık yetmez oldu. Acilen ekstra disk talep ederek bu sorunu atlattık, ama anlayamadığımız şey neden birden böyle bir sorunla karşılaştığımızdı. Kayıt sayılarında böyle ani bir artık beklenecek bir durum yoktu ortada, en azından işlemler açısından.

Sağolsun MS PFE'mizin bize ilgili KB'yi iletmesiyle sorun anlaşıldı. SQL Server 2008'den itibaren, Online Index Rebuild işlemleri Transaction Log dosyasına artık tam olarak işleniyormuş. SQL Server 2005'te bu işlem asgari seviyede yapılıyormuş. Bu sorunu kritik sistemlerimizi SQL Server 2008'e yükseltince farkettik, çünkü malum kritik sistemler en fazla kayıdın oluştuğu sistemler ve bu nedenle de Transaction Log'un en çok kullanıldığı, en büyük Transaction Log yedeklerinin oluştuğu sistemler.

Daha fazla bilgi için ilgili KB'yi incelemek isteyebilirsiniz: http://support.microsoft.com/kb/2407439

2011-2012 Microsoft SQL Server MVP Ödülü, 3. kere =)

Selam arkadaşlar,

Bugün 3. kere Microsoft SQL Server MVP ödülünü kazandığımı öğrendim... Umarım bu sayede daha çok şey öğrenebilir ve sizlere de olabildiğince aktarabilirim.

Sevgiler,
Ekrem Önsoy

Package migration from version 3 to version 2 failed with error 0xC001700A "The version number in the package is not valid. The version number c

HATA:
Package migration from version 3 to version 2 failed with error 0xC001700A "The version number in the package is not valid. The version number cannot be greater than current version number.

Açıklama:
Bir SSIS paketini doğrudan veya dolaylı olarak (örneğin bir toplu işlem dosyası (*.bat) ile) "dtexec" uygulaması kullanarak çalıştırmak isterseniz böyle bir hata ile karşılaşabilirsiniz. Örneğin ben bu sorunla karşılaştığımda, SSIS paketleri SQL Server 2008 versiyonuyla uyumluydu; paketler başka bir sunucudaydı ve paketler toplu işlem dosyaları ile çalıştırılıyordu. Paketler ise başka bir sunucudan UNC yolu kullanılarak (örn: \\...\...\...) çalıştırılıyordu. Yani çalıştırılan "dtexec" uygulaması aslında toplu işlem dosyalarına hangi makineden ulaşılıyorsa o makinedeki "dtexec" uygulaması kullanılmış oluyordu, SSIS paketlerinin bulunduğu sunucudaki "dtexec" değil.

Sorunu araştırırken şunu farkettim, operatörün bağlandığı makinede hem SQL Server 2005 hem de SQL Server 2008 kuruluydu ve operatör toplu işlem dosyasını çalıştırdığında aslında SQL Server 2005 versiyon olan "dtexec" uygulaması çalıştırılıyordu ve "eski yeniyi tanımaz" kuralına uygun olarak 2008 versiyon SSIS paketlerini tanımadığından yukarıdaki hatayı veriyordu.

Windows Environment Variables'ı kontrol ettiğimde SQL Server 2005 yolunun 2008 yolundan önce tanımlandığını gördüm, yani bir uygulama çalıştırılacağı zaman öncelikle 2005'in yollarında aranıyordu uygulama ve "dtexec" uygulaması SQL Server 2005'te de 2008'de de aynı isimle olduğundan dolayı 2005 versiyonu çalıştırılıyordu.

ÇÖZÜM:
Sorunu tespit ettiğimde geçici çözüm olarak SQL Server 2005'in "dtexec" uygulamasının adını "dtexec_" olarak değiştirdim ve artık varsayılan olarak SQL Server 2008'in "dtexec" uygulaması çalıştırılıyordu. Kalıcı çözüm olarak ise şayet gerekmiyorsa SQL Server 2005 tamamen kaldırılabilir (uninstallation). Şayet iki versiyona da ihtiyaç varsa yine ilk çözümde olduğu gibi dosya adı değiştirilebilir.

Bir taşıma tecrübesi...

Bu haftasonu, çok önemli üretim veritabanı sunucularımızdan biri olan bir sunucuyu SQL Server 2005'ten SQL Server 2008'e taşıdık. Ayrıca işletim sistemi olarak da Windows Server 2003'ten Windows Server 2008 R2'ye geçmiş olduk. Bu konuda yaşadığımız bazı tecrübeleri sizinle de paylaşmak istedim.

Öncelikle akla gelen "Neden SQL Server 2008 R2'ye veya bu yılın sonunda çıkması beklenen SQL Server 2011'i (kod adı Denali) bekleyip de bu yeni versiyonlara geçiş yapmadınız da gittiniz 2 sene öncesinin versiyonuna geçiş yaptınız?" sorusunu yanıtlayayım da hepimiz rahatlayalım. Bunun nedeni, kullandığımız 3. parti bir uygulama olan Oracle Golden Gate uygulamasının henüz resmi olarak SQL Server 2008 R2'yi desteklememesi ve bu ürünü üretim ortamında kullanmamızın gerektiğidir. SQL Server 2008 R2'nin piyasaya sunulmasından sonra (RTM) 2 sene geçmiş olmasına rağmen hâlâ bu versiyona resmen desteğini açıklamamış olan Oracle'dan haliyle SQL Server 2011 için elini çabuk tutmasını beklemezsiniz. Zaten Golden Gate'i Oracle firmasına satan ve Golden Gate'in hâlâ CEO'su olan Ali Kutay Bey de geçen sene Oracle'a satış sonrası Dedeman'daki Golden Gate toplantısında şöyle demişti: "Golden Gate için artık iki geliştirme ekibimiz bulunuyor, birisi Oracle geliştirme ekibi, diğer ekip de diğer ürünleri destekleyen ekip." Golden Gate uygulamasının Oracle Database, Microsoft SQL Server, IBM DB2, Sybase vb. RDBMS'leri desteklediğini göz önüne alırsak sanırım ne demek istediğim daha net anlaşılır.

Bu taşımada, Detach\Attach ile kaybedilen zamanı kazanmak için başka değişik bir yöntem izlemek istedik. Bu yöntem ile izleyeceğimiz yol aşağıdaki gibi olacaktı:

- Veritabanları kaynak sunucuda OFFLINE duruma getirilir,
- Diskler kaynak sunucudan çekilir,
- Diskler hedef sunucuya gösterilir,
- İlgili diskler, Cluster SQL Server Resource'una bağlanılır (depend),
- Veritabanları hedef sunucuda ONLINE duruma getirilir.

Not: Hedefteki SQL Server sunucusuna önceden aynı disklerin klonları gösterilmiş ve veritabanları Attach edilmiş olmalı (ki bunu başka testler için de zaten yapmış oluyorsunuz) ve ardından da diskler geri çekilmeden önce veritabanları OFFLINE durumuna alınır ve böylece yukarıdaki sıralamış olduğum son adım gerçekleştirilebilir.

Bu yöntemi iki kere test ettik. İkisinde de ACCESS VIOLATION sorunlarıyla karşılaştık ve bu sorun da SQL Server'ın Dump almasına neden oldu. Bu sorunu araştırırken, sorunu veritabanı veri veya log dosyalarının disk kökünde (root) bulunduğu disklerde yaşadığımızı fark ettik. Diskler Mountpoint. Şayet diskin içinde bir klasör varsa ve dosyalar klasörün içindeyse, o zaman bu sorunu yaşamadan veritabanlarını ONLINE duruma aldığımızda veritabanlarının hem otomatik olarak SQL Server 2005'ten 2008'e sürüm yükseltmesi (upgrade) yapıldığını gördük, hem de başarıyla ONLINE duruma geldiklerini. Maalesef tüm disklerdeki tüm dosyaların (30 kusür diskteki yüzlerce dosyadan bahsediyorum) yerlerini değiştirmek ve testi tekrarlamak için zamanımız olmadığından dolayı bu yöntemden kısmen vazgeçtik ve aşağıdaki yöntemi izledik:

- Veritabanları kaynak sunucuda OFFLINE duruma getirilir,
- Diskler kaynak sunucudan çekilir,
- Diskler hedef sunucuya gösterilir,
- İlgili diskler, Cluster SQL Server Resource'una bağlanılır (depend),
- Veritabanları hedef sunucuda Attach edilir.

İşin garip tarafı, dosyalar Mountpoint'lerin kök dizininde de olsa elle Attach ettiğimizde herhangi bir sorunla karşılaşmamamıza rağmen, bunu SQL Server'daki OFFLINE durumda olan veritabanını ONLINE'a alarak SQL Server'a yaptırdığımızda ACCESS VIOLATION hatası almamızdı. Bunu Microsoft mühendisleriyle de paylaştık, fakat onlar da mantıklı bir açıklama bulamadı. Muhtemelen sorunu Amerika'ya taşırsak belki bir sonuç alabilirdik, ama buna da vakit yoktu. Ayrıca Microsoft'taki arkadaşlardan önceden bu tür bir sorunla karşılaşılmış senaryolar hakkında araştırma yapmalarını da rica ettik ve bizimki gibi yaşanılan bir senaryo daha bulduk (maalesef bunu bizden önce birileri bir kere denemiş anlaşılan!), fakat o sorun da yüzeysel olarak kapatıldığından ve net bir çözüm üretilemediğinden dolayı o senaryo da bizim için bir çözüm olmadı.

Bu geçiş için sabaha kadar ofisteydim ve bu sabah 9 gibi eve gelebildim. Biraz uyudum, ama şimdi Log Shipping ve Golden Gate ile ilgilenmem gerekiyor...

The EXECUTE permission was denied on the object 'xp_sqlagent_enum_jobs', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 2

HATA:
The EXECUTE permission was denied on the object 'xp_sqlagent_enum_jobs', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 229)

AÇIKLAMA:
Bir SQL Server 2005 üretim sunucumuz vardı. Bunu, donanım açısından daha güçlü olan başka bir SQL Server 2005 sunucusuna taşıyorduk. Bu senaryoda, Job'ları, SSIS paketlerini (ki "msdb" veritabanının içerisindelerdi) daha kolay taşımak adına eski sunucudaki "msdb" veritabanını doğrudan taşıyarak aldık.

Her şey çok güzel gitti ve taşıma işlemimizi gerçekleştirdik. Birkaç gün sonra bir kullanıcı sunucudaki tüm Job'ları görmesi gerektiğini belirtti ve yetki talep etti. Yetki verildikten sonra kullanıcı bu gönderinin konusu olan hata mesajını aldığını belirtti.

Sorun üstünde araştırma yaparken Microsoft'un 2000274 numaralı KB'si ile karşılaştım: http://support.microsoft.com/kb/2000274

Yaşadığımız sorun tam anlamıyla bu KB'de anlatıldığı gibiydi. Fakat KB'deki yönlendirmeyi uygulamadan önce Microsoft'tan da destek almak istedik ve bir Advisory Case açtık. Microsoft destek personeli de bize bu KB'deki önerileri uygulayabileceğimizi, yurtdışında denenmiş senaryolar gördüğünü belirtti ve KB'deki önerileri tatbik ettik.

"msdb" veritabanındaki sertifikayı yeni sunucudaki "master" veritabanında Restore ettiğimizde şu uyarıyı aldık: "Warning: The certificate you created is expired."

Buna rağmen yaptığımız testlerden sonra bu hata mesajından kurtulduğumuzu gördük.

İPUCU: Windows Server 2008 R2 üzerinde SQL Server 2005'e çevrimiçi disk ekleme

Selam arkadaşlar,

Bu testi henüz yaptık ve hemen sonucu sizlerle paylaşmak istedim.

İşletim Sistemi: Windows Server 2008 R2
SQL Server: 2 Düğümlü SQL Server 2005 (+SP3 + CU2) Cluster
Testin amacı: SQL Server 2005, Windows Server 2008 R2'nin çevrimiçi disk büyütme işlemi ile uyumlu olarak çalışıyor mu?

Testimizde 2 tane 2GB boyunda SAN disk kullandık. Diskleri test yapacağımız sunucuya tanıttık ve bir SQL Server veritabanı oluşturduk. Veritabanının veri dosyasını bir diske, Log dosyasını diğer diske kaydettik. Dosyaların boyutunu da her biri 1,5GB olacak şekilde ayarladık. Daha sonra SAN mühendisi arkadaşımız diskleri 3GB boyutunu büyüttü ve biz de her bir dosyayı 2,5GB'a büyüttük. SQL Error Log'larını kontrol ettik, sorun yok. Daha sonra tekrar emin olmak için diskleri 4GB boyutuna getirdik ve oluşturduğumuz veritabanının veri ve Log doysalarının boyutlarını da 3,5GB boyutuna getirdik ve tüm bu büyütme işlemlerinin tamamının çevrimiçi, kesintisiz ve sorunsuz bir şekilde gerçekleştirildiğini gördük.

Diyeceğim odur ki, Windows Server 2008 R2 üzerinde bulunacak ve SQL Server için kullanılacak disklerinizi gönül rahatlığı ile çevrimiçi büyütebilirsiniz!

Hepimize kolay gelsin.
Ekrem

İPUCU: "Awaiting first complete passive cluster node 'Virtual Server Name'"

SQL Server 2005 Cluster kurulumunu yaptıktan sonra Service Pack veya Cumulative Update kurarken, kurulum ekranı bu mesaj yazar halde kalıyor olabilir.

Bu durumda, sadece kurulum yapıyor olduğunuz düğümde oturum açtığınıza ve diğer düğümlerde siz dahil kimsenin oturum açmadığından emin olmalısınız. Bu tedbiri aldığınız sürece bu sorunu yaşamazsınız.

SQLServer Error: 17750, Could not load the DLL xplog70.dll, or one of the DLLs it references. Reason: 126(The specified module could not be found.). [

HATA:
SQLServer Error: 17750, Could not load the DLL xplog70.dll, or one of the DLLs it references. Reason: 126(The specified module could not be found.). [SQLSTATE 42000] (ConnCacheSubsystems)

AÇIKLAMA:
SQL Server Agent servisinin çalışmayabilir ve bu hatayı da SQL Agent'ın Error Log dosyasında görebilirsiniz.

ÇÖZÜM:
"xplog70.dll" dosyası bozulmuş olabilir, aynı versiyondaki bir SQL Server sunucusundan bu dosya temin edilip, sorun yaşanan SQL Server kurulumundaki bozuk dosyanın üzerine yazılabilir. Sorun bu şekilde çözülecektir.

SSAS: ascmd ile birden fazla veritabanının yedeğini zaman ayarlı olarak almak

Senaryo: Windows Server 2008 R2 İşletim Sistemi üzerinde çalışan bir sunucumuz var, talep edilen ise sunucuya sadece bir tane SQL Server 2008 R2 Analysis Services Instance'ının kurulması. Yedekleme uygulamamız olan Commvault SSAS veritabanlarının yedeğini alamadığı için DBA olarak yapmamız gereken ise SSAS'teki veritabanlarının yedeklerinin zaman ayarlı olarak alınmasının sağlanması.

Bu gereksinimi gidermek için sevgili arkadaşım Batuhan Yıldız (Microsoft PFE)'dan destek aldık, çünkü konu hakkında çözüm için gereken araç gerece ulaşmak kolay değildi.

Eğer sunucuda bir SQL Server 2008 Database Engine kurulu olsaydı işimiz çok kolay olacaktı, çünkü SQL Server Agent hem XMLA kodlarını çalıştırıyor (ki veritabanlarının Backup Script'lerini çalıştırmak için bu işlevselliğe ihtiyaç var) hem de zaman ayarlı olarak çalışabiliyor.

Fakat bizim durumumuzda bir SQL Server Agent yok. SQLCMD ise XMLA kodlarını çalıştırmıyor. SQL Server'ın doğrudan kendi parçası olan başka da bir araç gereci yok.

Batuhan'dan adını ilk defa duyduğum "ascmd" isimli aracın varlığını da bu sorunla öğrenmiş oldum. "ascmd" isimli araç, tam da aradığımız gibi, SQLCMDvari bir araç ve XMLA Script'lerini çalıştırabiliyor. Fakat bu araç ile ilgili bir sorun var, SQL Server 2005 versiyonunu Codeplex'te bulabiliyorsunuz; fakat SQL Server 2008 versiyonunu internette bulmak konusunda ben muvaffak olamadım. Ancak Microsoft'taki diğer arkadaşlardan doğrudan elden alarak edinebildik bu aracı. Ayrıca şunu da belirtmek isterim ki, bu aracın uygulama halini (exe) doğrudan edinemiyorsunuz. Bu aracın kaynak kodlarını edinebiliyorsunuz ve bu kodları indirdikten sonra derlemeniz gerekiyor. Derlemek için de cscript.exe yetmiyor, Visual Studio'nun C# bileşenlerinin de yüklü olması gerekiyor.

Bizim durumumuzda birden fazla SSAS veritabanının yedeklenmesi gerekiyordu. Böyle bir durumda da aşağıdaki gibi bir Script'inin kullanılması gerekiyor. Yani "Batch" bloğunun içinde olmalı yedek alma Script'leri.




X:\BACKUP\Veritabanim1.abf
true




X:\BACKUP\Veritabanim2.abf
true



Velhasıl, "ascmd" uygulamasını ve yedekleme Script'lerini edindikten sonrası bildik hikâye. Bu Script'i bir XMLA dosyasına kaydedip aşağıdaki gibi bir komut dizisiyle Windows Task Scheduler kullanarak zaman ayarlı olarak çalıştırabilirsiniz:

ascmd -S DWANALIZ -i X:\BACKUP\ASBackupScript.xmla