Temmuz 2009 tarihinde Veritabanı Mühendisi olarak çalışmaya başladığım Denizbank - Intertech firmasından Eylül 2012 tarihi itibari ile ayrılmış bulunuyorum. Ekim 2012'den itibaren Aktif Grup altındaki Softaktif firması için çalışmaya başlayacağım.
Intertech, gerçekten "profesyonel" diyebileceğim birçok insanın çalıştığı ve her ne kadar zaman zaman çok yorulsam ve yıpransam da, benim de çalışmaktan memnunluk duyduğum bir firma. Kas, ağrısız büyümüyor. Intertech'teki çalışma ortamının yoğunluğu, neredeyse tamamen pratikte çalışmamıza neden oldu. Bu süreçte teorik konularda pek çalışamadım ne yazık ki. Ben en sağlıklı çalışma sürecinin, pratik ve teorik çalışmaların dengeli sürdürülebildiği bir süreç olduğunu düşünüyorum. Tabii ki sadece bu nedenle değil, ama daha ziyade bu nedenle Intertech'teki çalışma sürecimi sonlandırdım. Görevlerini sürdüren arkadaşlarıma başarılı çalışmalarının devamını diliyorum.
Softaktif'te ise Veritabanı Uzmanı olarak çalışacağım. Yine SQL Server sunucularını yöneteceğim, ama bunun yanında SQL Azure, MySQL ve PostgreSQL ile de ilgileneceğim. Bu konularda bilgi edinip, ilgili arkadaşlarımla ve belki bazılarını da sizlerle paylaşacağım.
Ayrıca, SQL Server ile ilgili küçük, orta ve büyük ölçekli tüm projelerinizde (yarım zamanlı olarak), yaşanılan sorunların çözümünde, yerinde doğaçlama veya belirlenecek olan bir müfredata göre eğitim verilmesinde, planlamalarda\kurulumlarda artık birlikte çalışabiliriz. Bu yeni işimde bu çeşit danışmanlık işleri de yapabileceğim. Lütfen ayrıntılar konusunda iletişim kurmaktan çekinmeyin. İletişim bilgilerimi, Blog'umun ana sayfasında bulabilirsiniz.
Umarım herkes için hayırlısı olur.
24 Ağustos 2012 Cuma
Kitap: SQL Server 2008 Query Performance Tuning Distilled
Arkadaşlar, 4-5 gündür Grant Fritchey'in yazdığı "SQL Server 2008 Query Performance Tuning Distilled" isimli kitabı okuyorum, elimden bırakamadım.
Grant bu eserinde, çok güzel ve açık örneklerle, gerçek hayatta en çok karşılaşılan SQL Server performans sorunlarını işlemiş. Bu yazılar, gerçekten bu sorunlarla karşılaşmış birisinin elinden yazıldığı için gerçekten kıymetli. Aynı kitabın SQL Server 2012 versiyonu için yazılmış olanı da var. Konu başlıklarına baktım, aynı konular işlenmiş. İşlenilen konuların çok temel olması nedeniyle iki kitap arasında çok fark olacağını düşünmesem de, onu da okuyacağım. En kötü ihtimal aynı kitabı iki kere okumuş olurum ;)
Daha yeni başlayan arkadaşlarıma bu kitabın biraz ağır gelebileceğini düşündüğüm için, orta ve ileri seviyedeki tüm arkadaşlarıma bu kitabı okumalarını tavsiye ederim.
http://www.amazon.com/Server-Performance-Tuning-Distilled-Experts/dp/1430219025
Grant bu eserinde, çok güzel ve açık örneklerle, gerçek hayatta en çok karşılaşılan SQL Server performans sorunlarını işlemiş. Bu yazılar, gerçekten bu sorunlarla karşılaşmış birisinin elinden yazıldığı için gerçekten kıymetli. Aynı kitabın SQL Server 2012 versiyonu için yazılmış olanı da var. Konu başlıklarına baktım, aynı konular işlenmiş. İşlenilen konuların çok temel olması nedeniyle iki kitap arasında çok fark olacağını düşünmesem de, onu da okuyacağım. En kötü ihtimal aynı kitabı iki kere okumuş olurum ;)
Daha yeni başlayan arkadaşlarıma bu kitabın biraz ağır gelebileceğini düşündüğüm için, orta ve ileri seviyedeki tüm arkadaşlarıma bu kitabı okumalarını tavsiye ederim.
http://www.amazon.com/Server-Performance-Tuning-Distilled-Experts/dp/1430219025
26 Nisan 2012 Perşembe
SQL Server'da Server Collation değiştirme
Dün akşam yine böyle bir iş denk geldi. SQL Server 2008 R2 versiyon, hem de Clustered şekilde kurulmuş bir SQL Server Instance'sının Server Collation'ını değiştirmem istendi.
Bu işlemi gerçekleştirmek için öncelikle SQL Server Setup dosyalarına ihtiyacınız olduğunu unutmayın. Bu dosyaların, SQL Server Instance'ının kurulu olduğu sunucudaki bir diskte olduğundan emin olun. Yani Network'te olmasın, doğrudan sunucu üstünde olsun.
Bu işlemi gerçekleştirmeden önce, sistem veritabanlarındaki her şeyin yedeğini aldım. Login'lerin, Job'ların... Eğer olsaydı, bu veritabanlarındaki oluşturulmuş tablo, SP ve diğer nesnelerin de yedeklerini almam gerekirdi. Tüm bunlardan sonra tabii ki sistem veritabanlarının kendilerinin yedeklerini de almakta fayda var. Ardından, Attach ve Detach Script'leri oluşturulmalı ki, Server Collation değiştirme işleminden önce veritabanları Detach edilmeli ve işlem tamamlandıktan sonra tekrar Attach edilmeli.
Bu işlemleri gerçekleştirmek için aşağıdaki adımları izledim:
- Öncelikle Login'lerin Script'lerini çıkardım. Bunun için sp_helprevlogin kullanılabilir (http://support.microsoft.com/kb/246133 , http://support.microsoft.com/kb/918992)
- Job'ların Script'leri alınır. Bunu pratik bir şekilde yapmak için Object Explorer Details penceresini de kullanabilirsiniz.
- Veritabanlarının Attach Script'lerini oluşturmak için ben veritabanlarının CREATE Script'lerini çıkarıyorum ve CREATE DATABASE ... FOR ATTACH komutunu kullanarak CREATE Script'lerinin sonuna FOR ATTACH komutlarını ekliyorum. Böylece hem aynı dosya yollarını ve hem de özelliklerini korumuş oluyorum. Çünkü böyle durumlarda TRUSTWORTHY veya SSB gibi özelliklerin Attach'ten sonra tekrar etkinleştirilmesi unutulabiliyor.
- Veritabanlarının Detach Script'lerini de çıkardık mı, işlemler genel olarak tamamdır. Eğer ortamınızda Linked Server vb. sunucu düzeyinde nesneler varsa, bunları da hesaba katmanız gerekmektedir. Benim senaryomda bunlar yoktu, ama sizin hesaba katmanız gerekebilir.
Daha sonra, eğer SQL Server Instance'ınız benimki gibi Failover Clustered ise, o zaman Failover Manager'dan SQL Server Resource'unu OFFLINE duruma getirmelisiniz. Ardından da, aşağıdaki gibi bir komutu çalıştırarak sistem veritabanlarını yeniden derlemeyi sağlayabilirsiniz, tabii ki istediğiniz Server Collation ile. Aşağıdaki örnekte de görebileceğiniz üzere SQL Server Instance'ım bir Default Instance. Bu işlemde SQLSYSADMINACCOUNTS parametresi ile "sysadmin" rolünün üyesi olarak birden fazla kişi tanımlayabilirsiniz (çift tırnak içinde ve eğer birden fazla kullanıcı olacaksa aralarında aşağıdaki örnekte olduğu gibi boşluk bırakarak). SAPWD parametresi ile de "sa" şifrenizi değiştirebilir veya yeniden belirleyebilirsiniz. SQLCOLLATION parametresi ile de değiştirmek istediğiniz yeni Server Collation değerini (çift tırnağa gerek kalmadan) girebilirsiniz. Aşağıdaki örnekte de görüleceği üzre, Setup dosyaları "C:\SQLSetup\x64" klasörünün içindeydi. Bu komut, Setup.exe'nin olduğu klasörde Command Prompt'ta çalıştırılmalıdır.
C:\SQLSetup\x64>Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS= "DOMAIN\HESAP1" "DOMAIN\HESAP2" /SAPWD="GucluSAsifrem" /SQLCOLLA TION=SQL_Latin1_General_CP1254_CS_AS
Bu işlemi gerçekleştirmek için öncelikle SQL Server Setup dosyalarına ihtiyacınız olduğunu unutmayın. Bu dosyaların, SQL Server Instance'ının kurulu olduğu sunucudaki bir diskte olduğundan emin olun. Yani Network'te olmasın, doğrudan sunucu üstünde olsun.
Bu işlemi gerçekleştirmeden önce, sistem veritabanlarındaki her şeyin yedeğini aldım. Login'lerin, Job'ların... Eğer olsaydı, bu veritabanlarındaki oluşturulmuş tablo, SP ve diğer nesnelerin de yedeklerini almam gerekirdi. Tüm bunlardan sonra tabii ki sistem veritabanlarının kendilerinin yedeklerini de almakta fayda var. Ardından, Attach ve Detach Script'leri oluşturulmalı ki, Server Collation değiştirme işleminden önce veritabanları Detach edilmeli ve işlem tamamlandıktan sonra tekrar Attach edilmeli.
Bu işlemleri gerçekleştirmek için aşağıdaki adımları izledim:
- Öncelikle Login'lerin Script'lerini çıkardım. Bunun için sp_helprevlogin kullanılabilir (http://support.microsoft.com/kb/246133 , http://support.microsoft.com/kb/918992)
- Job'ların Script'leri alınır. Bunu pratik bir şekilde yapmak için Object Explorer Details penceresini de kullanabilirsiniz.
- Veritabanlarının Attach Script'lerini oluşturmak için ben veritabanlarının CREATE Script'lerini çıkarıyorum ve CREATE DATABASE ... FOR ATTACH komutunu kullanarak CREATE Script'lerinin sonuna FOR ATTACH komutlarını ekliyorum. Böylece hem aynı dosya yollarını ve hem de özelliklerini korumuş oluyorum. Çünkü böyle durumlarda TRUSTWORTHY veya SSB gibi özelliklerin Attach'ten sonra tekrar etkinleştirilmesi unutulabiliyor.
- Veritabanlarının Detach Script'lerini de çıkardık mı, işlemler genel olarak tamamdır. Eğer ortamınızda Linked Server vb. sunucu düzeyinde nesneler varsa, bunları da hesaba katmanız gerekmektedir. Benim senaryomda bunlar yoktu, ama sizin hesaba katmanız gerekebilir.
Daha sonra, eğer SQL Server Instance'ınız benimki gibi Failover Clustered ise, o zaman Failover Manager'dan SQL Server Resource'unu OFFLINE duruma getirmelisiniz. Ardından da, aşağıdaki gibi bir komutu çalıştırarak sistem veritabanlarını yeniden derlemeyi sağlayabilirsiniz, tabii ki istediğiniz Server Collation ile. Aşağıdaki örnekte de görebileceğiniz üzere SQL Server Instance'ım bir Default Instance. Bu işlemde SQLSYSADMINACCOUNTS parametresi ile "sysadmin" rolünün üyesi olarak birden fazla kişi tanımlayabilirsiniz (çift tırnak içinde ve eğer birden fazla kullanıcı olacaksa aralarında aşağıdaki örnekte olduğu gibi boşluk bırakarak). SAPWD parametresi ile de "sa" şifrenizi değiştirebilir veya yeniden belirleyebilirsiniz. SQLCOLLATION parametresi ile de değiştirmek istediğiniz yeni Server Collation değerini (çift tırnağa gerek kalmadan) girebilirsiniz. Aşağıdaki örnekte de görüleceği üzre, Setup dosyaları "C:\SQLSetup\x64" klasörünün içindeydi. Bu komut, Setup.exe'nin olduğu klasörde Command Prompt'ta çalıştırılmalıdır.
C:\SQLSetup\x64>Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS= "DOMAIN\HESAP1" "DOMAIN\HESAP2" /SAPWD="GucluSAsifrem" /SQLCOLLA TION=SQL_Latin1_General_CP1254_CS_AS
3 Nisan 2012 Salı
Deneyimli SQL Server DBA?
Selam millet,
Bizimle aynı takımda çalışacak SQL Server DBA arıyoruz. Aradığımız profil ise en azından 5 bin kullanıcısı olan bir ortamda Production DBA olarak çalışmış ve 2 sene tecrübesi olan birisi. Bu kriterlere uyan arkadaşlar doğrudan benimle irtibat kursun lütfen.
enaksanamun AT gmail DOT com
Ekrem
Bizimle aynı takımda çalışacak SQL Server DBA arıyoruz. Aradığımız profil ise en azından 5 bin kullanıcısı olan bir ortamda Production DBA olarak çalışmış ve 2 sene tecrübesi olan birisi. Bu kriterlere uyan arkadaşlar doğrudan benimle irtibat kursun lütfen.
enaksanamun AT gmail DOT com
Ekrem
19 Mart 2012 Pazartesi
"Timeout (30000 milliseconds) waiting for the SQL Server (MSSQLSERVER) service to connect."
HATA:
"Timeout (30000 milliseconds) waiting for the SQL Server (MSSQLSERVER) service to connect."
AÇIKLAMA: Bugün, bir SQL Server 2005 yüklemesi yaparken çok ilginç bir hata ile karşılaştım. Windows System Event Log'daki Hata mesajı, yukarıda belirttiğim gibiydi; fakat kurulum esnasında, ekranda karşıma çıkan hata mesajı daha başkaydı. O anda maalesef ekran görüntüsünün resmini kaydetmediğim için burada sizinle paylaşamıyorum.
Hata mesajı tam olarak Database Engine yüklenmesi esnasında, Database Engin servisi çalıştırılmaya çalışılırken ekrana geliyordu.
SQL Server 2005'i yüzlerce kez kurmuşumdur, buna benzer sorunlarla da karşılaşmıştım; ama bu onların hepsinden farklıydı. Farklı servis hesapları kullansam da, sorunu bir türlü aşamıyordum. Sonra, elimdeki oldukça genel olan bu hata mesajını çaresizce Google'da arattım ve SQL Server 200 RTM'in CPU sayılarıyla sorunları olduğunu gördüm.
Kurulum yaptığım sunucuda 12 adet işlemci çekirdeği vardı ve Microsoft'un kb954835 isimli KB'sinde, bu tür sorunlarla karşılaşabileceği yazıyordu. Ben önce KB'de bahsedilen birinci yöntemi kullandım, fakat işe yaramadı. Sonra ikinci yöntemi kullandım ve VOILA!
ÇÖZÜM: Microsoft'un kb954835 isimli KB'sindeki 2. yöntem ile sorunu çözmeyi başardım. Olur da hâlâ aranızda benim gibi 2012 senesinde SQL Server 2005 kurulumu yapan olur ve böyle bir durumla karşılaşırsanız diye sorunu kaydetmek istedim.
"Timeout (30000 milliseconds) waiting for the SQL Server (MSSQLSERVER) service to connect."
AÇIKLAMA: Bugün, bir SQL Server 2005 yüklemesi yaparken çok ilginç bir hata ile karşılaştım. Windows System Event Log'daki Hata mesajı, yukarıda belirttiğim gibiydi; fakat kurulum esnasında, ekranda karşıma çıkan hata mesajı daha başkaydı. O anda maalesef ekran görüntüsünün resmini kaydetmediğim için burada sizinle paylaşamıyorum.
Hata mesajı tam olarak Database Engine yüklenmesi esnasında, Database Engin servisi çalıştırılmaya çalışılırken ekrana geliyordu.
SQL Server 2005'i yüzlerce kez kurmuşumdur, buna benzer sorunlarla da karşılaşmıştım; ama bu onların hepsinden farklıydı. Farklı servis hesapları kullansam da, sorunu bir türlü aşamıyordum. Sonra, elimdeki oldukça genel olan bu hata mesajını çaresizce Google'da arattım ve SQL Server 200 RTM'in CPU sayılarıyla sorunları olduğunu gördüm.
Kurulum yaptığım sunucuda 12 adet işlemci çekirdeği vardı ve Microsoft'un kb954835 isimli KB'sinde, bu tür sorunlarla karşılaşabileceği yazıyordu. Ben önce KB'de bahsedilen birinci yöntemi kullandım, fakat işe yaramadı. Sonra ikinci yöntemi kullandım ve VOILA!
ÇÖZÜM: Microsoft'un kb954835 isimli KB'sindeki 2. yöntem ile sorunu çözmeyi başardım. Olur da hâlâ aranızda benim gibi 2012 senesinde SQL Server 2005 kurulumu yapan olur ve böyle bir durumla karşılaşırsanız diye sorunu kaydetmek istedim.
Kaydol:
Kayıtlar (Atom)