SQL Server Management Studio (SSMS) hiç şüphesiz SQL Server sistemlerini yönetmek ve üzerinde uygulama geliştirmek için en güçlü araçtır. Hali hazırda çalışan bir uygulama için belli anlarda bu aracı açıp standart sistem izleme prosedürleri çalıştırıyorum. Bu işlemleri yapmak nasıl zaman kazanabilirim derken SSMS’in açılma esnasında dışarıdan parametre alabildiğini öğrendim. Bu da bu tür işlemler için kısayol sağladı.
Okumaya devam et
Aylık arşivler: Mart 2012
64 bit SSIS – Excel Connection Manager Kullanımı
SQL Server 2008 Integration Services içerisinde veri aktarımı esnasında Excel dosyasını kaynak veya hedef olarak kullanmamıza imkan tanıyan “Excel Source” ve “Excel Destination” bileşenleri bulunmaktadır.
Fakat bu bileşenleri 64 bit SQL Server 2008’in olduğu ortamda kullanmak istediğimizde aşağıdaki hatayla karşılaştık.
[Connection manager “Excel Connection Manager”] Error: SSIS Error Code DTS_E_OLEDB_EXCEL_NOT_SUPPORTED: The Excel Connection Manager is not supported in the 64-bit version of SSIS, as no OLE DB provider is available.
Bunun nedeni Excel Connection Manager’in 64bit sürümünün olmayışıdır. Bu bağlantı nesnesini kullanmak için hazırladığımız SSIS paketini 32bit modunda çalıştırmalıyız.
Okumaya devam et
The partner transaction manager has disabled its support for remote/network transactions
SQL Server içerisinde Linked Server, OPENROWSET, OPENQUERY, OPENDATASOURCE, RPC, BEGIN DISTRIBUTED TRANSACTION yöntemlerini kullanarak uzaktaki bir sunucudaki veritabanı üzerinde tanımlama ve düzenleme işlemlerini transaction yönetiminde yapmak için karşı sunucuda Distributed Transaction Coordinator (DTC) servisini aktifleştirmemiz gerekir. Yani aşağıdaki gibi bir sorgu çalıştırdığımızda eğer karşı makineden DTC çalışmıyorsa MSDTC on server ‘DW’ is unavailable. hata mesajını alırız.
BEGIN DISTRIBUTED TRANSACTION SELECT * FROM DW.Deneme.dbo.Urun ROLLBACK
SQL Server’de Uyarı Log Dosyaları Yönetimi
SQL Server’de kullanıcıların girişlerini, hataları, uyarıları, backup sonuçları gibi iç sistemle veya kullanıcı işlemleriyle ilgili mesajları Log dosyalarına yazar. Bu dosyalar varsayılan olarak SQL Server’in kurulum klasörünün altıdaki Log klasörünün altında bulunur.
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log
Bu klasörün altında ERRORLOG.1, ERRORLOG.2, ERRORLOG.3 . şeklinde dosyalar oluşturulur.
SQL Server her servis yeniden başladığında o tarihe ait yeni bir dosya oluşturur bir sonraki açılışa kadar aynı dosyayı log verilerini yazar. Bu da özellikle çok uzun süre açık kalan canlı sistemlerde log dosyalarının büyümesine neden olmaktadır. Bu da servisin dosyayı parse etmesi, sistem yöneticininin dosyada bir mesaj aramasını ağırlaştırır. Burada bir optimizasyon yapmak adına servisi kapatmadan SQL Server’in bundan sonra yeni bir log dosyasını oluşturmasını sağlayabiliriz. Bunun sp_cycle_errorlog prosedürü veya DBCC ERRORLOG komutu kullanılır. Bunlar birini çalıştırdığımızda otomatik olarak yeni bir log dosyası oluşacaktır. Böylece büyümüş olan log dosyaları daha küçük parçaları bölünmüş olur.
Burada diğer önemli konu SQL Server’in default olarak son 6 log dosyasını tutuyor olmasıdır. SQL Server’in dosyaları silmeden önce kaç dosya bırakacağını Management » SQL Server Logs menüsünü sağ tıklayıp Configure bölümünden ayarlayabiliriz.
“Configure SQL Server Error Logs” penceresindeki “Limit the number of error log files before they are recycled” seçeneğini aktifleştirip kaç dosyanın aktif olacağını belirleyebiliriz.
Sonuçta ne kadar log dosyası kayıtlarımızda bulunursa istenmeyen bir durum olduğundan o kadar eskiye gidip log dosyaları bizi yönlendirebilir.
SQL Server’de yönetimle ilgili log dosyalarını okumak için sys.xp_readerrorlog veya sp_readerrorlog prosedürleri kullanılır.
SQL Server’in güncel olarak kullandığı Error Log setine ait fiziksel dosyanın konumunu servis başladığında yazdığı log cümlelerinde aşağıdaki ifadeyi filtreleyerek öğrenebiliriz.
USE master GO xp_readerrorlog 0, 1, N'Logging SQL Server messages in file', NULL, NULL, N'asc' GO
32 bit ve 64 bit Arasında Data Taşıma
32 bit sistemde koşturduğumuz SQL Server’in zamanla daha fazla belleğe ihtiyaç duyması veya daha güçlü bir makineye geçirirken yeni işletim sistemi kurmamız dolayısıyla 64 bit ortama geçme durumu olabiliyor. Forumlarda gelen sorulara bakıldığı zaman bu konuda bir endişe olduğu gözlemledim. Temelde işlemci seviyesinden bu mimarilerde disk format yapısı değişmediği ve SQL Server bu mimarilere özgü bir data veya log file oluşturmadığı için herhangi bir yöntemle veritabanını x64, x86 ve IA64 tabanlı sistemler arasında kolayca taşıyabiliriz. x86’de backup alıp x64’e sorunsuz bir şekilde restore edebiliriz. Aynı şekilde detach/attach yöntemini tercih edebiliriz. Aynı şekilde high availability için kullandığımız Log Shipping, Mirroring, Transactional / Merge Replication yöntemlerinde de çapraz mimariler arasında data aktarımı yapılabilir.