Bu yazımda Plan Cache’de bulunan Plan’ları ve Memory’de bulunan clean data page’leri hangi komutlar ile temizleyebileceğimize bakıyor olacağız.

More...

SQL Server’da bulunan Auto Growth (Otomatik Büyüme) özelliği sayesinde veritabanı dosyaları dolduğunda sistem tarafından otomatik olarak büyütülmektedir. Bu büyüme oransal ya da boyutsal olarak daha önceden belirlenebilir. Aynı zamanda dosyaların en fazla hangi boyuta kadar büyüyebileceği de ayarlanabilir.

Auto Growth işlemi diskte yeni bir alan allocate edilmesinden dolayı kaynak tüketimi fazla olan bir operasyondur. Büyümenin boyutlarına göre bazı durumlarda bu büyüme işlemi 1-5 saniye arasında sürebilir. Büyüme tamamlanana kadar da ilgili dosyaya gelen okuma ve yazma istekleri bekletilecek bu da performans sıkıntısı olarak dönecektir.

More...

Bugünkü makalemde, heap tablolarda karşımıza çıkan Forwarded Record konusu üzerine konuşuyor olacağız. Alt başlıklarımız şu şekilde;

• Forwarded Record Nedir?
• Forwarded Record Nasıl Oluşur?
• Forwarded Record Neden Oluşur? SQL Server’ın Bu Davranışının Nedeni Nedir?
  • NonClustered Index İçeren Heap Tablolarda Forwarded Record
  • NonClustered Index İçermeyen Heap Tablolarda Forwarded Record
• Forwarded Record’un Performansa Etkisi Nedir?
• Clustered Index İçeren Tablolarda Neden Forwarded Record Oluşmaz?
• Hangi Tablolarımda Forwarded Record Var?
• Tablolarımda Bulunan Forwarded Record’lardan Dolayı Performans Sıkıntısı Yaşıyor muyum?
• Forwarded Record Nasıl Düzeltilir?
• Sonuç

More...

SQL Server’da sistemin nasıl çalıştığını kontrol etmek için bakacağımız belkide ilk yer SQL Server Error Log’larıdır. SQL Server ve Agent Error Log’ları sayesinde sistemde herhangi bir ciddi problem olup olmadığını kontrol etmemiz mümkündür.

Bugünkü yazımda SQL Server Error Log’ların sayısının nasıl arttırılacağını, yeni bir error log dosyasının nasıl create edilebileceğini, kısacası SQL Server’da Error Log’lar ile çalışırken hangi best practice’leri uygulamamız gerektiğinden bahsedeceğim.

More...

Bu makale, Index kullanımının amacını ve faydalarını sorguladıktan sonra, Index tiplerinin arasındaki farkları derinlemesine inceleyip, bakım işlemlerinin nasıl yapılacağı üzerinde duracaktır.

More...

SQL Server execute edilen procedure, trigger ya da adhoc query’ler için oluşturduğu Query Plan’larını saklar ve daha sonraki kullanımlarda bu query plan’ları kullanarak işlemin daha hızlı sonuçlanmasını sağlar.

Bu Query Planlar Plan Cache’de saklanır. Troubleshoot ya da bazı gereksinimlerden dolayı bu cache’lenmiş planları silme ihtiyacı duyabiliriz. Bugünkü yazımda plan cache’i nasıl temizleyebileceğimize bakıyor olacağız.

More...

SQL Server da kullanılan Heap, Clustered ya da NonClustered Index’ler insert,update,delete yapıldıkça otomatik olarak güncellenirler ve yapılan bu işlemler sonucunda fragmante olurlar. Bu da Index’in performansını olumsuz etkiler. Belirli aralıklarla fragmante olan bu indexleri bulup drop-create, ReOrganize ya da Rebuild işlemleriyle fragmante oranlarının düşürülmesi gerekmektedir. Bugünkü makalemde bu defragmentation işlemlerini inceliyor olacağız.

More...

Data bütünlüğü açısından DBCC CheckDB’nin nasıl kullanılacağını şu yazımda görmüştük. Bugünkü yazımda DBCC CheckDB yapıldığında Error Log’a kayıt olarak düşen rolled back ve rolled forward mesajlarının neler olduklarına ve bu konuyla alakalı herhangi bir aksiyon alınmasının gerekip gerekmediğini tartışıyor olacağız.

More...

