Aylık arşivler: Mayıs 2012

CorFlags dönüştürme aracı

Bir Cevap Yazın

Visual Studio ile birlikte gelen CorFlags aracı PE image’a ait corflags section bölümünü dönüştürmek için kullanılır. Bu şu demek; bilindiği gibi .NET ortamında bir uygulama geliştirirken derleme işlemini istediğimiz 32-bit veya 64-bit ortamına göre gerçekleştirebiliriz. Bu durumda kullanılacak Assembly’ler ona göre aktifleştirilir. Yani uygulamayı 32-bit’e göre gerçekleştirirsek kütüphaneler aşağıdaki klasörden

…\WINDOWS\Microsoft.Net\Framework\v2.0.50727

64-bit’e göre gerçekleştirirsek aşağıdaki klasörden okunur.

…\WINDOWS\Microsoft.Net\Framework64\v2.0.50727

.NET Framework’ün kendisinde olmayan bir Assembly’i kullanmışsak bunu uygulamanın config dosyasında belirtmemiz gerekiyor. Aynı şekilde 64-bit makinelerde türüne göre GAC_32, GAC_64 ve GAC_MSIL Global Assembly Cache klasörleri mevcuttur. 32-bit ortamlarda sadece GAC_32 ve GAC_MSIL klasörleri bulunur. GAC_MSIL klasörü platformu belirsiz yani AnyCpu olarak derlenmiş Assembly’leri içerir.

Bir uygulamayı aşağıdaki seçeneklere göre derleyebiliriz;

Anycpu – platform belirsiz
x86 – 32-bit platform
x64 – x64 platform
itanium – IA platform

.NET derleyicisi default olarak uygulamayı anycpu türünde derler. Bu da o uygulamanın hem 32-bit hem de 64-bit ortamında çalışabileceğini belirtir. Bu nedenle portable assembly olarak isimlendirilir.

Fakat bazı durumlarda hazırladığımız bir uygulamanın mutlaka belli bir platformda örneğin ne olursa olsun hep 32-bit çalışmasını istediğimizde bu dönüştürmeyi CorFlags aracı ile gerçekleştirebiliriz.

Ben bu aracı daha çok bir Assembly’nin hangi platformda kullanılabileceğini öğrenmek için kullanıyorum. CorFlags şeklinde komutu çalıştırdıktan sonra aşağıdaki gibi bir sonuç elde edilir.

Version : v4.0.30319
CLR Header: 2.5
PE : PE32+
CorFlags : 0x9
ILONLY : 1
32BITREQ : 0
32BITPREF : 0
Signed : 1

Bu alanlar uygulamanın hangi .NET Framework versiyonunda built edildiğini, CLR versiyonunu gibi bilgileri belirtir. Örneğin bu dosya için PE değerinin PE32+ olması bu assembly’nin 64 bit olduğunu gösterir.

CorFlags aracını kullanmak için Visual Studio Command Prompt üzerinden çalıştırmak gerekir.

Stored Procedure’in Sonucunu Tabloya Aktarma

Bir Cevap Yazın

SQL Server’de bir Stored Procedure ‘ü çalıştırıp sonucunu bir tabloya aktarmak için genellikle önce o şemaya uygun tablo oluşturulur. Ardından o tabloya INSERT INTO ile data aktarılır. Aşağıdaki örnekte spGetData prosedürünün sonucuna uygun şemada bir #table1 oluşturulmuş ardından prosedürün sonucu bu tabloya aktarılmıştır.

CREATE TABLE #table1
(
   Column1 INT,
   Column2  VARCHAR(10)
)

INSERT INTO #table1 
Exec spGetData 1

Kolay bir yöntem olarak OPENROWSET fonksiyonunun kullanılmasıdır.

SELECT * INTO #table1 FROM OPENROWSET('SQLNCLI', 'server=(local)' , 
	'Exec spGetData ')

Shrink Esnasında “Backup, file manipulation operations” Hatası

Bir Cevap Yazın

Management Studio üzerinden veya Job aracılığıyla otomatik olarak SHRINK işlemi yapılmak istendiğinde aşağıdaki hata mesajı alınabilir.
Backup, file manipulation operations (such as ALTER DATABASE ADD FILE) and encryption changes on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed
Bu hata mesajına veri ambarı projesinde her gece shrink Job çalışırken almıştım. Bu mesajın 2 nedeni olabilir;

      O anda veritabanına ait dosyalarda değişiklik ekleme çıkarma yapılıyorsa. Yani mevcut MDF’lerden biri kaldırılıyor veya yeni MDF ekleniyorsa bu hata mesajı alınabilir. Bunu da bilindiği gibi ALTER DATABASE komutu aracılığıyla ADD FILE veya REMOVE FILE tümceleri kullanılarak yapılmaktadır.
      İkinci neden de o esnada sistemde backup alıyor olmasıdır ki ben de bu şekilde tecrübe edindim.

O esnada bu işlemler yapılıyorsa Shrink işlemi başarısız bir şekilde sonlandırılacaktır.

SQL Server VLF (Virtual Log File) Nedir ?

1 Yanıt

VLF, SQL Server tarafından dahili olarak yönetilen LDF içerisinde bulunan sanal log dosyalarıdır. Fiziksel log dosyaları (LDF dosyaları) veritabanı sistemi tarafından iç transaction yönetimi için birden fazla mantıksal dosyalara bölümlendirilir. Bir sistemde bu dosyaların sayısı artıkça özellikle sistemin yeniden açılma durumlarında o veritabanının toparlanma süresi (recovery time) uzadığı gibi LOG dosyasına ihtiyaç duyuldukça performans sorunu yaşanır. Bu tür çok log dosyalı veritabanlarında SQL servisini restart ettiğimizde o veritabanı uzun süre “Restoring” modunda kalabiliyor. Bu veritabanının kendine gelme süresi bazen 1-2 saati bulabiliyor.
İdeal durumda VLF sayısının 50 veya altı olması beklenir. Bu rakamın üstündeki her dosya performansı olumsuz etkileyecektir. Mevcut veritabanında ne kadar VLF olduğunu anlamak için DBCC LOGINFO komutu kullanılır.
Bu sayıyı düşürmek için sık sık Transaction Log Backup alınabilir.
BACKUP LOG VeriTabaniAdi TO SurucuAdi
Veya DBCC SHRINKFILE komutu aracılığıyla Transaction Log dosyası mümkün olduğunca sıkıştırılır. Transaction Log içerisinde ne kadar boş alan olduğunu DBCC SQLPERF(LOGSPACE) komutuyla öğrenebiliriz.