Visual Studio gibi başarılı bir editörün özellikle 2010 sürümünden sonra geliştirilen eklentileri programcılar için önemli kolaylıklar sağlamaktadır. Fakat çoğu zaman editörü yavaşlattığı için zorunlu olmadıkça bu eklentileri yüklemiyorum. Fakat geçenlerde Java Script tarafında code-behind tarafındaki #region ifadesine benzer bir yöntemin olup olmadığını araştırırken Microsoft’un çıkardığı “JScript Editor Extensions” isimli extension çok işimi gördü. Bu sayede Java Script tarafındaki parantezlerle boğuşmamış olacağız. Daha kolay iç içe kod yazabileceğiz.

Bu sorun için macro çözümleri de geliştirilmiş ancak çok ilgimi çekmedi. Araçla ilgili detaylar aşağıdaki adreste bulunmaktadır;

http://visualstudiogallery.msdn.microsoft.com/872d27ee-38c7-4a97-98dc-0d8a431cc2ed

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. SQL Server 2005 tarafında aşağıdaki gibi kullanıyoruz.

SELECT *,%%lockres%% FROM OGRENCI

Şekilde görüldüğü gibi SQL Server her satırı tekil bir RID değeriyle ayırmış durumda. Bu adres bilgisi verinin bulunduğu Data File:Page:Row Slot değerini içermektedir.

Kaynak kilitlemesi doğrudan fiziksel alan üzerinden olmaktadır. Bunu aşağıdaki gibi net bir şekilde görebiliriz. OGRENCI tablosu üzerinde 2 INSERT ve 1 UPDATE işlemi gerçekleştireceğiz. Transaction açıkken tablonun lock durumuna bakacağız. Aktif kilitlemeleri görmek için sys.dm_tran_locks isimli DMV kullanılabilir.

BEGIN TRAN

UPDATE OGRENCI SET AdSoyad='Serdar' WHERE AdSoyad='Ömer'
INSERT OGRENCI VALUES('Berk')
INSERT OGRENCI VALUES('Berk')

SELECT
    o.NAME obj_name, l.resource_description, l.request_mode, l.request_status, request_owner_type, request_session_id,
    ogr.*
FROM sys.dm_tran_locks l
    INNER JOIN sys.dm_exec_sessions s on l.request_session_id = s.session_id
    INNER JOIN sys.partitions p on l.resource_associated_entity_id = p.hobt_id
    INNER JOIN sys.objects o ON o.object_id = p.object_id
    CROSS APPLY (SELECT *
                         FROM OGRENCI (NOLOCK)
                         WHERE %%lockres%% = l.resource_description) ogr
ROLLBACK

Şekilde de görüldüğü gibi SQL Server ilgili satırlar üzerinde exclusive lock (X) türünde bir kilit yerleştirmiş.

SQL Server 2008′de aynı komut çalışmakla birlikte %%physloc%% isminde yeni komut eklendi.

SELECT *,%%physloc%% FROM OGRENCI

SQL Server 2008′deki bu komut hexadecimal türünde değer döndürmektedir. Bu değerin kolayca okunabilmesi için sys.fn_PhysLocFormatter fonksiyonu kullanılır.

SELECT %%physloc%% AdresHex,
sys.fn_PhysLocFormatter(%%physloc%%) Adres,
* FROM OGRENCI

“Zeynep” kaydı 1 nolu data file içerisindeki 79 nolu data page içerisindeki 2 nolu slotta bulunmaktadır.

Daha önceki makalelerimde anlattığım gibi bir data page yapısını görmek için DBCC PAGE komutu kullanılabilir. Bu komut aşağıdaki parametreleri alır.

• Database ID veya Database Adı
• Data File Numarası
• Data Page Numarası
• Sayfa içeriğinin detay seviyesi (ne kadar detay yazdırılacak)
• 0 = Başlık
• 1 = Başlık ve Satırlar için hex açıklama
• 2 = Başlık ve Page seviyesinde detay
• 3 = Başlık ve Satırların detaylı içeriği

DBCC PAGE ({dbid|dbname}, pagenum [,print option] [,cache] [,logical])