SQL Server 2008 R2 Best Practices Analyzer, instance inizi best practice değerlerine göre kontrol edip size önerilerde bulunan bir tooldur. Bugünkü makelemizde bu tool un kullanımını inceliyor olacağız.

Best practise kavramını biraz açalım. Best practise bahsi geçen teknolojik ürün üzerinde kabul görmüş genel konfigurasyonlardır. Örneğin SQL Server ı ele alacak olursak; Database Data ve Log dosyalarını performans amaçlı farklı fiziksel disklerde bulundurmak best practice dir. Ya da TempDB Data file larını core cpu sayısı kadar yapmak gene bir SQL Server Best Practice dir.

Microsoft SQL Server 2005 Best Practise tool unu release ettikten sonra 2008 Best Practice tool u için çok uzun süre bekledi ve ancak 18.06.2010 tarihinde release edebildi. Çok uzun bir süre 2008 ortamlarımızda hala 2005 best practice tool unu kullanmak zorunda kalırken artık şimdi elimizde 2008 best practice tool u var. Ve bu yazımızda bu tool un detaylarına iniyor olacağız.

More...

SQL Server da kullanılan Heap, Clustered yada NonClustered Index’ler kullanıldıkça fragmante olurlar. Bu da Index’in performansını olumsuz etkiler. Belirli aralıklarla fragmante olan bu indexleri bulup drop-create, ReOrganize yada Rebuild işlemleriyle fragmante oranlarının düşürülmesi gerekmektedir. Bugünkü yazımızda Index’lerin fragmante oranlarını nasıl sorgulayacağımızı işliyor olacağız.

More...

SQL Server TempDB veritabanı yanlış yapılan join sorgularının order by clause ile beraber kullanımı ile plan dışı büyüyebilir. Bu büyüme disk size ı dolduracak kadar olursa servis kullanılmaz duruma gelebilir. Bugünkü yazımda TempDB boyutunu küçültme amaçlı yapılabilecek shrink operasyonlarını inceliyor olacağız. Bu kapsamda 3 farklı shrink metodu anlatıyor olacağım.

More...

SQL Server DBA olarak ana görevlerimizden biride veritabanlarımızın periyodik olarak mantıksal ve fiziksel bütünlüklerini kontrol etmektir. Bugünkü yazımda CHECKDB, CHECKALLOC ve CHECKTABLE DBCC komutlarını kullanarak bu kontrollerin nasıl yapılacağını işliyor olacağız.

CHECKDB en kapsamlı check işlemidir ve CHECKALLOC,CHECKTABLE komutlarının yaptığı kontrolleri de içermektedir. Dolayısıyla sisteminizde CHECKDB çalıştırdıysanız ayriyeten CHECKALLOC ve CHECKTABLE çalıştırmanıza gerek yoktur.

More...

SQL Server üzerindeki database lerimize daha sağlıklı çalışabilmesi için periyoduk olarak bakım yapmamız gerekmektedir. Aynı zamanda disaster durumları için periyodik olarak yedekleme işlemleride yaparız. Genelde yapılan işlemleri şu şekilde sıralayabiliriz;

• Shrink (Boş Alanları Sıkıştırma) İşlemleri
• Index Bakım İşlemleri (reIndex ve ReBuild)
• BackUp Alma İşlemleri

Bu işlemleri manuel olarak yapmamız mümkün. Ama eğer birden fazla database varsa ve her gece belli bir saatte bu işlemleri yapmak istiyorsak bu durumda job ları devreye sokabiliriz.

SQL Server Maintenance Plan ise bize bu işlemleri belli bir plan içinde yapma şansı tanıyor. Aynı zamanda yapılan tanımlamayı tek bir yerden kontrol edebilme, aynı şekilde işlem sonucunuda tek bir yerden raporlama hakkı veriyor. Bu şekilde karmaşık yapılı veritabanı yönetiminde oldukça büyük rahatlık sağlamakta.

Şimdi isterseniz SQL Server 2008 de Maintenance Plan nasıl tanımlanır ve işletilir görelim.

Maintenance Plan menüsüne SQL Server Management Studio >> Management altından erişiyoruz.

Maintenance Plans a sağ tıklayıp yeni bir Maintenance Plan tanımlamak için “Maintenance Plan Wizard” a tıklıyoruz.

Gelen karşılama ekranında Next e basıp bir sonraki ekrana geçiyoruz.

Hazırladığımız maintenance plan a bir ad ve açıklama veriyoruz. Eğer birden fazla maintenance plan tasarlamayı düşünüyorsanız ad ve açıklama kısmına dikkat etmenizi tavsiye ederim.

