Kategori arşivi: SQL Server, Oracle

Sql Server 2000, Sql Server 2005, Sql Server 2008, Sql Server 2012, Sql Server Reporting Services, Oracle, SSIS SQL Server Integration Services

Backup / Restore / Index Reorganize İşlemi Ne kadar Sürecek

Geçen gün virtual device üzerinden restore işlemi yaparken bu işlemin tahminen ne kadar süreceğini öğrenmek istedim. Veritabanı RESTORING modunda görünüyor ancak bu işlemi yapan Agent network üzerinden çalıştığın için hiçbir yerde percent değeri yazmıyord.
Konuyu biraz araştırınca sys.dm_exec_requests isimli DMV’deki percent_complete kolonunun Backup / Restore / Index Reorganize işlemleri için yüklendiğini öğrendim.

SELECT  command,
        session_id,
        percent_complete,
        DATEADD(ms, estimated_completion_time, GETDATE()) AS estimated_completion_time,
        start_time
FROM    master.sys.dm_exec_requests
WHERE   percent_complete > 0

Bu sorguda işlemin ne zaman başladığı, ne kadarının tamamlandığı ve tahmini ne zaman biteceğini döndürmektedir. Eğer o esnadan birden fazla işlem varsa aşağıdaki script aracılığıyla sadece BACKUP / RESTORE işlemi sorgulanabilir.

SELECT command, s.text, start_time,percent_complete,
CAST(((DATEDIFF(s,start_time,GetDate()))/3600) as varchar) + ' hour(s), '
+ CAST((DATEDIFF(s,start_time,GetDate())%3600)/60 as varchar) + 'min, '
+ CAST((DATEDIFF(s,start_time,GetDate())%60) as varchar) + ' sec' as running_time,
CAST((estimated_completion_time/3600000) as varchar) + ' hour(s), '
+ CAST((estimated_completion_time %3600000)/60000 as varchar) + 'min, '
+ CAST((estimated_completion_time %60000)/1000 as varchar) + ' sec' as est_time_to_go,
dateadd(second,estimated_completion_time/1000, getdate()) as est_completion_time
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) s
WHERE r.command in ('RESTORE DATABASE', 'BACKUP DATABASE', 'RESTORE LOG', 'BACKUP LOG')

SQL Server Change Data Capture (CDC) Nedir?

Kritik verilerin bulunduğu veritabanı uygulamalarında en önemli ihtiyaçlardan biri de kullanıcının yaptığı değişikliklerin kayıt altına alınıyor olmasıdır. Bu amaçla ilgili tablolara ait bir log/tarihçe tablosu oluşturulup değişiklikler bu tabloya yazılır. Bunun için ya veritabanı içerisinde ilgili tablolar üzerinde trigger oluşturulur veya uygulama içerisinde değişiklikler uygulanmadan önce değişiklikler tarihçe / arşiv tablolarına aktarılır.
SQL Server 2008 ile sunulan Change Data Capture (CDC) özelliği tablo üzerinde gerçekleşen INSERT, DELETE, UPDATE faaliyetlerinin doğrudan SQL Server tarafından izlenmesini ve kayıt altına alınmasını sağlar. Bu özelliğin en önemli anvantajı doğrudan log altyapısını kullandığı için bizim oluşturacağımız algoritmalara göre daha performanslı olmasıdır. Ayrıca tüm satırı değil sadece değişikliğin yapıldığı kolonları alması da ergonomik bir yapı sağlamaktadır.
MSDN’den alınmış aşağıdaki illustration CDC’nin temel çalışma akışını göstermektedir.

Okumaya devam et

Resource Database Nedir ?

SQL Server 2005 ile birlikte Resource isimli sistem veritabanı geldi. Salt-Okunur ve gizli olan bu veritabanı “sys” şeması altında bulunan tüm sistem nesnelerini içerir. Kullanıcı veri veya şemasıyla ilgili herhangi bir bilgi içermez. Bu veritabanın amacı upgrade işlemlerini hızlı yapılmasını sağlamaktır.
Resource veritabanının dosyaları mssqlsystemresource.mdf ve mssqlsystemresource.ldf olarak isimlendirilmiştir. Bu dosyalar “:\Program Files\Microsoft SQL Server\MSSQL10_50.\MSSQL\Binn\” altında bulunmaktadır.
SQL Server üzerindeki Resource veritabanını versiyonu ve en sonki upgrade bilgisini görmek için sunucuya ait aşağıdaki özellikler okunur.

SELECT SERVERPROPERTY('RESOURCEVERSION')
GO
SELECT SERVERPROPERTY('RESOURCELASTUPDATEDATETIME')

Gerekli durumda bu database’e ait dosyaları taşımak için SQL Server servisini -F parametresi T3608 trace flag koduyla başlatmak gerekir. Single User modunda iken “ALTER DATABASE” komutlarıyla sözkonusu mdf ve ldf dosyalarını kolayca taşıyabiliriz.

ALTER DATABASE mssqlsystemresource MODIFY FILE (NAME=data, FILENAME= 'C:\mssqlsystemresource.mdf')
ALTER DATABASE mssqlsystemresource MODIFY FILE (NAME=log, FILENAME= 'C:\mssqlsystemresource.ldf')