DBCC TRACEON(3604)
DBCC PAGE (Deneme, 1, 79, 3)
DBCC TRACEOFF(3604)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Bu komutun gerçek hayatta kullanıldığı alanlardan biri üzerinde herhangi bir unique key olmayan tablolardaki çift kayıtların silinmesidir. Bu kayıtları silmek için kayıt değerlerin göre gruplama yapıp en düşük veya en yüksek fiziksel konuma sahip olanlar hariç diğerleri silinir. OGRENCI tablosunda 2 tane “Ahmet” değeri vardı bunları tek düşürmek için aşağıdaki kod yeterli olacaktır.

DELETE OGRENCI
WHERE OGRENCI.%%physloc%%
NOT IN (SELECT MIN(%%physloc%%)
        FROM OGRENCI
        GROUP BY AdSoyad);

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.

Aşağıdaki komutları kullanarak örnek MUSTERI tablosunu oluşturalım.

--Tabloyu oluşturalım
CREATE TABLE MUSTERI(MusteriId int,AdSoyad varchar(50),KayitTarih smalldatetime)
GO
--Tablo üzerinde index oluşturalım
CREATE UNIQUE CLUSTERED INDEX IX_MusteriId ON MUSTERI(MusteriId)
GO
CREATE INDEX IX_AdSoyad ON MUSTERI(AdSoyad)
GO
CREATE INDEX IX_KayitTarih ON MUSTERI(KayitTarih)
GO
--Tabloya örnek kayıt girelim
INSERT INTO MUSTERI VALUES(1,'Ahmet Kaymaz',GETDATE())
INSERT INTO MUSTERI VALUES(2,'Ömer Kaymaz',GETDATE())
INSERT INTO MUSTERI VALUES(3,'Zeynep Kaymaz',GETDATE())

Bir non-clustered index’i disable ettiğimiz zaman sorguları en az maliyetle çalışmasından görevli SQL Server Optimizer aracı bu index’leri yoksayar. Ayrıca index datası fiziksel olarak silinir. Aşağıdaki sorguyu çalıştırıp Execution Plan’ına bakalım.

SET SHOWPLAN_TEXT ON
SELECT MusteriId,AdSoyad FROM MUSTERI WHERE AdSoyad ='Ahmet Kaymaz'

|–Index Seek(OBJECT:([Deneme].[dbo].[MUSTERI].[IX_AdSoyad]), SEEK:([Deneme].[dbo].[MUSTERI].[AdSoyad]=[@1]) ORDERED FORWARD)

“SET SHOWPLAN_TEXT ON” komutu yürütme planını metinsel olarak görmemizi sağlar. Grafiksel olarak bu planı görmek için “Include Actual Execution Plan” düğmesini tıklamamıza yeterli olacaktır.

Yürütme planı bu sorgu için MUSTERI tablosu üzerinde IX_AdSoyad indeksinin kullanılarak index seek operasyonun yapıldığını anlatmaktadır. Şimdi bu indexi DISABLE edelim.

ALTER INDEX IX_AdSoyad ON MUSTERI DISABLE

Disable işlemi ALTER INDEX komutuyla yapılabildiği gibi aşağıdaki gibi Management Studio üzerinden de yapılabilir.

Bu işlemden sonra aynı sorguyu çalıştırdığımızda bu sefer Execution Plan olarak aşağıdaki gibi bir sonuç dönecektir.

|–Clustered Index Scan(OBJECT:([Deneme].[dbo].[MUSTERI].[IX_MusteriId]), WHERE:([Deneme].[dbo].[MUSTERI].[AdSoyad]=[@1]))

Görüldüğü gibi Optimize IX_AdSoyad indexini görmezden gelip doğrudan clustered index scan operasyonunu uyguladı.

Non-clustered index’in disable edilmesinden sonra bu index için oluşturulmuş olan index datalarının silindiğini yazmıştık. Bunu doğrulamak için sys.sysindexes view’i çalıştırılabilir. Index’i disable yapmadan önce aşağıdaki sorguyu çalıştıracak olursak sonuç olarak “3″ değeri dönecektir.

SELECT rowcnt FROM sys.sysindexes WHERE name = 'IX_AdSoyad'