Yapılan Maintenance ve BackUp işlemleri için schedule tanımlayabilir ve bu şekilde bu işlemleri periyodik olarak gerçekleşmesini sağlayabilirsiniz.

Bu işlemlerin her biri için ayrı ayrı schedule tanımlayabileceğiniz gibi hepsi için tek bir schedule da tanımlayabilirsiniz. Biz bu örneğimizde bütün işlemler için tek bir schedule tanımlayacağız. Ekrandaki radio butonu 2.seçenek olarak seçip schedule tanımlamak üzere Change butonuna basıyoruz.

Daha önceki yazılarımda SQL Server 2008 üzerinde Schedule (Job) tanımlamasını ayrıntılı anlattığım için burada tekrar anlatmıyorum. Schedule ile alakalı yazılarıma buradan erişebilirsiniz.

Biz bu ekranda işimizi 1 dakikada bir tekrarlatmak için 1 minute seçip OK e basıyoruz. Arka ekranda da Next e basıp bir sonraki ekrana geçiyoruz.

Bu ekranda Maintenance Plan dahilinde yapılması istenen işlemleri seçiyoruz. İşlemleri kendi bölümlerinde açıklayacağım. Ekranda ki bütün işlemleri seçip Next e basarak bir sonraki ekrana geçiyoruz.

Bir önceki ekranda seçtiğimiz işlemleri bu ekranda sıralayabiliriz. İşlemler yukarıdan aşağıya şekilde gerçekleştirilecektir. İstediğiniz sıralama değişikliklerini Move Up ve Move Down butonları vasıtasıyla yapabilirsiniz. Next e basıp bir sonraki ekrana geçiyoruz.

Bu aşamadan itibaren yapılacak işlemler için ayarlama tanımlamaları başlıyor.

Check Database Integrity : İstenilen database lerin bütünlüğünü ve sağlamlığını kontrol edip rapor verir. Database seçimi yapmak için Databases yazısının yanındaki combobox a tıklayıp database seçim ekranını açıyoruz.

Gelen ekranda istediğimiz databaseleri seçerek Ok e basıyoruz. Arka ekranda da Next e basıp bir sonraki ekrana geçiyoruz.

Shrink Database : Database lerdeki boş kullanılmayan alanları sıkıştırmaya yarar. Gerekli shrink ayarlarını yapıp database seçimini de yaptıktan sonra Next e basıyoruz. (Daha sonra bir yazımda Shrink i ayrıntılı ele almayı düşünüyorum. O yüzden burada çok detaylı bilgi vermeyeceğim.)

ReOrganize Index : Table ve view lerde kullanılan Index leri ReOrganize edip daha hızlı çalışmasını sağlayabiliriz. Database seçimini yapıp Index işleminin hangi Object lerde yapılmasını istediğimiz belirtip Next e basarak bir sonraki ekrana geçiyoruz.

ReBuild Index : Gene Index leri ReBuild ederek daha hızlı çalışmasını sağlayabiliriz. (Daha sonraki yazılarımda ReBuild ile ReOrganize arasındaki farklara değineceğim.) Database ve Object seçimini istediğimiz gibi yapıyoruz. Bu ekranda ayrıca “Keep Index online while reindexing” seçeneği bizim için çok önemli. Bu seçenek vasıtasıyla reindex işlemi yapılırken dahi index e erişimi kesmemiş oluyoruz. Next e basarak bir sonraki ekrana geçiyoruz.

Update Statistics : Veritabanı ile alakalı istatistik verilerinin update edilmesini yarayan bu ekranda table ve object seçimlerini yapıp Next e basıyoruz.

CleanUp History : Hazırlanan Maintenance Plan lar gerçekleştiğinde hdd de history dosyaları oluşturmaktadır. Bu ekranda bu oluşan history dosyalarının ne kadar süreyle hdd de saklanacağını seçebiliyorsunuz. İstenilen ayarlamaları yapıp Next e basıyoruz.

Execute SQL Server Agent Job : Daha önce başka işlemler için hazırladığınız SQL Server Job ları Maintenance Plan ın içine dahil edebilirsiniz. Bu ekranda eklemek istediğiniz Job ları seçip Next e basıyoruz.

BackUp Database (Full) : Bu ekranda FULL BackUp ının alınmasını istediğimiz Database leri belirliyoruz. Database seçimini yaptıktan sonra “Create a sub-directory for each database” yazısını işaretleyerek her database için bir klasör oluşmasını sağlıyoruz. Folder kısmına da BackUp ların alınacağı folder ı belirtiyoruz. Son olarak Compression Type ı seçerek Next e basıyoruz.

