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')

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 →

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')

Ç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.

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 →