Disable işleminden sonra rowcnt değeri “0″ olarak dönecektir. Çünkü index page’ler silinmiş oldu. Ayrıca indexin aktif/pasif bilgisi de aynı view’deki is_disabled kolonunda belirtilmektedir.

Clustered Index’e gelince durum biraz daha farklılık arzetmektedir. SQL Server sisteminde non-clustered indexler varsa clustered index üzerine kurulduğu için clustered index tarafındaki düzenleme non-clustered indexleri etkilemektedir. Dolayısıyla clustered index’in disable edilmesi tüm non-clustered indexlerin disable olmasına neden olur. Ve daha öncemli clustered index tablonun kendisini ifade ettiği için bu disable işleminden sonra sistem kataloğunda indexle ilgili bilgi tutulsa da kullanıcı ilgili tabloya erişemez.

ALTER INDEX IX_MusteriId ON MUSTERI DISABLE

Bu işlem sonrasında SQL Server aşağıdaki gibi uyarıyı verecektir.

Warning: Index ‘IX_AdSoyad’ on table ‘MUSTERI’ was disabled as a result of disabling the clustered index on the table.
Warning: Index ‘IX_KayitTarih’ on table ‘MUSTERI’ was disabled as a result of disabling the clustered index on the table.

Şimdi örnek sorgumuzu çalıştıracak olursak aşağıdaki hatayla karşılaşırız.
The query processor is unable to produce a plan because the index ‘IX_MusteriId’ on table or view ‘MUSTERI’ is disabled.

Herhangi bir indexi yeniden aktifleştirmek için ALTER INDEX REBUILD veya CREATE INDEX WITH DROP_EXISTING komutları kullanılır. Yani indexler yeniden oluşturulur. Tüm indexleri rebuild etmek için ALTER INDEX ALL komutu kullanılır. Ayrıca clustered index’in aktifleştirilmesi tablo üzerindeki non-clustered indexlerin de aktifleştirileceği anlamına gelmez. Bu yüzden hepsinin bağımsız olarak rebuild edilmesi gerekmektedir. Tüm indexleri yeniden aktifleştirelim.

ALTER INDEX ALL ON MUSTERI REBUILD

Index’lerin drop edilmeden doğrudan pasif yapılması bulk import/update işlemleri için kolaylık sağlamaktadır.

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.

SQL Server üzerinde replike edilen bir tabloya yeni bir kolon eklediğimizde veya tablodan kaldırdığımızda (ALTER TABLE ADD / ALTER TABLE DROP) SQL Server 2000 bunu doğrudan replikasyona dahil etmez SQL Server 2005 ise bunu default olarak replikasyona dahil eder. SQL Server 2000′de yeni kolonu replikasyona dahil etmek için ya sözkonusu tablo yeniden replikasyona dahil edilir veya sp_repladdcolumn ve sp_repldropcolumn prosedürleri kullanılır. Eğer tablodaki kayıtlar az ise aşağıdaki gibi tabloyu mevcut replikasyondan çıkarıp yeniden dahil etmek daha kolay bir çözüm olarak tercih edilebilir.

--W00 isimli abonenin Urun nesnesine olan aboneliğini kaldırıyoruz
exec sp_dropsubscription @publication = 'MerkezData'
, @article = 'Urun'
, @subscriber = 'W00'
, @destination_db = 'akaymaz' 

--Mevcut publication içerisinden Urun tablosunu çıkarıyoruz
exec sp_droparticle @publication = 'MerkezData'
, @article = 'Urun'

--Urun tablosuna Fiyat kolonu ekleyelim
ALTER TABLE Urun ADD Fiyat int null

--MerkezData isimli yayına Urun nesnesini ekliyoruz
exec sp_addarticle @publication = 'MerkezData'
, @article = 'Urun'
, @source_table = 'Urun'
, @ins_cmd = N'SQL', @del_cmd = N'SQL', @upd_cmd = N'SQL'

--W00 istemcisinin Urun nesnesine abone edelim
exec sp_addsubscription @publication = 'MerkezData'
, @article = 'Urun'
, @subscriber = 'W00'
, @destination_db = 'akaymaz'

Bu kodları çalıştırdıktan sonra Urun tablosunun yeniden abonelere aktarmak için bu tablo için snapshot oluşturmak gerekir.

