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
21 Aralık 2011 Çarşamba
20 Aralık 2011 Salı
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
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
19 Aralık 2011 Pazartesi
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
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
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
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
Kaydol:
Kayıtlar (Atom)