SQL Server 2008 R2 Sürümünde Veritabanı Restore İşleminde Dikkat Edilecek Önemli Özellik

SQL Server 2008 R2 sürümünde bulunan TEST_DATA isimli test  veritabanım üzerine farklı  bir saat'ta alınan yedeği restore etmeye çalıştığımda restore komutunu seçip veritabanı yedeğini gösterdikten sonra Restore The Database  File As adres yolunda mevcut üretim veritabanımın isminin ve mdf-ldf uzantılarının göründüğünü farkettim(Yol TEST_DATA olması gerekirken mevcuttaki veritabanımın ismi gözüküyordu ST2015 gibi).Bu üretim sunucularındaki veritabanları için son derece tehlikeli bir özelliktir ve veri kaybına sebep olabilir.Belkide SQL Management Studio ile ilgili bug olarak yorumlayabiliriz.Aşağıdaki şekilde gösterilmiştir;

Bunun için Restore işlemi yaparken özellikle Restore The Database  File As yoluna mutlaka dikkat edip mevcut üretim veritabanının ismive mdf-ldf uzantısı  varsa mutlaka silip aşağıdaki gibi test veritabanımızın ismini yazmalıyız.Daha önceki SQL Server 2000/2005 sürümlerinde de bu durumu yaşadığım için bloğa konu ile ilgili yazı yazma gereksinimi duydum.Bol yedekli günler :)

8 Kasım 2015 Tarihine Ertelenen Saat değişikliği Hakkında

Bu sene 25 Ekim 2015 Tarihinde olması gereken  kış saatine geçiş  Türkiye genelinde 8 Kasım 2015 Pazar gününe ertelendiği için sunucu ve bilgisayarlarımızın otomatik saat değişimini 8 Kasım 2015 Pazar gününe ötelememiz gerektiği hakkında Microsoft düzeltme yaması çıkarmıştır.Yama yüklemeden de bu işlem yapılabilmektedir.Bunun için kayıt defteri değişikliği yapılması gerekmektedir.Aşağıdaki kodları not defteri  açarak reg uzantılı kayıt ettiğimizde  çift tıklayıp kayıt defterini ilgili anahtaları ekleyebiliriz.Bundan önce ilgili değişiklik yapacağımız registry kayıtlarının yedeğini almalıyız.


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"DaylightName"="@tzres.dll,-1501"
"StandardName"="@tzres.dll,-1502"

"TimeZoneKeyName"="Turkey Standard Time"


Yukarıdaki kod saat dilimimizi İstanbul saat dilimine çekecektir.Bunu not defterine reg1 adıyla reg uzantılı kaydedebiliriz.


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Turkey Standard Time\Dynamic DST]
"2015"=hex:88,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,02,00,04,00,\
00,00,00,00,00,00,00,00,03,00,00,00,05,00,03,00,00,00,00,00,00,00

"LastEntry"=dword:000007df

Yukarıda yer alan kod ise sistem tarihimizi 8 Kasım 2015 tarihine ötelememizi sağlayan koddur.Bunu ise reg uzantılı olarak reg 2 adıyla kayıt edebiliriz.Bu anahtarları kayıt defterine eklemeden önce aşağıdaki kayıt defteri anahtarlarının regedit'ten yedeğini almamız gerekmektedir.

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Turkey Standard Time\Dynamic DST

Yedek almak için ilgili kayıt defteri anahtarının üzerinde sağ klik yaparak ver komutu ile örneğin yedek reg1 ile eski kaydı yedek alıp ardından reg1 ve reg2 uzantılı kayıtları eklemeliyiz.İlgili resim aşağıdadır.

Bu işlemleri yaptıktan sonra Windows Time servisini restart edince 8 kasım 2015 ayarları sistemimize uygulanmış olacaktır.Domain ortamında registry ayarları group policy yönemiylede kullanıcılara dağıtılabilmekte olup 8 kasım tarihinden sonra ayarları eski tarihe döndürmek gerekmektedir.

Registry kayıtlarının görüntüsü;

SQL Server MSDB Veritabanı

SQL Server'da çalışma yaparken genellikle üretime yönelik veritabanları ile daha çok ilgili olduğumuz için sistem veritabanlarını  merak etmeyiz -zaten gizlidirler-SQL Server'da çeşitli amaçta 4 adet sistem veritabanı bulunmaktadır.Bunlar;Master,Model,Msdb ve Tempdb veritabanlarıdır.Bu yazıda kısaca MSDB veritabanı ile ilgili bazı özelliklere değinmek istiyorum.MSDB veritabanı sistem ile ilgili jobları ve veritabanı yedeklerinin ne zaman yapıldığı ile ilgili bilgileri tutmaktadır.Sistem performansı için DBA görevlerimize MSDB ve sistem veritanalarımızın bakımını almamız performans açısından önemlidir.Örneğin aşağıdaki resimdeki gibi herhangi bir zamanlanmış göreve bağlı olmadan elle yedekleme yaptığımızı varsayalım;

yedekleme işlemi bittikten sonra msdb.dbo.backupset tablosuna aşağıdaki komut ile sorgu çektiğimizde  bize tüm yedekleme görevlerinin ne zaman başladığı ve ne zaman tamamlandığı hakkında bilgi verecektir.

SELECT * FROM msdb.dbo.backupset
WHERE [database_name]='db adı'

order by backup_start_date

Yedekleme görevimiz ile ilgili başlangıç ve bitiş tarihleri ile ilgili MSDB veritabanı kayıtlarımızı aşağıdaki gibidir.