BackUp Database (Differential) : Differential BackUp alınmasını istediğimiz veritabanlarını bu ekranda belirliyoruz. Diğer ayarlamalar bir önceki ekrandaki gibidir. Next e basıp bir sonraki ekrana geçiyoruz.

BackUp Database (Transaction Log) : Transaction Log BackUp alınmasını istediğimiz veritabanlarını bu ekranda belirliyoruz. Diğer ayarlamalar bir önceki ekrandaki gibidir. Next e basıp bir sonraki ekrana geçiyoruz.

Maintenance CleanUp Task : Maintenance Plan gerçekleşmeleri sonucunda oluşan BackUp ve Maintenance Plan Report dosyalarının hdd de ne kadar süre ile saklanacağını bu ekran vasıtasıyla ayarlayabilirsiniz. Gerekli ayarlamaları yapıp Next e basıyoruz.

Son olarak Maintenance Plan gerçekleştiğinde report dosyasının nereye oluşturulacağını ve bu sonucun mail olarak kime gönderileceğini seçerek Next e basıyoruz. Eğer SQL Server için mail ayarlarının anlatıldığı şu yazımı okumadıysanız okumanızı tavsiye ederim.

Yaptığımız Maintenance Plan ın bir summary si olan bu ekranı kontrol ettikten sonra Next e basıyoruz.

Ve son olarak close a basıp Maintenance Plan ı tanımlama işlemimizi bitiriyoruz.

Artık Maintenance Plan ımız hazır. Bu işlemin tamamlanmasından sonra Maintenance Plans kısmında ve Jobs kısmında 1 er yeni item oluşmuş olması lazım.

Maintenance Plan a bir schedule atadığımız için burada atadığımız schedule Jobs kısmında görüntülenmekte.

Schedule 1 dakikada 1 olarak ayarlamıştık. Dolayısıyla her 1 dakikada 1 ayarladığımız bütün işlemler gerçekleşecektir. Biz genede bu işlemi elle çalıştırmak isteyebiliriz. Bunun için Maintenance Plans altından hazırladığımız Plan ı bulup sağ tıkla açılan ekranda Evecute e basabiliriz.

Bu işlem sonucunda Plan çalışmaya başlayacak ve aşağıdaki ekran açılacaktır.

Hata verirse bu ekranda message kısmında verdiği hatayı görebilirsiniz.

Son olarak oluşan backup dosyalarına HDD de bakalım ve yazımızı noktalayalım.

SQL Server 2008 de Maintenance Plan oluşturma ve yönetme işlemleri bu şekilde. Umarım açıklayıcı bir yazı olmuştur ve işinize yarar.

Kolay gelsin

Turgay Sahtiyan

Merhaba arkadaşlar

Bu yazımda SQL Server 2008 de ki Policy Management kavramından bahsedeceğim.

Policy Management Sql Server 2008 ile beraber gelen yeni bir özellik. Hazırlanan policy ler sayesinde örneğin bir veritabanı create edilirken auto shrink özelliğinin kontrol edilmesi ve bizim belirlediğimiz değilse hata verilmesi sağlanabilir. Yada table create edilirken girilen table adı policy e uygun mu, yada table create edilirken index e sahip olsun mu olmasın mı tarzında policy ler tanımlayabiliriz.

Policy Management Menüsüne SQL Server Management Studio (SSMS) da Management ın altından erişebiliriz.

İlk incelememiz gereken yer facets. Facets, sql server kurulumuyla beraber gelen yönetilebilen özelliklerdir. Mesela bu bölümdeki database facet ına çift tıklarsak açılan pencerede database için verebileceğimiz özellikleri görmekteyiz.

Şimdi sırasıyla bir policy oluşturmanın adımlarına bakalım.

• Condition oluştur
• Policy oluştur
• Policy i kontrol et.

Condition Oluşturmak

Örneğin table adı için bir policy yapalım. Bu policy table adı “tbl_” ile mi başlıyor diye kontrol etsin. İlk olarak bir condition oluşturmalıyız. Bunun için menüden condition a sağ tıklayıp new condition diyoruz.