Geçici Tablo ve Tablo Türü Değişken Arasındaki Fark

Çalışma esnasında bir kayıt listesinin sonucunu geçici saklamak için geçici tablo (temporary table) veya tablo türü değişken (table variable) kullanırız. Peki bunların arasındaki fark nedir ?
SQL Server’de yerel (local) ve genel (global) olmak üzere 2 tür geçici tablo kullanırız. Yerel tabloları başında “#” olacak şekilde isimlendiririz. Genel tabloları başında “##” olacak şekilde isimlendiririz.

--Yerel geçici tablo
SELECT * INTO #t1 FROM Alisveris

--Genel geçici tablo
SELECT * INTO ##t1 FROM Alisveris

Yerel geçici tablo ile genel geçici tablo arasındaki tek fark, yerel tabloya sadece oluşturulduğu oturumdan erişilebilir. Genel tabloya ise diğer oturumlardan da erişilebilir. Geçici tabloların yaşam süresi oturumlarıyla sınırlıdır. Yani oluşturuldukları oturumda DROP edildikleri zaman veya oturum kapatıldığı zaman tablolar silinmiş olur.
Geçici tablolar üzerinde normal tablolarda yaptığımız her türlü (clustered / non-clustered index oluşturma, identity kolon kullanmaz, transaction yönetimi .) DDL ve DML işlemi yapılabilir. Sadece Foreign Key constraint oluşturulamaz. Geçici tablolar normal tablolar gibi diskte (tempdb) tutulur ve transaction log tarafında loglanır.
Tablo türü değişkenler de geçici tablolar gibi aynı amaç için kullanılır. SQL Server’de değişken tanımlanır gibi tanımlanır. Bu tablolar üzerinde sadece cluster index oluşturulabilir.

--Tablo oluştur
DECLARE @Alisveris TABLE (SatirId INT identity(1,1) primary key,
	UrunAdi VARCHAR(50) )

--Kayıt girelim
INSERT @Alisveris VALUES('Urun1')
INSERT @Alisveris VALUES('Urun2')

--Tabloyu okuyalım
SELECT * FROM @Alisveris

Temporary tables ve table variable arasındaki benzer ve farklılıklar şunlardır;

  1. Her ikisi de TEMPDB içerisinde oluşturulur.
  2. Table variable constraint tarafında daha kısıtlı yeteneğe sahip. Primary Key oluşturulabilse de default ve check constraint konusunda başarılı sayılmaz.
  3. Her ikisi üzerinde cluster index oluşturulabilir.
  4. Table variable üzerinde non-cluster index oluşturulamaz.
  5. Table variable için statistic bilgiler oluşturulmaz.
  6. Ve en önemli fark temporary table, transaction yönetimini desteklerken table variable desteklemez.

SQL Server CPU ve Memory Bilgisi

Üzerinde çalıştığım veri ambarı projesi için gerekmişti. SQL üzerinden makinein sahip olduğu işlemci ve bellek bilgisini almak istedim. Bunun için aşağıdaki script kullanılabilir.

-- CPU bilgisini Registry'den alacağız
EXEC xp_instance_regread
'HKEY_LOCAL_MACHINE',
'HARDWARE\DESCRIPTION\System\CentralProcessor\0',
'ProcessorNameString';

-- CPU ve Memory bilgisi
SELECT cpu_count AS [CPU sayısı (mantıksal)]
,hyperthread_ratio
,cpu_count/hyperthread_ratio AS [CPU sayısı (fiziksel)]
,physical_memory_in_bytes/1048576/1024 AS [Toplam bellek miktarı (GB)]
FROM sys.dm_os_sys_info;

SQL Server Dedicated Administrator Connection (DAC)

SQL Server 2005 ile birlikte DAC (Dedicated Administrator Connection), SQL Server’in yoğunluktan, kilitlenmenin oluşmasından hiçbir bağlantıya yanıt vermediği bir anda sistem yöneticisinin sisteme giriş yapabilmesini sağlayan önemli bir özelliktir. Bu tür durumlarda SQL Server’i restart etmek sorun yaratabileceği için sisteme bağlanıp olup biteni görmekte fayda var. Bunun için öncelikle sunucunu DAC özelliğinin aktif olması gerekir. Bu özelliği yere veya uzaktan erişim için ayarlayabiliriz.

Use master
GO
--0 = Yerel Bağlantı İzni,
--1 = Uzak Bağlantı İzni
sp_configure 'remote admin connections', 0
GO
RECONFIGURE
GO

SQL Server 2005’te “Surface Area Configuration” aracında da aynı ayara erişilebilir.
Bu özelliği aktifleştirdikten sonra SQL Server’e hem komut satırından (SQLCMD) hem de Management Studio üzerinden erişiebiliriz.
Okumaya devam et

SQL Server Instance Hangi Portu Kullanıyor

Birden fazla SQL Server instance kurduğumuz makinede hangi instance hangi portu kullanıyor bazen bunu bulmakta zorlanabiliyoruz. Uzaktan makineye erişemiyor olmamızın nedeni çoğu zaman doğru portu bilmiyor olmamızdır. SQL Server’in hangi portu kullandığını birkaç şekilde öğrenebiliriz.
Okumaya devam et

SQL Server Management Studio Özelleştirme ve Hızlandırma

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

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

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