SQL Server ASP.NET C# Kitabı

Oracle’da satırların disk üzerindeki fiziksel konumunu döndüren ROWID komutu bulunmaktadır. Bu tür komutlar değerleri veritabanında tutulmadığı o anda hesaplandığı için sahte komut(pseudo-column) olarak tanımlanır. Birçok veritabanı yönetim sisteminde her satır için arka tarafta bir ID bilgisi tutulmaktadır. Fakat bu değerleri geliştirilerin okuması zor olabiliyor. SQL Server 2005′te aynı amaç için %%lockres%% komutu eklendi. Bu komutun SQL Server 2008′deki karşılığı %%physloc%% komutudur. Read the rest of this entry »

Kendimiz bir servis yazdığında veya SQL Server kurulumunda en çok karşımızı çıkan konusu servisi hangi kullanıcı çalıştıracak. Bu iş genel olarak Local System, Local Service, Network Service kullanıcı hesapları tercih edilir. Bu küçük yazıda bu kullanıcıların farkını belirtip SQL Server cephesinde nasıl bir tercih yapmamız gerektiğini not alacağız.

Local System : Makine üzerindeki en yetkili hesaptır. Hatta Administrator hesabından daha yetkilidir diyebiliriz. Hem yerel hem de network kaynaklarına erişebilir. Bu hesabın adı gerçekte “NT AUTHORITY\SYSTEM” olarak geçmektedir. Temelde NT AUTHORITY\SYSTEM ve Builtin\Administrators yetkilerini içerir. Bu yüzden SQL Server tarafından default olarak sysadmin rolünü alır.

Network Service : Local System / Administrator kullanıcısına göre daha az yetkili olup network kaynaklarına erişecek servis kullanıcısıdır. Bu hesabın kullanıcı adı “NT AUTHORITY\NETWORK SERVICE” olarak geçmektedir.

Local Service : Network Service kullanıcısıyla aynı sınırlı yetkilere sahip olup tek farkı network kaynaklarına erişemez. Bu hesabın kullanıcısı “NT AUTHORITY\LOCAL SERVICE” olarak geçmektedir. Bu account SQL Server veya SQL Server Agent servisleri tarafından desteklenmemektedir. Bu kullanıcı genellikle makinenin dışındaki kaynaklara erişmeyecek servisler tarafında tercih edilir.

SQL Server servisi için mümkün olduğunca Local non-system veya Service kullanıcısını kullanmak yerine bu iş oluşturulmuş bir Domain hesabının kullanılması tavsiye edilir. Ve bu domain hesabının da olabildiğince minimum yetkilere sahip olması gerekmektedir. Eğer SQL Server üzerinden dosya paylaşımı, linked server gibi network kaynak erişimi olacaksa doğru yetkilendirilmiş AD kullanıcısı tercih edilmesi daha doğru olacaktır. Ayrıca birden fazla SQL Server sunucusu varsa bunların tek bir domain kullanıcısı tarafından başlatılması yönetim kolaylığı sağlayacaktır. Eğer SQL Server’in bulunduğu makine Domain’de bulunmuyorsa yerel kullanıcı servisi kullanıcısı olarak tercih edilebilir. Tabi bu kullanıcının Administrator yetkilerine sahip olmamasına dikkat edilmelidir.

Özetle SQL Server ve alt birimlerini için mümkün olduğunca az yetkili bir kullanıcıyla çalıştırmak ve SQL Server ve Agent için ayrı kullanıcıları tercih etmek tavsiye edilir.

SQL Server 2000′de mevcut bir indexi aktif veya pasif yapamıyoruz. Sadece drop edebiliriz. Oysa bazı durumlarda örneğin optimizasyon işlemlerinde veya büyük aktarımlar için (DTS, BCP, BULK INSERT ) kısıtlı zamanlarda geçici olarak bazı indexleri pasif yapma ihtiyacı doğabiliyor. SQL Server 2005 ve sonrasında gelen ALTER INDEX komutu sayesinde bu işlem yapılabilmektedir. Read the rest of this entry »

SQL Server’in bulunduğu makineyi değiştirdikten sonra mevcut sistemde tanımlı Job’ları da yeni sunucuya aktardık. Yöntem olarak msdb veritabanını attach ettik. Bu Job’lar SSIS paketlerini çalıştırıyor. Job’ları çalıştırdığımızda aşağıdaki hatayı aldım.

Unable to start execution of step 1 (reason: The SSIS subsystem failed to load [see the SQLAGENT.OUT file for details]; The job has been suspended). The step failed.

Bu sorunun nedeni eski ile yeni sunucunun SQL Server kurulum klasörlerinin farklı oluşuymuş. Çünkü SQL Server TSQL, CmdExec, SSIS, PowerShell, Snapshot, LogReader, Distribution … gibi SQL Server Agent üzerindeki alt sistemlere ait DLL bilgilerini msdb.dbo.syssubsystems tablosunda tutuyor. Bu tablodaki kütüphane adresleri eski sunucuda farklı olduğu için sistem SSIS paketlerini hangi motorla çalıştıracağını bilemiyor.