Name kısmına condition için bir ad giriyoruz. Daha sonra facet kısmından table ı seçiyoruz. Çünkü table adını kontrol edeceğiz. Expression kısmında ki field kısmından @name seçeneğini seçip operator ü like yapıyoruz. Çünkü belirli bir ifade ile başlayıp başlamadığını kontrol edeceğiz. Son olarak ta value kısmına kontrolümüz olan ‘tbl_%’ yi yazıp ok e basıyoruz.

Policy Oluşturmak

Management Studio da policy e sağ tıklayıp new policy diyoruz. Açılan pencerede policy a bir isim veriyoruz.  Check condition kısmından az önce yaptığımız condition ı seçiyoruz. Şu an için bu condition bütün table lar ve bütün database için geçerli olacaktır. Eğer bunu değiştirmek istiyorsak every yazılarının yanındaki ok tuşlarına basarak onlar içinde condition lar tanımlayabiliriz.

Evaluation Mode kısmında 4 seçenek göreceksiniz. Bunlar;

• On Demand (Default Seçenek) = Bu seçimi yaparsanız eğer policy in kontrolünü management studio da policy e sağ tıklayıp evaluate seçeneğini seçtiğinizde gelen ekranda yapabilirsiniz.
• On Schedule : Policy için bir iş emri tanımlayabilirsiniz. Bunun için hazır tanımlanmış iş emri seçebileceğiniz gibi kendiniz istediğiniz bir süreyi de seçebilirsiniz.
• On Change – Log Only : Bu seçenek vasıtasıyla koşul sağlanmadığı anda otomatikman Windows Event Log a bununla alakalı bilgi düşmekte.
• On Change – Prevent : Bu seçenek vasıtasıyla örneğin daha table ı create ederken hata mesajı almanız mümkün. SQL ile table Create komutu uygulandığında sistem size bir uyarı mesajı verecektir.

On Demand seçeneğini seçip Ok e basarak policy e oluşturuyoruz. Bu arada on demand hariç diğer seçeneklerde enable yazısını tiklemeyi unutmayın yoksa policy çalışmaz.

Şimdi oluşturduğumuz bu policy i evaluate edip sistemimizdeki tableların bu policy i sağlayıp sağlamadığına bakalım.

Bunun için management studio da policy ı bulup sağ tıklayıp evaluate diyoruz. Şu tarz bir pencere açılacaktır.

Bu ekranda kırmızı ile belirtilen satırlar belirtilen policy i sağlamamakta, yeşil ile belirtilen satırlar ise sağlamaktadır.

Export Result özelliği ile de evaluate sonucunu xml formatında kaydetmemiz mümkün.

İyi çalışmalar

Turgay Sahtiyan

Merhaba arkadaşlar,

Sql Server 2008 ile gelen bir diğer özellik Change Data Capture. Bu özellik ile bir table üzerinde yapılan insert,update ve delete işlemlerinin logunu tutabilmekteyiz. Bu özelliği tablo bazında yada tablonun istediğimiz alanları bazında yapabilmekteyiz.

Şimdi bunu nasıl yapabildiğimize bakalım.

Örneğin aşağıdaki gibi bir table üzerinde çalıştığımızı düşünelim. Table ın oluşması için aşağıdaki sorguyu çalıştırabilirsiniz.

CREATE TABLE dbo.Employee(

EmpID int Primary Key NOT NULL,

EmpName nvarchar(100) NOT NULL,

EmpEmail nvarchar(100) NOT NULL)

GO

Daha sonra database in Change Data Capture özelliğini enable etmemiz gerekiyor. Bunun için uygulamamız gereken komut;

EXEC sp_cdc_enable_db

Şimdide bizim table ımızın Change Data Capture özelliğini enable etmemiz gerekiyor. Bunun içinde aşağıda ki sorguyu uygulamamız gerekiyor;

EXEC sp_cdc_enable_table

@source_schema = N'dbo',

@source_name = N'Employee',

@role_name = NULL,

@filegroup_name = N'',

@supports_net_changes = 1

Enable işlemlerimiz tamam. Şu anda employee table ında bir insert update yada delete işlemi yaparsak bu işlem loglanacak.

İlk işlemi yapalım;

INSERT INTO dbo.Employee

values (1, N'Ahmet Sahtiyan', N'turgay@turgaysahtiyan.com')

Daha sonra bu kayıdı update edelim.

UPDATE dbo.Employee SET EmpName = N'Turgay Sahtiyan' WHERE EmpID = 1;