Yukarıdaki 3 adet kayıt test ortamındaki bir sunucudan alındığı için az kayıt gözükmektedir.Örneğin benim üretim ortamında kullandığım veritabanlarında veri  kaybına tahammülümüz olmadığı için sıkı bir yedekleme görevlerimiz mevcut olup an itibari ile 1448183 adet kayıt bulunmaktadır.Bunun için eskiye ait kayıtların temizlenmesi gerekmektedir.Bunu ise aşağıdaki stored procedure kodunu çağırarak yapabiliriz;

exec msdb.dbo.sp_delete_backuphistory '2015-10-16'

Yukarıdaki komut 16.10.2015 tarihinden önceki tüm kayıtları silecektir.msdb.dbo.backupset set tablomuzda 14 ekim ve 15 ekim 2015 tarihlerine ait kayıtlar bulunduğu için ilgili stored procedur bu kayıtların hepsini silmiş olacaktır.

Windows 7 ve Windows 8.1 İşletim Sistemlerini Windows 10'a Güncelleme

Microsoft'un bugün itibari ile yayınladığı (29 Temmuz 2015) Windows 10 işletim sistemini korsan olmayan Windows 7 ve Windows 8.1 kullanıcıları yükseltebilmekte.Bir şekilde sağ alttaki saatin yanına Windows 10 güncelleştirmesi gelmeyen  Windows 7 -Windows 8.1 işletim sistemi kullanıcıları komut istemini yönetici olarak çalıştırıp wuauclt.exe /updatenow komutunu girerek indirme işlemini başlatabilirler.

Netsis TBLSERITRA ve TBLSTHAR Bağlantısı Hakkında

Netsis Programı SQL Server 2008 R2  veritabanında serili stok hareketlerinin  kayıt altına alındığı 2 tablo bulunmakta bunlar TBLSTHAR ve TBLSERITRA tabloları olup TBLSTHAR INCKEYNO TBLSERITRA ise STRA_INC Primary keyleri ile birbirine bağlı olmak zorunda yani 1 adet stok hareketinin karşılığı 1 seri demek oluyor.Stok yaşlandırma'da bulunan eksi bakiye sorununu çözmek için yedek şirkette devir ile gelen eksi bakiyeyi TBLSTHAR ve TBLSERITRA tablosundan Delete komutu ile sildiğimde yaşlandırma raporundaki eksi bakiye sorunu ortadan kalkmış oldu.Bu sefer tam tersi düşünerek sildiğim bu kayıtları yeniden eski yerlerine almak istedim.Farklı bir yedekten SERITRA tablosundaki kaydı sorunsuz eski yerine taşıdım diğer kaydı TBLSTHAR tablosuna taşımak istediğimde ise INCKEYNO identity değeri aldığı için hata verdi.Böyle durumlarda aslında identity seçeneği tablo dizaynından iptal edilebilir ama üretim veritabanlarında böyle bir durum risk oluşturacağı için yedekteki ilgili kaydı INSERT INTO komutu ile TBLSTHAR tablosuna INCKEYNO değerini yazmadan ekledim böylece sorunsuz olarak hem doğru kayıtlar eklendi hemde INCKEYNO  otomatik olarak yeni değer aldı.TBLSTHAR tablosunda bulunan yeni INCKEYNO değerini TBLSERITRA tablosunda bulunan STRA_INC alanına eşitlemek için ise TBLSERITRA tablosundaki eski STRA_INC değerini TBLSTHAR tablosundaki ilgili hareketin aldığı yeni INCKEYNO değerine UPDATE komutu ile ekleyerek her iki tablodaki INCKEYNO ve STRA_INC alanları stok hareketi ve seri kaydı olarak birbirine sorunsuz bağlanmış oldu.

SQL Server Recovery Modelleri

Şirketimizde kullandığımız ERP programının kullandığı veritabanının Recovery Mode'nu daha önce Simple Recovery Mode düzeyinde tutuyorduk. Şirketimizde yapılan IT Denetlemesi sonucu denetimi yapan ekibin  Erp programında yapılan değişikliklerin geçmişe yönelik olarak  görülebilmesi gerektiğini söylemeleri üzerine sene başından itibaren Recovery Mode'u Full Recovery Mode'a alarak yapılan insert-update-delete işlemlerini görmeye başladık. Veritabanı Full Recovery Mode düzeyinde olunca bu defa transaction logların tutulduğu ldf dosyasının otomatik büyümesinden dolayı sene ortasına gelmeden mdf dosyasının boyutunu geçtiği durumlar da olmakta.

Resim- Full Recovery Mode'da MDF ve LDF dosyalarını göstermekte(Burada ldf dosyası mdf dosyasının boyutuna henüz ulaşmamış)

Sunucu yapılandırmanız ne kadar iyi olsa da bu defa yapılan işlemler transaction log dosyasına (ldf) yazıldığı için üretim sonu kaydı yaptığımız programı kullanan arkadaşlar üretim sonu kaydının yapıldığı anda sistem de yavaşlık olduğunu söylediler. Sorun, belirli periyotlarda otomatik transaction log yedeği  alınarak çözülmüş oldu. 15 dakikalık periyotlarla alınan transaction log yedeklerinin genelde mesai saati içinde boyutu yükselmekte ve bu boyut şirketinizde yapılan veritabanı operasyonu ile orantılı olarak kısa bir zamanda artabilmektedir. Alınan transaction log yedekleri kapasitesi yüksek depolama aygıtında arşivlenirse geçmişe yönelik hareketlere erişmiş oluruz.

Resim-15 dakika ara ile alınan transaction log yedeği.Yapılan insert-update-delete işlemine göre boyutlar farklı görünmekte.