Bu sorunun kolay bir çözüm var. sp_verify_subsystems prosedürü ilgili alt sistemler için doğru DLL adreslerini yeniden oluşturuyor. Aşağıdaki gibi tablodaki mevcut kayıtları silip ilgili prosedürü çalıştırmamız yeterli olacaktır.

--Mevcut kayıtları sil
DELETE FROM msdb.dbo.syssubsystems

--Tabloyu yeni DLL adresleriyle yeniden doldur
EXEC msdb.dbo.sp_verify_subsystems 1

Birkaç gün önce sunucu iyileştirme kapsamında SQL Server 2008 instance üzerinde bulunan bir veritabanını detach edip network üzerinden ikinci sunucuya kopyalayıp aynı şekilde SQL Server 2008 R2 üzerine attach etmeye çalışırken aşağıdaki hatayla karşılaştım.

Msg 3415, Level 16, State 3, Line 1
Database [database_name] cannot be upgraded because it is read-only or has read-only files. Make the database or files writeable, and rerun recovery.
Msg 1813, Level 16, State 2, Line 1
Could not open new database [database_name]. CREATE DATABASE is aborted.

Mesajın içeriğine bakınca database dosyalarının işletim sistemi üzerinde salt-okunur olduğunu düşündüm. Oysa dosyaları read-only durumda değildi. SQL Server’i çalıştıran kullanıcının permission ayarlarına baktım onlar da full görünüyordu. Yaptığım araştırmalarda bu işin nedenlerinin farklı olabileceği ve farklı şekillerde çözülebileceği söyleniyor. Muhtemel neden ve çözümleri aşağıda bulabilirsiniz;

Öncelikle bu dosyaların attach edilmesi esnasında başka bir instance tarafından kullanılmadığında ve dosya özelliklerinden ve ya kullanıcı yetkilerinden salt-okunur olmadıklarından emin olmamız gerekiyor.

Birinci çözüm olarak “Everyone” kullanıcısına full access yetkisi verilir. Dosyalar attach edildikten sonra işlem başarılı olduktan sonra Everyone yetkisi geri alınır.

İkinci çözüm veya sorunun nedeni olarak SQL Server kullanıcısına bakılabilir. Benim sorunum buydu. SQL Server servisi AUTHORITY\NETWORKSERVICE kullanıcısıyla başlatılmıştı. Bu kullanıcının attach etmek hakkı olmadığı için servis kullanıcısını LOCAL ACCOUNT olarak değiştirince sorun çözüldü.

JQuery aracılığıyla bir formu ASP.NET sayfasına doğrudan POST veya GET ile gönderebilmek için Form Serialize işlemi gerçekleştirilir. Bu amaçla .serialize() veya .serializeArray() yordamları kullanılır.

Özellikle Internet Explorer ortamında bir formu serialize edip ASP.NET sayfasında okumaya çalıştığımızda Türkçe Karakter sorunu yaşanmaktadır. Örneğin “öçşğüİ” değeri Ã¶Ã§ÅŸÄŸÃ¼Ä şeklinde görünmektedir. Bu karakterlerin UTF-8 olarak gönderilmesi için aşağıdaki örnekte gösterildiği gibi “application/x-www-form-urlencoded; charset=utf-8″ şeklinde content teype belirmek gerekiyor.

var formValue=$("#aspnetForm").serializeNoViewState();

$.ajax({
	type: "POST",
	url: "OrnekSayfa.aspx?Prm=1",
	data: formValue,

	beforeSend: function (xhr) {
	    xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded; charset=utf-8");
	},

	contentType: "application/x-www-form-urlencoded; charset=utf-8",
	dataType: "json", 

	success: function (msg, status) {
		alert(msg);
	},
	error: function (xhr, msg, e) {
	    alert("Hata Oluştu!\n" + xhr.responseText +"\n"+msg );
	},

	complete: function() {
		alert('İstek başarıyla gönderildi.');
	}
});

ASP.NET sayfasına POST işlemi yaptığımızda post edilen metin içerisinde “<>” gibi web safyaları için tehlike oluşturabilecek değerler gönderildiği zaman ASP.NET WP, “A potentially dangerous Request.Form value was detected from the client” hatasını fırlatır. Bu hatayı engellemek yani kullanıcının bu tür değerleri girmesine izin vermek için ASP.NET sayfasının tanımlama satırına validateRequest=”false” ibaresi yazılır. Aynı şekilde uygulamadaki tüm sayfalar için bu ayarın geçerli olması için Web.Config dosyasına aşağıdaki gibi ekleme yapılabilir.

<pages validateRequest="false" />