Bunu oluşturmak için “Snapshot Agent” servisini başlatmak yeterli olacaktır. Snapshot Agent, eklenen tablo için bir snapshot oluşturacaktır. Bu snapshot içerisinde tablodaki tüm kayıtlar olacağı için bu yöntem yükse satırlı tablolarda sorun teşkil edebilir. Büyük tablolar veya snapshot oluşturulmasını istemediğimiz durumlar için ikinci yöntem alternatif olarak kullanılabilir. Bu yöntem sp_repladdcolumn ve sp_repldropcolumn prosedürlerinin kullanılmasıdır. Bu prosedürler publish edilmiş tabloya yeni kolon ekler veya tablodaki kolonu çıkarır. Örneğin Urun tablosunda bulunan Fiyat kolonunu replikasyona dahil edelim. Fakat bu tabloda daha önce bulunan kayıtları da karşı tarafa aktarmamız gerekiyor. snapshot işlemi olmayacağı için ara bir kolon oluşturmamız gerekecektir. Aşağıdaki gibi tmpFiyat isimli bir alan oluşturacağız Fiyat alanındaki değerleri tmpFiyat alanına taşıyacağız. Fiyat alanını silip ardından replikasyonda dahil edilecek şekilde yeniden oluşturacak ve tmpFiyat alanındaki verileri Fiyat alanına taşıyacağız.

exec sp_repladdcolumn @source_object = 'Urun'
, @column = 'tmpFiyat'
, @typetext = 'int NULL'
, @publication_to_add = 'MerkezData'

update Urun set tmpFiyat = Fiyat

exec sp_repldropcolumn @source_object = 'Urun'
, @column = 'Fiyat'

exec sp_repladdcolumn @source_object = 'Urun'
, @column = 'Fiyat'
, @typetext = 'int NULL'
, @publication_to_add = 'MerkezData' 

update Urun set Fiyat = tmpFiyat

exec sp_repldropcolumn @source_object = 'Urun'
, @column = 'tmpFiyat'

Bu yöntemlerden farklı olarak şu da yapılabilir; replikasyonu kurarken kullandığımız sp_articlecolumn isimli prosedür aracılığıyla mevcut replikasyona tablodaki kolon eklenir. Böylece bundaki sonraki işlemlerde bu kolon da dahil edilmiş olur. O arada o kolondaki eski kayıtları linked server veya Import/Export ile aboneye taşıyıp şube ile merkez senkronize edilebilir.

exec sp_articlecolumn @publication = N'MerkezData',
@article = N'Urun',
@column = N'Fiyat', @operation = N'add'

exec sp_articlecolumn @publication = N'MerkezData',
@article = N'Urun',
@column = N'Fiyat', @operation = N'drop'

SQL Server 2005′te 2000′den farklı olarak replike edilen bir tabloya yeni kolon eklediğimizde bu kolon default olarak replikasyona dahil edilir. Aşağıdaki gibi Cinsiyet alanını eklediğimizde otomatik olarak abonedeki Musteri tablosuna da Cinsiyet alanı eklenecektir.
ALTER TABLE Musteri ADD Cinsiyet int
Aynı şekilde alanı DROP ettiğimizde abonedeki Cinsiyet alanı da kaldırılmış olacaktır.
ALTER TABLE Musteri DROP COLUMN Cinsiyet

SQL Server 2005′te de mevcut bir kolonu replikasyona dahil etmek için sp_articlecolumn yordamı kullanılabilir.

Şimdi şema değişikliği konusuna değinelim. SQL Server 2000′de replikasyonda bulunan bir tablo üzerinde ortamında şema değişikliği yapmak istediğimizde aşağıdaki hata mesajıyla karşılaşırız.

ALTER TABLE Urun ALTER COLUMN Fiyat numeric(9,2)

“Cannot alter/drop the table ‘Urun’ because it is being published for replication”.

SQL Server 2005′te tahmin edileceği gibi kolon ekleme, çıkarma gibi şema değişikliği de default olarak aboneye yansır. Bu özellik sp_addpublication veya sp_changepublication yordamları için kullanılan @replicate_ddl parametresiyle belirlenmektedir.

sp_changepublication @publication='MerkezData',
	@property = N'replicate_ddl', @value = 0

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.