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

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 »

SQL Server’deki bir sorgunun hangi yöntemle çalıştırılacağını SQL Server’in ürettiÄŸi Execution Plan’a bakarak anlayabiliriz. SQL Server’in sunduÄŸu gösterim planı ifadelerini (Showplan SET statements) kullanarak o anki Execution Plan hakkında daha geniÅŸ bilgi alabiliriz. Sorguya ait execution plan’ı görmek için temel olarak aÅŸağıdaki deyimler kullanılır.

SET SHOWPLAN_ALL ON
SET SHOWPLAN_TEXT ON
SET SHOWPLAN_XML ON
SET STATISTICS XML ON
SET STATISTICS PROFILE ON
SET STATISTICS IO ON
SET STATISTICS TIME ON Read the rest of this entry »

SQL Server 2005 ile birlikte “Surface Area Configuration” isimli ayrı bir programcık kurulur. Bu araç aracılığıyla SQL Server ve Analysis Services, SQL Server Agent, Full-Text Search, Integration Services, SQL Server Browser gibi SQL Server üzerinde çalışan alt servislerin yönetimi saÄŸlanır. Ayrıca Ad Hod Remote Queries, CLR Integration, DAC, Database Mail, xp_cmdshell gibi veritabanı tarafında SQL dünyası dışındaki özelliklerin aktif veya pasifleÅŸtirilmesi saÄŸlanır. Bu araca Start » Programs » Microsoft SQL Server 2005 altındaki Configuration Tools bölümden ulaşılır.

SQL Server 2008′te bu araç ayrı bir program olarak kurulmayıp Policy Based Management kapsamında sunulmaktadır. Policy Based Management, SQL Server üzerinde oluÅŸturulmuÅŸ olan kuralların yönetildiÄŸi alandır. Policy Based Management altında yeni policy (kural) oluÅŸturulabilir veya mevcut policy’ler yönetilebilir. PBM altındaki Facet bölümü policy oluÅŸtururken kullanabileceÄŸimiz temel özellikleri içermektedir. “Facet” kavramını SQL Server üzerinde veritabanı yöneticisi tarafında yönetebilecek özellikler olarak tanımlayabiliriz.

Konuya geri dönecek olursak “Surface Area Configuration” yönetimini SQL Server 2008′de Facets bölümü altında yapabiliyoruz.