Cross-site scripting (XSS) attack riskini engellemek için ASP.NET tüm sürümlerinde request validation özelliği varsayılan olarak aktifdir. ASP.NET’in önceki sürümlerinde bu doğrulama işlemi sadece ASPX sayfaları için yapılmaktaydı. 4.0 sürümüyle birlikte doğrulama işlemi doğrudan BeginRequest aşamasında devreye alınacak şekilde düzenlendi. Böylece uygulamaya gelen tüm istekler için yani sadece ASPX sayfaları değil, Web Servisi çağırma, HTTP handler çalıştırma gibi tüm ASP.NET kaynaklarına istek gönderildiği zaman doğrulama işlemi devreye alınmış oldu.

Bazı durumlarda .NET Framework 4.0 altında eski sürüm ugyulamalarını çalıştırma durumumuz olabilir. Bu durumda hangi sürüm algoritmasının kullanacağını belirtmek için requestValidationMode niteliği kullanılır.

<system.web>
<httpRuntime requestValidationMode="2.0" />
</system.web>

Kurulu olan bir replikasyona yeni nesne ekleme, mevcut nesne silme gibi işlemler bir gereksinim olduğu gibi bazı durumlarda tablodaki kolonların veri tipi değişimi, kolon adı değişimi gibi ihtiyaçlar da doğabiliyor. Daha önce yazdığımız SQL Server Replication – Yeni Tablo Ekleme makalesinde replikasyona yeni bir tablo nesnesinin nasıl ekleneceğini örneklendirmiştik. Bu yazıda da bir tablodaki kolonu replikasyona eklemek, replikasyonda çıkarmak ve şemasını değiştirdiğimizde replikasyonun nasıl etkileneceğini göreceğiz. Read the rest of this entry »

SQL Server 2000 üzerinde kurduğumuz replikasyon aracılığıyla 50 tane şubeyi merkeze kolayca ve hızlıca taşıyabildik. Ancak SQL Server 2005 kullanan şubelerimiz nedenini henüz çözemediğim bir yavaşlıktan dolayı şube tarafında çok uzun sayıdaki transactionlar merkeze geç aktarılıyor. Farklı alternatifler denememe rağmen başarılı olamadık. Şube tarafındaki bulk işlemlerden dolayı bir transaction içerisinde çok sayıda command eklenmektedir. Buradaki sıkıntı kuyrukta bekleyen çok sayıdan komut satırının herhangi bir bağlantı kesilmesinde rollback edilecek olması ve her defasında yeniden baştan itibaren aboneye gönderilmesidir. Örneğin bir transaction setinde 100bin komut olduğunu düşünelim. Bunları adım adım aboneye gönderirken 90bininci satırda herhangi bir bağlantı kesilmeside abone üzerinde tüm işlemler rollback edilecek ve bir sonraki bağlantıda 100bin satır yeniden gönderilecektir. Bu işlemi hızlandırmak için bir çözüm bulamadım. Bunun yerine bir transaction içerisine daha az komut eklenecek şekilde bir düzenleme yapmak en azından rollback sürecinde daha az satır için gerigönderme işlemi yapmış olacaktır.

Bu işlem için SQL Server 2000 SP1 ile gelen MaxCmdsInTran parametresi kullanılmaktadır. Bu parametre için MSDN’de aşağıdaki tanım yazılmıştır.

-MaxCmdsInTran number_of_commands

Requires Service Pack 1 or later. MaxCmdsInTran specifies the maximum number of statements grouped into a transaction as the Log Reader writes commands to the distribution database. Using this parameter allows the Log Reader Agent and Distribution Agent to divide large transactions (consisting of many commands) at the Publisher into several smaller transactions when applied at the Subscriber. Specifying this parameter can reduce contention at the Distributor and reduce latency between the Publisher and Subscriber. Because the original transaction is applied in smaller units, the Subscriber can access rows of a large logical Publisher transaction prior to the end of the original transaction, breaking strict transactional atomicity. The default is 0, which preserves the transaction boundaries of the Publisher.

Bu parametre Log Reader servisi için kullanılmaktadır. Görsel olarak set edilecek bir alan bulunmamaktadır. Bunun için SQL Server Agent altında çalışan Log Reader servisine ait Job’ın özellikleri kullanılır. Log Reader job’ının Properties menüsü tıklanarak Agent’i çalıştıran adıma “-MaxCmdsInTrans 1000″ şeklinde değer girilebilir. Bu durumda Log Reader bulk işlemlerinde her transaction bloğunda 1000 komut olacak şeklinde ayarlama yapar.

Bu yazıda SQL Server 2005 ile birlikte gelen ve özellikle birçok Job tanımlanmış sistemlerde kolaylık sağlayacak bir özelliği paylaşmak istiyorum. Tanımlanmış olan bir schedule’in birden fazla Job tarafından paylaşılabiliyor olması. Özellikle birçok Job’ın olduğu durumlarda bazılarını aynı anda başlatma ihtiyacımız olabilir. Bunlar için tek bir zaman tanımlayıp gerektiği durumda zaman ayarlarını güncelleme imkanımız olabilmektedir. Read the rest of this entry »