Şimdi loglanan kayıtlara bir bakalım. Bu kayıtlar cdc.dbo_Employee_CT table ında tutulmaktadır. Change Data capture özelliği enable edilen her kayıt için log bilgileri <schema>_<table>_CT formatındaki table larda saklanmaktadır.

Employee table ı için loglanan kayıtları görebilmek için select * from cdc.dbo_Employee_CT sorgusunu çalıştırdığımızda 3 kayıt göreceğiz. Bunların ilki insert işlemi. 2. si update işlemi, son kayıt ise update işleminden sonraki kayıtın durumunu vermekte.

Yani operation kolonunda değer 1 ise delete, 2 ise insert,3 ise update ten önceki kayıt,4 ise update ten sonraki kayıtın durumunu vermekte.Select işlemi ise loglanmamaktadır.

Şimdi aşağıdaki sorguyu çalıştıralım.

DECLARE @from_lsn binary(10), @to_lsn binary(10);

SET @from_lsn = sys.fn_cdc_get_min_lsn('dbo_employee');

SET @to_lsn = sys.fn_cdc_get_max_lsn();

SELECT * FROM cdc.fn_cdc_get_all_changes_dbo_employee(@from_lsn, @to_lsn, 'all');

Bu sorgu ile 2 kayıt dönecektir. İlki insert işlemi, 2.si ise update işleminden sonraki kayıtın durumu. Filtre olarak kullanılan ‘all’ dikkatinizi çekmiştir. Bu özellik bütün değişiklikleri getirmekte.Fakat update işlemleri için sadece updateten sonraki kayıtı getirmekte. Eğer update işleminden önceki kayıtıda görmek istiyorsak ‘all’ yerine 'all update old’ filtresini kullanmamız gerekmekte.

fn_cdc_get_min_lsn sistem fonksiyonu belirtilen tablonun minimum lsn değerini almaya yarar. Aynı şekilde fn_cdc_get_max_lsn fonksiyonuda maksimum lsn değerini almaya yarar.

Şimdi aşağıdaki sorguyu çalıştıralım.

DECLARE @from_lsn binary(10), @to_lsn binary(10);

SET @from_lsn = sys.fn_cdc_get_min_lsn('dbo_employee');

SET @to_lsn = sys.fn_cdc_get_max_lsn();

SELECT * FROM cdc.fn_cdc_get_net_changes_dbo_employee(@from_lsn, @to_lsn, 'all');

Bu sorguda fn_cdc_get_all_changes_dbo_employee fonksiyonu yerine fn_cdc_get_net_changes_dbo_employee fonksiyonu kullanılmıştır. Bu fonksiyon vasıtası ilede kayıdın en güncel halini almaktayız.

Aşağıdaki sorgu ile log tableını temizleyebiliriz.

DECLARE @end_time datetime;

DECLARE @to_lsn binary(10);

SET @end_time = GETDATE();

SELECT @to_lsn = sys.fn_cdc_map_time_to_lsn('largest less than or equal', @end_time);

exec sys.sp_cdc_cleanup_change_table @capture_instance = 'dbo_employee', @low_water_mark=@to_lsn

sp_cdc_cleanup_change_table belirlenen tabloda ki kayıtları @low_water_mark değerine göre temizlemekte.

İstediğimiz anda Change Data Capture işlemini disable edip loglama işlemini sonlandırabiliriz. Bunun için uygulayabileceğimiz sorgu aşağıdaki gibidir.

EXECUTE sp_cdc_disable_table

@source_schema = N'dbo',

@source_name = N'Employee',

@capture_instance = N'dbo_Employee'

İyi çalışmalar,

Turgay Sahtiyan

Merhaba arkadaşlar,

Bazı tablolara select çektiğimizde input/output hatası alabilmekteyiz. Böyle bir durum indexlerde ki problemden kaynaklanmaktadır.

Bunu düzeltebilmek için aşağıda ki kodları uyguluyoruz.

Önce database in single user control özelliğini true yapıyoruz. DENEME diye yazdığımız yer düzeltmek istediğimiz database in adı.

exec sp_dboption 'DENEME','single user','true'

Daha sonra Data kaybını göze al seçeneği ile beraber CheckDB prosedure ünü uyguluyoruz.

DBCC CHECKDB ('DENEME', REPAIR_ALLOW_DATA_LOSS)

En son işlem olarak datayı tekrar single user false posizyonuna çekiyoruz.

exec sp_dboption 'DENEME','single user','False'

Bu işlemler sonucunda input/output hatası ortadan kalkacaktır.

Kolay gelsin

Turgay Sahtiyan