SQL Server Günlüğü

"Executed as user: DOMAIN\ServiceAccountName. Cannot open backup device 'X:\BACKUP\BackupFileName'. Operating system error 5(failed to retrieve text for this error. Reason: 15105). [SQLSTATE 42000] (Error 3201) BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed."

2012-01-16T10:09:00.001+02:00

HATA:"Executed as user: DOMAIN\ServiceAccountName. Cannot open backup device 'X:\BACKUP\BackupFileName'. Operating system error 5(failed to retrieve text for this error. Reason: 15105). [SQLSTATE 42000] (Error 3201) BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed."

AÇIKLAMA:SQL Server veritabanlarında yedek alırken, böyle hatalar alabilirsiniz. Bu hata mesajında öncelikle benim dikkatimi çeken "Operating system error 5" mesajıydı. Bu mesajı gördüğünüzde, "Access is denied" cümleciği gelmeli aklınıza. Normalde hemen bu mesajın yanındaki parantez içerisinde yazmalıydı "Access is denied", fakat benim de bilmediğim bir nedenden dolayı hata mesajının alınamadığına dair bir mesaj var parantez içerisinde. Bu sonuca göre belli ki ilgili yola erişilemiyor. Bu da akla (en azından benimkine) iki şey getirir hemen

1- SQL Server servis hesabının ilgili yola erişim yetkisi yok,
2- Belirtilen yol yok, bir şekilde disk veya klasör uçmuş.

Normalde, hata mesajındaki parantez içerisinde

ÇÖZÜM:Yukarıda da belirttiğim aklıma gelen şeyleri kontrol ederken, diskin ve klasörün yerinde olduğundan emin olduktan sonra, SQL Server servis hesabının ilgili klasöre yetkisinin olup olmadığını kontrol ettim ve ilgili yetkinin olmadığını gördüm. SQL Server servis hesabı için o klasöre okuma\yazma yetkisi verdikten sonra yedek alma işlemi başarıyla tamamlandı ve sorun çözümlenmiş oldu.

Uzun süren maliyetli işlerin takibi

2012-01-10T11:37:00.002+02:00

SQL Server Kurulumlarında Gözden Kaçanlar - 8 başlıklı yazımda bir DBA'in veritabanı sunucusunda takip etmek isteyeceği şeylerden bahsetmiştim, bunlardan bir diğeri de uzun süren maliyetli işlerin takibiydi. Bu yazımda da bu konuya değineceğim.

Uzun süren maliyetli işler, genelde:
- Eksik veya yanlış Index'lerden,
- Zamanla ilgili tablolara yeni sorguların gelmesinden,
- Gelen sorgularda değişiklik yapılıp Index'lerde değişiklik yapılmasının unutulmasından,
- Implicit Conversion'lar...

gibi nedenlerden dolayı kaynaklanır.

Geçmişe dönük olarak bu maliyetli işleri sorgulamayı ise, Server Side Trace kullanımıyla görebilirsiniz. Tabii ki kullanacağınız süzgeç değerlerinin kendi ortamınıza göre değişiklik gösterebileceği unutulmamalıdır. Örneğin biz genel olarak kendi ortamlarımızda Batch işlemlerin tamamlanma sürelerini yarım saniyeyi aştığı durumları yakalamayı uygun görüyoruz.

Uzun süren maliyetli işlerin geçmişe dönük takibi için aşağıdaki ekran görüntüsünde de görüleceği gibi bir Server Side Trace ayarlamanız çoğu durum için uygun olacaktır:

Çok temel olarak, gelen sorguların şayet Duration değerleri yüksekse, sorguda kullanılan Function'lara, Implicit Conversion'lara dikkat edin; şayet Reads fazlaysa, o zaman da eksik veya yanlış Index kullanımına odaklanabilirsiniz.

Konuyla ilgili yazılar:
Server Side Trace hazırlamak

Server Side Trace hazırlamak

2012-01-09T11:29:00.000+02:00

Deadlock takibi ve Blocking takibi yazılarımda bahsettiğim ve önerdiğim Server Side Trace kullanımı hakkında bilgi vermek için de bir yazı yazacağımı söylemiştim, bu işte o.

Bir Server Side Trace hazırlamanın en pratik yolu, SQL Server Profiler aracını kullanmaktır. Öncelikle Profiler'ı açar, istediğiniz Event'leri ve alanları seçer, istediğiniz süzgeci koyarsınız.

Ardından "Trace Properties" penceresindeki "Run" düğmesine tıklayıp Trace'i başlatır ve anında durdurursunuz. Trace'in Script'ini almak için "File->Export->Script Trace Definition->(kullanacağınız versiyona göre...)For SQL Server 2005 - 2008 R2..." komutunu seçebilirsiniz. Oluşturulan Script'i, Script içerisindeki "InsertFileNameHere" değerini değiştirdikten sonra (Script içerisindeki açıklamaları okuyun lütfen) doğrudan Query Editor'de çalıştırabilirsiniz ve Server Side Trace'iniz çalışmaya başlayacaktır.

Bu Trace'leri ağınızdaki başka bir sunucuda barındırmak mantıklı olacaktır. Hem üretim sunucunuzun disklerini meşgul etmezsiniz, hem eğer birden fazla SQL Server sunucunuz varsa tüm dosyaları merkezi bir yerde tutabilir ve üretim sunucunuzu etkilemeden tetkiklerde bulunabilirsiniz.

Ben ayrıca kritik sunucularım için bu Server Side Trace'lerinin çalışıp çalışmadığını kontrol ettirmeyi de yeğliyorum. "sys.traces" Catalog View'ünü kullanarak çalışan Trace'leri zaman zaman sorgulattırıp, çalışmayan Trace'ler için haberdar olmanızı sağlayabilirsiniz. Böylece Blocking, Deadlock, uzun süren sorguların kaydedilmesi gibi bir DBA için çok elzem olan bilgileri toparlama işini de garantiye almış olursunuz.

Deadlock takibi

2012-01-06T11:03:00.001+02:00

SQL Server Kurulumlarında Gözden Kaçanlar - 8 yazısında izlenmezse olmaz diye bahsettiğim şeylerden bir diğeri de Deadlock takibi.

Bir kullanıcı size aşağıdaki gibi bir hata mesajı gösterip, sorun yaşadığını söyleyebilir:

Transaction (Process ID 845) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Şayet Deadlock takibi için bir Trace Flag veya bir Profiler\Server Side Trace kullanmıyorsanız, bu sorunun nedenini anlamanız pek mümkün değildir. Bu nedenle SQL Server'da Deadlock takibi için Trace Flag veya tercihen bir Server Side Trace kullanmak çok yerinde olacaktır. Çünkü bu sayede Deadlock sorunlarıyla ilgili tüm veriler tek bir yerde tutulmuş olur ve yönetimi ve ulaşılabilirliği kolay olur. Trace Flag kullandığınız zaman ise veriler SQL Server Error Log'a yazılacaktır ve diğer tüm verilerle karışacak ve Error Log'u da şişirmiş olacaktır.

Aşağıdaki kod ile, hiç SQL Server servisini kapatıp açmaya gerek kalmadan anlık Deadlock takibi yapabilirsiniz. Anlık diyorum, çünkü bunu bir Oturum (Session) açarak takip etmiş olacaksınız. Oturum kapanabilir, ama Server Side Trace daha sağlamdır.

dbcc traceon (1204, 3605, -1)
go
dbcc tracestatus(-1)
go

Bu takibi Profiler ile yapmak için, "Locks" Event'i altındaki "Deadlock graph" Event'ini kullanabilirsiniz.

Bu takipleri yaptığınız takdirde, geçmişe dönük Deadlock verilerine de ulaşabilir durumda olursunuz ve bu sayede Deadlock sorunlarını çözecek veriye sahip olursunuz.

Konuyla ilgili yazılar:
Server Side Trace hazırlamak

Blocking takibi

2012-01-05T11:19:00.000+02:00

Yine SQL Server Kurulumlarında Gözden Kaçanlar - 8 yazısına istinaden, bu yazıda Blocking takibini nasıl yapabileceğinizden bahsedeceğim.

Blocking takibinin geçmişe dönük olsun, anlık olsun yapılmasında büyük fayda vardır. Örneğin kullanıcılar veya sistemciler size gelip "bugün şu saatte zaman aşımı sorunu yaşadık (time-out), acaba veritabanı tarafında bir sorun olabilir mi?" diye sorduklarında, şayet elinizde geçmişe dönük veri yoksa cevap veremezsiniz. Bu da pek hoş bir durum değil. Özellikle bu gibi durumlarda Deadlock, Blocking, uzun çalışan işlemler gibi bilgilere geçmişe dönük şekilde sahip olmak istersiniz. İşte bu yazıda bu 3 temel gereksinimden birisi olan Blocking takibinden bahsedeceğim.

Anlık Blocking takibini iki pratik araçla yapabilirsiniz. Bunlardan biri, Microsoft'un aracı olan "sp_blocker_pss08" isimli SP. Bu SP'ye aşağıdaki adresten ulaşabilirsiniz:

http://support.microsoft.com/kb/271509/tr

Diğer araç ise, SQL Server konusunda dünya çapındaki duayenlerden Adam Machanic'in yazdığı "sp_WhoIsActive" isimli araç. Bu aracı da aşağıdaki adresten edinebilirsiniz.

http://sqlblog.com/tags/Who+is+Active/default.aspx

sp_WhoIsActive isimli Stored Procedure (SP)'ün birçok parametresi bulunmaktadır ve temel maksadı o anda çalışan tüm işlemleri ayrıntılı şekilde göstermektir. Bu SP ile Blocking takibi yapabilmek için "@find_block_leaders" ve "@sort_order" parametrelerini kullanmalısınız, örnek:

EXEC sp_WhoIsActive @find_block_leaders = 1, @sort_order = '[blocked_session_count] DESC'

Geçmişe dönük Blocking takibi ihtiyacınızı karşılamak için ise bir Server Side Trace* kullanabilirsiniz. Bu Trace'te "Errors and Warnings" Event grubunun içindeki "Blocked process report" Event'ini kullanabilirsiniz.

Fakat bu Event'i kullanabilmek için öncelikle SQL Server Kurulumlarında Gözden Kaçanlar - 2 yazımda bahsettiğim "blocked process threshold (s)" ayarını yapmalısınız.

Sonuç olarak, eğer Microsoft'un aracı olan "sp_blocker_pss08" veya Adam Machanic'in çok amaçlı aracı olan (ki favorim) "sp_WhoIsActive" araçlarından birini veya hepsini kullanarak anlık Blocking takibi yapabilir ve "Blocked process report" Event'ini kullanarak oluşturacağınız bir Server Side Trace'i de geçmişe dönük verileri tutmak için kullanabilirsiniz.

*Bir Server Side Trace oluşturma ve yönetme konusunda da başka bir gün (belki yarın?) bir yazı yazacağım. Bu konuda deneyimi olmayan arkadaşlarım o yazıdan da yararlanabilir.

Konuyla ilgili yazılar:
Server Side Trace hazırlamak

Transaction Log doluluk oranını tespit etmek

2012-01-04T14:31:00.000+02:00

"SQL Server Kurulumlarında Gözden Kaçanlar - 8" başlıklı yazımda belirttiğim maddelerden biri olan Transaction Log dosyasının doluluk oranını takip etmek için örneğin 3. parti bir yazılım olan Quest'in Stoplight ürününü de kullanabilirsiniz, aşağıda anlattığım yöntemi de. 3. ürün paralı, anlatacağım yöntem beleş ;)

Normal şartlar altında Transaction Log dosyalarının boyutları ve içlerinin doluluk oranları gibi bilgileri DBCC SQLPERF(LOGSPACE) komutuyla alabilirsiniz. Zaten yazdığım Script'te de bunu kullandım. Ayrıca bu işlemi parametrik bir hale getirdim. Parametreler için bir tablo ve sonuçları almak için de bir SP iş görüyor. Eğer her SQL Server Instance'ınızda DBA araçları için oluşturduğunuz bir DBA veritabanınız varsa bu iki nesneyi de o veritabanında tutabilirsiniz.

Ben DBA isimli bir SCHEMA kullanıyorum DBA araçları için, siz de isterseniz böyle yapabilirsiniz veya kendi standardınız varsa onu kullanabilirsiniz.

Tüm bu işlemlere başlamadan önce, komutları nesneleri yaratmak istediğiniz veritabanında çalıştıracağınızdan emin olun. Yeni bir SCHEMA yaratmak için (örneğin DBA):

CREATE SCHEMA [DBA]

Tablonun Script'i şöyle:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ONGO
CREATE TABLE [DBA].[GET_USED_LOG_PERCENTAGE_PARAMS](
[dbname] [nvarchar](250) NOT NULL,
[major] [tinyint] NOT NULL,
[critical] [tinyint] NOT NULL
) ON [PRIMARY]
GO

dbname: Bu alana, hangi veritabanının Transaction Log doluluk oranını izlemek istiyorsak, o veritabanının adını yazıyoruz.
major: Bu alana, kritik hatadan önce gelmesini istediğimiz uyarı değerini giriyoruz. Yani örneğin dosyanın boyutu 10GB ve dosyanın %60'ı doldu ve eğer major değer olarak "60" girdiyseniz, kendinize bu eşik değere ulaşıldığında (örneğin Database Mail ile) e-posta göndertebilirsiniz.
critical: Bu alana da kritik eşik değerini giriyoruz. Bu değere ulaşıldığında artık kesinkes haberdar edilmek istersiniz, bu değeri buna göre ayarlamalısınız. Örneğin "85" gibi.

Tabloyu oluşturduktan sonra, Transaction Log'ların doluluk oranını denetleyecek Stored Procedure (SP)'u da oluşturabilirsiniz:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [DBA].[GET_USED_LOG_PERCENTAGE]
AS
IF EXISTS(SELECT * from tempdb..sysobjects where name like '#LogSpaceUsed%')
DROP TABLE #LogSpaceUsed
CREATE TABLE #LogSpaceUsed (dbname nvarchar(200) not null, logsize dec not null, spaceused dec not null, [status] tinyint, )
INSERT INTO #LogSpaceUsed exec sp_executesql N'dbcc sqlperf(logspace)'
SELECT PRM.dbname [Database], spaceused [Percentage Used], PRM.[major], PRM.[critical], 'CRITICAL' AS [Severity] FROM #LogSpaceUsed AS LSU
INNER JOIN DBA.GET_USED_LOG_PERCENTAGE_PARAMS AS PRM ON PRM.dbname = LSU.dbname
WHERE PRM.dbname NOT IN ('model') AND LSU.[spaceused] >= PRM.[critical]
Union all
SELECT PRM.dbname [Database], spaceused [Percentage Used], PRM.[major], PRM.[critical], 'MAJOR' AS [Severity] FROM #LogSpaceUsed AS LSU
INNER JOIN DBA.GET_USED_LOG_PERCENTAGE_PARAMS AS PRM ON PRM.dbname = LSU.dbname
WHERE PRM.dbname NOT IN ('model') AND (LSU.[spaceused] >= PRM.[major] AND LSU.[spaceused] < PRM.[critical])

Bu SP ile, önceden oluşturduğumuz [DBA].[GET_USED_LOG_PERCENTAGE_PARAMS] isimli tablodaki parametreler kullanılarak takip edilmesi istenen veritabanlarının Transaction Log'larını her bir veritabanı için ayrı ayrı belirlediğiniz Major ve Critical değerlere göre sorgulayabilirsiniz. Çıkan sonucu ister HP Openview gibi bir izleme uygulaması ile alırsınız, isterseniz Database Mail ile kendinize e-posta göndertebilirsiniz veya RAISERROR ile Log'lara da kaydettirebilirsiniz ihtiyacınıza göre.

İlgili bağlantılar:
SQL Server Kurulumlarında Gözden Kaçanlar - 8

Tüm "sysadmin"ler silinirse ne yapmak gerek?

2012-01-02T19:05:00.002+02:00

Aşağıdaki gibi bazı durumlarda bir SQL Server Instance'ınız için tüm sistem yöneticiliği yetkilerini kaybedebilirsiniz:

- "sysadmin" rolüne sahip tüm kullanıcılar yanlışlıkla silinebilir,

- "sysadmin" rolüne sahip kullanıcılar şirketten ayrılır veya şirkete bağlanamıyor durumda olabilirler,

- "sa" hesabı pasiftir (disabled) ve kimse de şifresini bilmiyordur.

Böyle bir durumda kurulu olan SQL Server Instance'ını kaldırıp tekrar kurabilir ve kullanıcı veritabanlarını tekrar Attach edebilirsiniz. Fakat bu seçenek oldukça zaman kaybına neden olacaktır. Ayrıca sistem veritabanlarını kullanmazsanız tüm sunucu düzeyindeki ayarları ve nesneleri kaybedebilirsiniz.

Daha iyi bir çözüm ise, SQL Server Instance'ını "Single-user Mode"da çalıştırıp (-f veya -m parametresiyle), Local Administrators grubunun üyesi olan bir kullanıcıyı kullanarak bu Instance'a bağlanmaktır. Bu sayede yetkisi olsun olmasın, bu kullanıcı SQL Server Instance'ına "sysadmin" olarak bağlanacaktır. Bu noktadan sonra istediğiniz işlemi yapabilir, "sa" hesabını etkinleştirebilir ve şifresini değiştirebilir veya yeni kullanıcılar yaratıp veya varolan kullanıcılara "sysadmin" rolüne üyelik verebilirsiniz. Ayrıca bu parametre değişikliğini yaptıktan sonra, SQL Server servisini durdurup tekrar başlatmanız gerektiğini unutmamalısınız.

Bu işlemi yaparken (SQL Server'ı başlattığınızda) SQL Server Agent servisinin veya başka bir servisin çalışmadığından emin olmalısınız. Çünkü SQL Server'ı tek kullanıcı durumunda açmış oluyorsunuz ve eğer sizden önce başka bir servis veya kişi bağlanırsa o zaman sunucuya bağlanamaz durumda olursunuz. Bu nedenle sunucuya sizden başka kimsenin bağlanamadığından emin olmalısınız.

Bir SQL Server Instance'ını nasıl Single-user mode'a alabileceğinizi gösteren ekran görüntüsü aşağıdadır:

SQL Server Kurulumlarında Gözden Kaçanlar - 8

2011-12-30T09:42:00.003+02:00

Kurulum yapıldıktan sonra, özellikle de kritik veritabanı uygulamalarını barındıran SQL Server sunucularında, SQL Server açısından takibini yapmanız gereken olmazsa olmaz şeyler var. Bunlardan temel olarak bazıları:

- CPU kullanımı (Ortalama İşlemci Kullanımı)
- RAM kullanımı (Plan Cache ve Data Buffer Cache Hit Ratio, Available Memory, Page Life Expectancy gibi)
- Disk performansı (Ortalama Disk Queue Length, Disk Idle, Disk Response Time gibi)
- Disk kullanımı (doluluk oranları)
- Veritabanı veri ve Transaction Log dosyaları için doluluk oranları
- SQL Error Log dosyasının içindeki hatalar
- Deadlock takibi
- Blocking takibi
- Uzun süren, maliyetli işlemlerin takibi
- (Varsa) Log Shipping, Database Mirroring, Replication gibi sistemlerin çalışırlığı, senkronizasyon sürelerindeki gecikmeler gibi (meselâ Heartbeat yöntemleri kullanarak)
- (Varsa) SQL Server Failover Clustering'teki pasif düğümlerinizin durumu (meselâ Ping'leyerek)

Bu takipler çoğu zaman 3. parti uygulamalarla gerçekleştiriliyor. Fakat bütçesi müsait olmayan firmalarda bu takiplerin birçoğu, ücretli uygulamalar olmadan da gerçekleştirilebilir. Bazılarının takibi için bazı icatlar yapmıştım, bazılarını ise şirkette kullandığımız 3. parti uygulamalarla yapıyoruz. Yavaş yavaş, bu takipleri olabildiğince 3. parti ücretli uygulamalara para ödemeden nasıl yapabileceğiniz hakkında yazılar yazmaya çalışacağım; tabii ki her şeyi 3. parti uygulama olmadan çözmek mümkün veya pratik olmayabilir, bunları da ayrıca anlatmaya çalışacağım.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7

SQL Server Kurulumlarında Gözden Kaçanlar - 7

2011-12-29T14:58:00.003+02:00

SQL Server kurulumlarından sonra yapılması gereken şeylerden biri de TEMPDB veritabanının DATA dosyalarının sayısının CPU (CORE) sayısına göre çoğaltılmasıdır.

Örneğin 8 çekirdekli bir işlemciye sahip olan bir sunucunuz var, o zaman TEMPDB için toplam 8 tane DATA dosyası oluşturmanız uygun olacaktır. Transaction Log dosyasının sayısını ise seri şekilde işlendiğinden dolayı istisnai durumlar haricinde gerekmediği zaman çoğaltmaya gerek yoktur.

Ayrıca yapılan testlere göre işlemci sayısı 16'yı geçse bile, 16'dan fazla TEMPDB dosyası oluşturmamak gerekiyor. Yani üst sınırınız şimdilik 16.

DATA dosyalarını oluştururken tüm dosyaların boyutlarının aynı olduğundan emin olun. Örneğin sistem veritabanları için 50GB'lık bir disk ayırdıysanız ve sunucunuzda 16 CPU varsa, o zaman 16 tane dosya oluşturun ve hepsinin boyutunu da 512MB veya 1GB olarak ayarlayın. Bunu ihtiyacınıza göre değiştirebilirsiniz, fakat bir dosyanın boyutu ne olacaksa, diğerleri de aynı olmalıdır. Transaction Log dosyasının boyutu ise farklı olabilir, bunu da yine ihtiyacınıza göre ayarlarsınız. Maksat, işlemlerin dosyalara eşit şekilde yayılmasını sağlamak ve paralellikten faydalanmak ve dosyaların sürekli bir şekilde büyümesini engelleyip performans kaybının oluşmasını önlemek.

Dosyaları oluştururken dikkate almanız gereken şey ise büyüklükleri ve artış oranları. Dosyaları oluştururken varsayılan olarak 3MB değil büyüyecek şekilde bırakmayın. Bu ayarı makul bir şekilde ayarlamanız gerekiyor. Çünkü dosya büyürken yaşanan performans sıkıntılarını yaşamak istemezsiniz. Büyüme değerlerini de kontrollü bir büyüme için MB cinsinden, makul değerlerle belirlemek gerekir. Örneğin bazı durumlarda büyüme değerinin %25 olarak yapıldığını görüyoruz. Bunu şöyle düşünün, 100MB'ın %25'i 25MB; fakat 1GB'ın %25 256MB. Kestiremeyeceğiniz şekilde yaşanan büyümeler veritabanının Suspect duruma düşmesine yol açabilecek sonuçlara kadar gidebilir. Başka örneklerde de bu büyümenin 1MB gibi çok düşük bir miktarda olduğunu görebiliyoruz. Bu gibi durumlarda ise SQL Error Log'da sürekli IO ile ilgili uyarılara rastlanabilir. Ayrıca Transaction Log dosyasının büyümesi sırasında donmalar yaşanabilir, çünkü veritabanı yeni kayıtları kabul edemeyebilir.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Performance Counter'larının tekrar oluşturulması

2011-12-28T09:35:00.004+02:00

Tam olarak ne gibi durumlarda gerçekleşiyor bilemiyorum, fakat bazı SQL Server kurulumlarından sonra sunucuda SQL Server Performance Counter'ları belki kurulumda hiç oluşturulmamış oluyor ve biz olmadıklarını sonradan fark ediyoruz, belki de herhangi bazı işlemler yüzünden bu Performance Counter'ları bir şekilde silinebiliyor.

Daha geçen gün, yine bir müşterimizde böyle bir sorun ile karşılaştım. SQL Server 2008 Failover Cluster'ın kurulu olduğu 2 düğümlü bir sistemde, makinelerden birinde SQL Server Performance Counter'ları vardı; fakat diğerinde sadece SQL Server Agent ve SQL Server Integration Services'a ait 4-5 tane Performance Counter vardı.

Bu durumda SQL Server (2005 veya 2008) Performance Counter'larını tekrar oluşturmak gerekiyor. SQL Server Performance Counter'ları ilgili SQL Server Instance'ının "BINN" klasöründeki "sqlctr.ini" isimli dosyada bulunur. Counter'ları tekrar oluşturmak için aşağıdaki yolu izleyebilirsiniz.

- Bir Command Prompt penceresi açarak Performance Counter'ları olmayan SQL Server Instance'ının "BINN" klasörüne ulaşmanız gerekiyor, örneğin: "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn".
- Halihazırda var olan (eğer varsa) sayaçlar kaldırılır. Bunun için varsayılan bir SQL Server Instance'ı (Default Instance) için aşağıdaki kod:

unlodctr MSSQLSERVER

Bir Named Instance için de aşağıdaki kod çalıştırılmalı:

unlodctr MSSQL$namedInstance

- Sonrasında ise yine ilgili SQL Server Instance'ının "BINN" klasöründe aşağıdaki kod çalıştırılmalı:

lodctr sqlctr.ini

Eğer bu komutu çalıştırdıktan sonra herhangi bir sonuç dönmüyorsa, bu komutun başarılı olarak çalıştırıldığı anlamına gelir. Ayarların etkinleştirilebilmesi için ise ilgili SQL Server servisinin yeniden başlatılması gerekir. Bu işlemden sonra SQL Server Performance Counter'larının görünmesi gerekir.

Bazı durumlarda ise "sqlctr.ini" dosyası bir şekilde bozulmuş olabiliyor. Böyle bir durumda ise, bu dosyanın sağlam bir halini, aynı versiyondaki başka bir SQL Server Instance'ının "BINN" klasöründen alıp kopyalayabilirsiniz. Böyle bir durumda ise "sqlctr.ini" dosyasındaki aşağıdaki parametreyi SQL Server Instance'ınızın adına göre düzenlemelisiniz. Aşağıdaki örnekte SQL Server Instance'ı Default Instance'tır.

[info]drivername=MSSQLServer
trusted=
symbolfile=sqlctr.h

SQL Server Kurulumlarında Gözden Kaçanlar - 6

2011-12-27T11:45:00.002+02:00

Bazı SQL Server sunucuları veya servisleri çok uzun süre kapatıl(a)mayabiliyor. Bu durumda ise, SQL Server Error Log çok şişebiliyor ve bu da bazı sıkıntılara neden olabiliyor. Örneğin dosyanın açılması, okunması zor oluyor, pratik olmuyor. Bu nedenle ben, yeni kurulan sunucularda SQL Error Log'larının haftada bir yenilenmesi (Cycle) için bir Job oluştururum ve bu Job, aşağıdaki kodu çalıştırarak SQL Error Log'unu haftada bir kere yeniler.

EXEC sp_cycle_errorlog

Bu sayede SQL Server Error Log dosyaların boyutları hafifler ve açması, içinde bir şeyler araması ve bulması ve yönetimi kolay olur.

Ayrıca, varsayılan olarak SQL Server sadece 6 tane SQL Server Error Log tutar. 6 tanesinden sonra yeni SQL Server Error Log'lar ise, eskilerinin üzerine yazılmaya başlar.

Bu sayıyı arttırmak için SQL Server Management Studio'da aşağıdaki yolu izleyebilirsiniz:
- Object Explorer'dan ilgili SQL Server Instance'ının altından "Management"ı genişletin.
- "SQL Server Logs" öğesinin üzerinde farenin sağ tuşuna tıklayın ve "Configure" öğesine tıklayarak "Configure SQL Server Error Logs" penceresine ulaşın.
- "Maximum number of error log files:" parametresinin değerini ihtiyacınıza göre ayarlayın.

Not:Log sayısını belirlerken, diskteki boş yerinizi de göz önüne almanız önemlidir.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 5

2011-12-26T09:38:00.000+02:00

Bir SQL Server kurulumu yaptıktan sonra, özellikle de Log Shipping kullanılacaksa veya sık yedek alınabilecek bir sunucuysa (Transaction Log yedekleri gibi) o zaman muhakkak "msdb" sistem veritabanındaki yedeklemeyle ilgili kayıtları tutan tabloların düzenli bir şekilde silinmesinde fayda vardır. Aksi takdirde "msdb" veritabanı zamanla büyüyecektir, çünkü "msdb" veritabanında en çok büyüyen tablolar yedekleme ile ilgili tablolardır.

Bu amaçla, kurulum yaptığınız ve/veya yapacağınız sunucularda çalıştırılmak üzere standart bir Script oluşturup, bu Script'i de bir Job ile, SQL Server Agent* vasıtasıyla çalıştırabilirsiniz.

Bu Script'i hazırlarken temel olarak kullanabileceğiniz bir sistem Stored Procedure (SP)'ü bulunmaktadır. Bu SP "sp_delete_backuphistory" isimli SP'dir. Bu SP hakkında daha fazla bilgi almak için Books Online'dan şu adrese bakabilirsiniz: http://msdn.microsoft.com/en-us/library/ms188328.aspx

Örnek: Aşağıdaki kod ile, 1 aydan daha eski yedekleme kayıtlarının tarihçesini "msdb" veritabanındaki ilgili tablolardan temizlemiş olursunuz.
DECLARE @tarih datetimeSET @tarih = DATEADD(month, -1, getdate())EXEC sp_delete_backuphistory @tarih

* SQL Server Express Edition'larda SQL Server Agent bulunmamaktadır. Bu durumda, oluşturacağınız Script'i bir dosyaya kaydedebilir, bu dosyayı SQLCMD ile (SQL Server'ın Command Prompt aracı), Windows Scheduler ile de zamanlayarak çalıştırabilirsiniz.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 4

2011-12-23T10:11:00.001+02:00

Varsayılan SQL Server kurulumundan sonra yapılmasında fayda olabilecek diğer SQL Server Server ayarlarından başka diğer bazıları:

- optimize for ad hoc workloads: Bu ayar, Plan Cache'in daha verimli kullanılmasını sağlar. Sunucuya birçok Ad Hoc sorgular geliyor olabilir, fakat bunlar sadece bir kere kullanılıyor ve daha da kullanılmıyor olabilir. Bu nedenle Plan Cache verimli kullanılmıyor olabilir. Eğer "optimize for ad hoc workloads" parametresini etkinleştirirseniz, o zaman ilk defa çalıştırılan bir Batch için geçici, özet bir plan oluşturulur Plan Cache'te ve eğer aynı Batch ikinci kere gelirse, bu sefer planın tamamı Plan Cache'te tutulur ve bu sayede hafıza yönetimi daha verimli bir şekilde yapılmış olur.

Örnek:
EXEC sp_configure "optimize for ad hoc workloads", 1
RECONFIGURE

- remote admin connections: Yine SQL Server 2005 ile birlikte gelen yeni bir özellik vardır, Dedicated Administrator Connection (DAC). DAC sayesinde, bir SQL Server Instance'ında donma, yetersiz hafıza veya CPU işlem yoğunluğu gibi sorunlar olduğunda ilgili Instance'a bağlanmamız mümkündür. Bu sayede kısıtlı da olsa sorunu çözebilecek belli müdahalelerde bulunabiliriz. Fakat DAC özelliği varsayılan olarak sadece SQL Server Instance'ının kurulu olduğu makine üstünden kullanılabilir. Yani DAC'ye uzaktaki bir makineden varsayılan olarak bağlanılamaz. Şayet "remote admin connections" parametresinin değeri "1" yapılırsa, o zaman bu mümkündür.

Örnek:
EXEC sp_configure "remote admin connections", 1
RECONFIGURE

Varsayılan bir SQL Server 2005 (ve üstü) kurulumlarda yukarıda belirttiğim SQL Server Configuration parametreleri etkin değildir ve bunlar SQL Server Instance'ınızın performansını ve işlevselliğini olumsuz şekilde etkileyebilir. Ben ortamımda yaptığım kurulumlardan sonra bu özellikleri etkinleştiriyorum, eğer sizin ortamınıza da uygunsa siz de bu ayarları yapmayı düşünebilirsiniz.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 3

2011-12-22T09:52:00.002+02:00

Varsayılan SQL Server kurulumundan sonra yapılmasında fayda olabilecek diğer SQL Server Server ayarlarından diğer bazıları:

- - max degree of parallelism: OLTP sistemler için bu parametrenin değerini "1" yapmakta, yani işlemleri seri şekilde çalışmasında fayda var. Şayet paralel çalışması gereken (Index işlemleri vb.) işlemleriniz varsa, o zaman o işlemlerde ilgili Hint'leri (örneğin Index Rebuild işlemi için MAXDOP=4 gibi) kullanmanızda fayda var.

Örnek:
EXEC sp_configure "max degree of parallelism", 1
RECONFIGURE

- max server memory (MB): İnternet ortamındaki forumlarda veya başka sosyal ortamlarda insanlardan şunu çok duyarsınız "SQL Server sunucudaki tüm RAM'i kullanıyor ve diğer uygulamalar sıkıntı çekiyorlar!". Çünkü SQL Server'ın varsayılan "max server memory (MB)" ayarı, sunucudaki tüm RAM'in kullanılmasına göre ayarlıdır. O yüzden SQL Server birden değil, ama işlem yoğunluğuna göre yavaş yavaş veya hızlı hızlı tüm RAM'i kullanmaya meyillidir. Şayet "max server memory (MB)" parametresini elle ayarlarsanız, bunu sınırlayabilirsiniz. Örneğin sunucunuzda 8GB RAM varsa ve SQL Server'ın sadece 4GB RAM kullanmasını istiyorsanız o zaman "max server memory (MB)" parametresinin değerini "4096" yapabilirsiniz.

Örnek:
EXEC sp_configure "max server memory (MB)", 4096
RECONFIGURE

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 2

2011-12-21T11:31:00.002+02:00

Bir SQL Server Instance'ının kurulumundan sonra yapmanız gereken şeylerden biri de SQL Server Configuration ayarlarıdır. Bu ayarların çoğunu "sp_configure" isimli SP ile yapabilirsiniz.

Örneğin OLTP bir sistem için ben aşağıdaki ayarları yapıyorum:
- awe enabled: Sunucunuzun işlemci mimarisi 32Bit ise (eğer hâlâ varsa?) ve sunucuda 4GB'tan fazla RAM varsa, o zaman SQL Server bu özelliği (boot.ini dosyasına PAE* parametresini de ekleyerek) etkinleştirmek isteyebilirsiniz. Bu sayede SQL Server'ın Buffer Cache'inin 2GB'tan fazla RAM kullanmasını sağlayabilirsiniz. Aksi halde SQL Server sadece 2GB RAM kullanacaktır, sunucuda 32GB RAM olsa da.

Örnek:
EXEC sp_configure "awe enabled", 1
RECONFIGURE

- blocked process threshold (s): SQL Server 2005 ile birlikte SQL Server Profiler aracına Blocking takibi yapılabilmesi için "Blocked Process Report" isimli bir Event eklendi. Bu Event, "Errors and Warnings" başlığının altında bulunmaktadır. Bu Event kullanıldığında, Blocking takibi, "sp_configure" ile ayarlayacağınız "blocked process threshold (s)" parametresine verilen zaman bilgisine göre yapılmış olacak. Örneğin bu parametreye "5" değerini verirseniz, o zaman 5 saniyeyi geçen Blocking sorunları "Blocked Process Report" isimli Event tarafından Profiler Trace'te yakalanacaktır.

Örnek:
EXEC sp_configure "blocked process threshold (s)", 5
RECONFIGURE

Not: Devamı yarın...

* PAE parametresi hakkında ayrıntılı bilgi: KB283037 (İngilizce)

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 1
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

SQL Server Kurulumlarında Gözden Kaçanlar - 1

2011-12-20T10:26:00.003+02:00

SQL Server kurulumlarının birçok kurumda SQL Server DBA'leri tarafından yapılmadığını gözlemledim. Bu kurulumlar genelde ya yazılımcılar tarafından ya da genel olarak sistem alt yapı bölümünde çalışan personel tarafından yapılıyor. Tabii hal böyle olunca, SQL Server'ın verimli ve sağlıklı çalışabilmesi için yapılması gereken birçok ayar gözden kaçıyor.

Sizlerle paylaşıyor olacağım bu kurulum ipuçlarını nihai doğru olarak almanızı beklemiyorum, bunlar benim kendi ortamıma uygun olduğu için uyguladığım pratikler. Sizlerin ortamlarının daha farklı ihtiyaçları olabilir. Bu nedenle sizlerle paylaşacağım ipuçlarının açıklamalarını da elimden geldiğince yapacağım. Sizin ortamınız için iyi gelip gelmeyeceğine de bu sayesi sizler karar verebileceksiniz.

Bu başlık silsilesiyle, ipuçlarını ayrı ayrı paylaşacağım; belki daha sonra tek bir yazı altında toparlarım.

Sunucunun mimarisine göre, kurulum yapılmadan önce SQL Server servis hesabı olarak kullanılacak hesaba Local Security Policy'de "Perform volume maintenance" hakkı verilmelidir. (Control Panel->Administrative Tools->Local Security Policy->Local Policies->User Rights Assignment)

Perform volume maintenance: Bu hak sayesinde, SQL Server için Instant File Initialization özelliğini açmış olacaksınız. Bu özellik sayesinde:
- Bir veritabanı oluştururken,
- Varolan bir veritabanına veri dosyası eklerken (bu özellik Transaction Log dosyalarında işe yaramıyor),
- Autogrowth dahil, varolan bir dosyanın boyutunu büyütürken,
- Bir veritabanını Restore ederken.

İşlemi anında gerçekleştirmiş oluyorsunuz. Aksi takdirde, yani bu özellik kullanılmadığında ise, yukarıda belirttiğim işlemler gerçekleşirken, dosya boyutu kadar sıfır, dosyanın içine yazılıyor ve dosyalar bu şekilde oluşturuluyor. Haliyle de örneğin 50GB'lık bir dosyayı yukarıda sıraladığım şekilde oluşturmak istediğinizde uzun süre beklemek durumunda kalabiliyorsunuz.
Özellikle de üretim sunucularınızda gerçekleştirmek istediğiniz işlemleri en kısa zamanda gerçekleştirmek istersiniz. Kimse bu işlemlerde vakit kaybetmek istemez. Özellikle bazı durumlar oldukça kritik olabiliyor ve bu durumlarda bu özelliğin nimetlerinden faydalanmayı kesinlikle istersiniz.

Şayet SQL Server kurulumunu zaten yaptıysanız ve bu özelliği daha sonra etkinleştirmek isterseniz, SQL Server servis hesabına bu hakkı verdikten sonra, bu özelliğin etkinleşmesi için SQL Server Database Engine servisini kapatıp tekrar başlatmanız gerekmektedir.

Konuyla ilgili diğer ipuçları:
SQL Server Kurulumlarında Gözden Kaçanlar - 2
SQL Server Kurulumlarında Gözden Kaçanlar - 3
SQL Server Kurulumlarında Gözden Kaçanlar - 4
SQL Server Kurulumlarında Gözden Kaçanlar - 5
SQL Server Kurulumlarında Gözden Kaçanlar - 6
SQL Server Kurulumlarında Gözden Kaçanlar - 7
SQL Server Kurulumlarında Gözden Kaçanlar - 8

Golden Gate: ERROR OGG-00868 Oracle GoldenGate Capture for ODBC, EXTRACT.prm: Supplemental logging is disabled for database 'veritabanı_adı'. To enable logging, perform the following: 1) Set 'trunc. log on chkpt.' to false. 2) Create a full backup of the database. Please refer to the "Oracle GoldenGate For Windows and UNIX Administration Guide" for details.

2011-12-19T17:31:00.000+02:00

HATA:
ERROR OGG-00868 Oracle GoldenGate Capture for ODBC, EXTRACT.prm: Supplemental logging is disabled for database 'veritabanı_adı'. To enable logging, perform the following: 1) Set 'trunc. log on chkpt.' to false. 2) Create a full backup of the database. Please refer to the "Oracle GoldenGate For Windows and UNIX Administration Guide" for details.

AÇIKLAMA:
Bu hata oluştuğunda, ilgili Extract ABENDING duruma geliyor ve (eğer otomatik başlatma parametresi etkin değilse) duruyor. Hiçbir şey yapmanıza gerek kalmadan doğrudan Extract'ı başlatırsanız (START EXTRACT) o zaman Extract tekrar sağlıklı bir şekilde başlıyor ve Replication devam ediyor.

Biz bu sorun ile karşılaştığımızda, sorun tam da bu şekilde açıkladığım gibiydi. Yani aslında veritabanının "Supplemental Logging"inin Disabled duruma getirildiği falan yoktu. Fakat yine de Golden Gate bu hatayı vererek ABENDING duruma düşüp kapanıyordu zaman zaman. Bu konuda Oracle'a SR (Service Request) açtık ve onlar da bu konuda bir yama çıkardılar. Yeni versiyonu kullandıktan sonra bu hata ile karşılaşmadık.

Siz de sorunu çözmek için yeni bir versiyon kullanmayı deneyebilirsiniz. Örneğin: 11.1.1.1.2_01

Ekrem

Golden Gate: ERROR OGG-00146 Oracle GoldenGate Capture for ODBC, EXTRACT.prm: VAM function VAMInitialize returned unexpected result: error 600 - VAM Client Report .

2011-12-19T17:23:00.000+02:00

HATA:
ERROR OGG-00146 Oracle GoldenGate Capture for ODBC, EXTRACT.prm: VAM function VAMInitialize returned unexpected result: error 600 - VAM Client Report .

AÇIKLAMA:
Bu sorun üstünde Oracle Support ile çok uzun süre çalıştık. Sorunun ne olduğunu bulamadılar, bir gün şansa biz bulduk. Bu sorun oluştuğunda ilk başlarda Extract'ın parametre dosyasında ALTARCHIVELOGDEST parametresini kullanıyor ve sorunu geçici savuşturuyorduk. Bu geçici çözümü de şansa bulmuştuk yine.

ALTARCHIVELOGDEST parametresi oldukça masraflı bir parametre. Bu parametre kullanıldığında, Transaction Log Backup kayıtlarında ve Online Transaction Log dosyasında bulunamayan LSN; tüm Transaction Log Backup dosyaları taranarak bir şekilde bulunuyordu. Daha sonra öğrendik ki, normal şartlar altında Golden Gate, SQL Server'ın sistem veritabanı olan MSDB veritabanındaki Backupset ve BackupMediaFamily tablolarını kullanarak bulmaya çalışıyor aradığı LSN'leri. Bir şekilde eğer alınan Transaction Log Backup'ın kaydı bu tablolarda yoksa, o zaman Golden Gate bu hatayı alarak duruyor. ALTARCHIVELOGDEST parametresi kullanıldığında ise Golden Gate'in LSN arama yöntemi değişiyor ve sistem tabloları yerine tüm yedek dosyalarını tek tek açarak ilgili LSN'i bulmaya çalışıyor, bu nedenle işlem çok uzun sürüyor. Tabii ki ilgili yedek klasöründe kaç tane dosya olduğu ve bu dosyaların büyüklüğüyle de doğrudan ilgili bir konu bu.

Bizim durumumuzda sistem tablolarındaki boşlukların nedeni ise, yine SQL Server'ın Backup tarihçesinin temizlenmesi için kullanılan Sistem SP'sinin çalışırken Transaction Log yedeği alındığında bu işlemin sistem tablolarına işlenmesinin engellenmesiydi. Yani temizlik işlemi yapılırken şayet Transaction Log yedeği alınırsa, o zaman Transaction Log yedeği alınıyor, fakat Deadlock oluşuyor ve bu işlem MSDB'deki sistem tablolarına işlenemiyordu.

Görüldüğü üzre bu sorun doğrudan SQL Server'da oluşan Deadlock nedeniyle kaynaklanıyor ve sorunun doğrudan Golden Gate ile ilgisi yok. Golden Gate, sorunun sonucundan etkileniyor. Biz bir şekilde Deadlock oluşmasını engelledik, şayet siz de bu sorunu yaşıyorsanız ve Deadlock oluşmasını engelleyebilirseniz, o zaman Golden Gate'teki bu sorundan da kurtulmuş olursunuz.

Ekrem

Golden Gate: "Invalid character value for cast specification"

2011-12-19T17:12:00.000+02:00

HATA:"Invalid character value for cast specification"

AÇIKLAMA / ÇÖZÜM:Ben bu hata ile ilk önce Replicat tarafında karşılaşmıştım. Golden Gate'in "logdump" isimli araçıyla sorunu didiklerken, Replicat tarafında eklenmeye çalışılan tarih alanı değerinin 1757.58.35 gibi bir abuk değer olduğunu fark etmiştim. Bu sorunu da sadece sıkıştırılmış tablolarda yaşıyordum.

Daha sonra bu sorunu düzelttiklerini söylemişlerdi ve yeni bir versiyonu kullanmamı önermişlerdi. Yeni versiyonu kurmuştum ve daha sonra da aynı sorunla bu sefer kaynakta, Extract'larda karşılaşmıştım. Bu sefer sorunu sadece sıkıştırılmış tablolarda değil, tüm tablolarda yaşıyordum. Bu sefer de farklı bir versiyona yönlendirmişlerdi ve sorun bu şekilde çözümlenmişti.

Ekrem

İş ilanı (SQL Server DBA)

2011-11-30T10:08:00.001+02:00

Selam arkadaşlar,Sizinle bir iş ilanı paylaşmak istiyorum, ilgilenenler CV'lerini doğrudan bana (enaksanamun AT gmail . com) gönderebilirler. Ben de ilgili kişilerle paylaşacağım.

Genel Nitelikler:Üniversitelerin ilgili bölümlerinden mezunİngilizce bilenMinimum 3 yıl veritabanı yönetimi tecrübesi olanVeritabanı recovery deneyimi bulunan“Disaster recovery site” uygulama deneyimi olanİleri seviyede SQL bilgisi bulunanVeritabanı tasarım bilgisine sahipPerformans izleme ve optimizasyon bilgisi olanTakım çalışmasına yatkınİletişim becerisine sahipAskerliğini tamamlamış

İş Tanımı:Firmamıza MS Sql Server 2005 & 2008 sunucularının ,· Kurulumu yönetimi,· Sunucu ve disk donanımlarının planlanması· Backup ve recovery planlarının hazırlanıp uygulanması· Performans izleme ve optimizasyon çalışmalarının yapılması· “Disaster recovery site” planlanması ve uygulanması· Gerekmesi halinde recovery planlarının uygulanmasıKonularında görev alacak “Veri Tabanı Yöneticisi” arayışımız bulunmaktadır.

2011-11-15T14:00:00.001+02:00

HATA:The database owner SID recorded in the master database differs from the database owner SID recorded in database 'veritabanı_adı'. You should correct this situation by resetting the owner of database 'veritabanı_adı' using the ALTER AUTHORIZATION statement.AÇIKLAMA:Bir kullanıcı sistemde bir SP çalıştırmak istediğinde böyle bir hata ile karşılaştığını söylemişti. Bahsi geçen veritabanında TRUSTWORTHY özelliği açıktı. Bu sorunla önceden de karşılaştığımız için sorunun veritabanı sahibinden kaynaklandığını biliyordum.ÇÖZÜM:Veritabanının sahibini aşağıdaki gibi bir kod ile "sa" yaptığınızda sorun çözülür:USE [veritabani_adi]GOEXEC sp_changedbowner 'sa'GO

"Cannot generate SSPI context. (Microsoft SQL Server)"

2011-10-07T16:23:00.000+03:00

HATA:Cannot generate SSPI context. (Microsoft SQL Server)

AÇIKLAMA:Bu hatayı değişik durumlarda alabilirsiniz. Hemen biraz önce bir kullanıcı bana bu hatayı aldığını söyledi. En son ne zaman sağlıklı bağlandığını, o zamandan bu yana ne değişiklik olduğunu falan sordum ve o arada bana Windows Domain şifresinin değiştiğini söyledi. Kilit ipucu buydu işte. Çünkü şifresini değiştirdikten sonra yeni şifre ile hiç Windows'una giriş yapmamıştı ve bu nedenden dolayı Windows Authentication işlemi yapılırken o anki şifresiyle Active Directory'deki şifresi eşleştirilemiyordu ve SQL Server'a giriş yapamıyor ve bu hatayı alıyordu.

ÇÖZÜM:Kullanıcıya Windows'undan Log Off olup sonra Log In işlemlerini uygulaması gerektiğini söyledim, fakat kullanıcı bana o anda makinesinde birçok uygulama açık olduğunu ve bunun sıkıntılı olacağını söyledi. Ben de kendisine SQL Server Management Studio'yu SHIFT tuşu basılıyken farenin sağ tuşuna basıp başka bir kullanıcı olarak (Run as a different user) SSMS'i açabileceğini ve bu sayede yeni şifresini kullanabileceğini ve Authentication işleminin başarıyla yapılabileceğini ve hatayı almayacağını anlattım. Uygulayınca da sorun çözümlenmiş oldu. Bu şekilde de sizele bu sorun için iki çözüm paylaşmış oldum, umarım işinize yarar =)

"Product: SQL Server System CLR Types -- SQL Server System CLR Types requires the .NET Framework version 2.0 or 3.0 or 3.5 or 4.0. Ensure that this r"

2011-09-28T14:17:00.000+03:00

HATA: Product: SQL Server System CLR Types -- SQL Server System CLR Types requires the .NET Framework version 2.0 or 3.0 or 3.5 or 4.0. Ensure that this requirement is fulfilled before installing SQL Server System CLR Types.

AÇIKLAMA:
SQL Server 2008 (SP1 + CU2) sunucularımızdan birine SP2 kurmaya çalışırken bu hatayı aldım. Sunucuda haliyle .Net kurulumu zaten vardı. Bu kurulumu onarmak istediğimde de başka bir hata alınca, en akıllıcasının sunucuyu yeniden başlatmak olduğunu düşündüm ve voila!

ÇÖZÜM:
Sunucuyu yeniden başlatınca bu sorun düzeliyor. Eğer olur da düzelmezse, .Net kurulumunu onarmayı denemenizi tavsiye edebilirim.

"Error 14274: Cannot add, update, or delete a job (or its steps or schedules) that originated from an MSX server. The job was not saved."

2011-08-15T09:40:00.000+03:00

HATA:
Error 14274: Cannot add, update, or delete a job (or its steps or schedules) that originated from an MSX server. The job was not saved.

AÇIKLAMA:
SQL Server 2000 Instance'ınızın üstünde çalıştığı Windows İşletim Sisteminin bilgisayar adını değiştirdikten sonra Job'larla çalışırken böyle bir sorun ile karşılaşabilirsiniz. Sorunun nedeni ve çözümü Microsoft KB'sinde (http://support.microsoft.com/kb/281642) anlatılıyor. O yüzden daha fazla açıklama girmeyeceğim, ama çözümü bir de Türkçe yazayım.

ÇÖZÜM:
- Bilgisayarın adını eski haline getirin.
- Job'ları tekrar oluşturabilmek için Script'lerini çıkarın ve Job'ları silin.
- Bilgisayarın adını yeni adıyla değiştirin.
- 2. adımda oluşturduğunuz Job Script'leriyle Job'ları tekrar oluşturun.

"String or binary data would be truncated."

2011-07-28T16:45:00.000+03:00

HATA:
String or binary data would be truncated.

AÇIKLAMA:
Örneğin bir SQL Server 2008 Instance'ındaki Job History'sini SQL Server 2005 Management Studio ile açmaya çalışırsanız bu hata mesajıyla karşılaşabilirsiniz:

ÇÖZÜM:
Bu tarz garip sorunlarla karşılaşmamak için her versiyonun kendi araçlarını (SSMS, Proffiler gibi) kullanmanızda fayda var. Örneğin bu sorundan kurtulmak için yapılması gereken, SQL Server 2008 Instance'ına SQL Server 2008 Management Studio ile bağlanmanızdır.

"The report server database is an invalid version."

2011-07-22T11:52:00.000+03:00

HATA:
"The report server database is an invalid version."

AÇIKLAMA:
Reporting Services'a bağlanmaya çalıştığınızda Windows Application Event Log'unda böyle bir hata mesajı görebilirsiniz. Event ID: 117, Type: Error.

ÇÖZÜM:
Bu hata, Reporting Services'in kurulumundan sonra, yapılandırılmasının gerçekleştirilmemesinden kaynaklanıyor. Yapılandırmayı gerçekleştirmek için Reporting Services Configuration aracını kullanmanız gerekiyor. Bu araç ile Report Manager Virtual Directory, Windows Service Identity, Database Setup gibi tüm ayarları yapmalısınız. Kırmızı yuvarlak içerisinde X kalmadığından emin olduktan sonra Reporting Services'a (örneğin SSMS ile) tekrar bağlanmayı deneyebilirsiniz.

Oracle Golden Gate & SQL Server: Extract'in takılı\asılı kalması sorunu

2011-07-20T14:47:00.000+03:00

Arkadaşlar farkındayım bu aralar hep Replication (veri aktarma) uygulamaları ve özellikle de Oracle Golden Gate'in SQL Server ile çalışmasından, sorunlarından vs. bahsediyorum. Bunun nedeni, bu ürünün çalıştığım firmada servis yöneticisi olmam ve bu ürünün sorunlarıyla uğraşıyor olmam. Bu sorunlarla boğuşurken, Google'da arattırıldığında Golden Gate ile kaynaklara ulaşmadaki zorluğu gördüğümden dolayı ve Türkiye'de bu ürünün (her ne kadar sınırlı olsa da) kullanımının artmasından dolayı, Türkçe içerik oluşturmak için paylaşımda bulunmak istiyorum.

Çok uzun süredir bu ürünün kaynak sunuculardaki Extract'larının asılı kalma sorunuyla boğuşuyoruz. Bu konuda Oracle Development Vice President'i Alok ile de hem yüzyüze, hem de telekonferans şeklinde birkaç toplantı yaptık. Ayrıca tabii ki bu konuda bir SR (Service Request - Çağrı Kaydı)'ımız da var ve Oracle Support ile sorun üstünde çalışmalarımız devam ediyor.

Önce biraz sorunu tanımlayayım, ondan sonra da neden bu sorun hakkında paylaşımda bulunduğumu aktarayım.

Sorun, kaynaktaki Extract Process'lerinin çalışıyor olarak görünmelerine (RUNNING) rağmen aslında Transaction Log veya Transaction Log Backup dosyalarından kayıt okuyamalarıdır. Tabii ki kayıt okunamadığı için de, tablolara yapılan yeni işlemler hedef sunucuya aktarılamıyor. Bu sorunu farketmek normal şartlar altında zor, ancak kullanıcılar yeni veri gelmiyor diye şikâyet ettiğinde farkedebiliyorsunuz çünkü her şey çalışıyor görünüyor.

Bu sorunu sizlerle paylaşıyorum, çünkü bu sorun hakkında internette bir şeye ulaşmanız zor. Ayrıca geldiğimiz noktaya gelinceye kadar biz çok vakit ve emek harcadık, siz de Amerika'yı tekrar keşfetmek için vakit harcamayın.

Henüz sorun ile ilgili bir yama (Patch) çıkarılabilmiş değil, fakat en son yaptığımız toplantıda Oracle bu sorun konusunda çok yol aldıklarını ve sorunu gidermek için bir test versiyonu yaptıklarını söylüyorlardı. Yakında deneyeme başlarız sanırım. Bu, bize özel bir sürüm olacak; genel için ise bu sürümü 2012 senesinin başında yayınlayabileceklerini söylediler.

Örneğin eğer sorunlu Extract'a SEND STATUS komutunu gönderdiğinizde aşağıdaki gibi bir sonuç alıyorsanız:

GGSCI (SUNUCU_ADI) 79> SEND E_XXX01 STATUS

Sending STATUS request to EXTRACT E_XXX01 ...

EXTRACT E_XXX01 (PID 24612)
Current status: Recovery complete: At EOF

Current read position:
LSN: 0x0017a155:0001d552:0009
Timestamp: 2011-07-20 10:11:08.403333

Current write position:
Sequence #: 376
RBA: 5696650
Timestamp: 2011-07-20 15:11:18.633000
Extract Trail: ./dirdat/I1

O zaman bu sorunu yaşıyorsunuz demektir. Görüldüğü üzere "Current status" verisi Recovery'nin tamamlandığını, dosya sonuna gelindiğini söylüyor; fakat bu komutu çalıştırdığımda saat 15:11 olmasına rağmen "Current read position" sabah saat 10:11'de kalmış. Eğer siz de böyle bir sonuç alıyorsanız, Extract'ınızın takılı\asılı kalma sorunu var demektir.

Sorunu geçici olarak aşmanın yolu ise çoğu sorunu aşmak için kullandığımız yöntem ile aynı: "kapat / aç". Evet, sorunu aşmak için sorun yaşanan Extract Process'ini STOP EXTRACT komutu ile durdurup, START EXTRACT komutuyla başlatmanız yetiyor.

Ben bu sorunun geçici çözümünü otomatikleştirdim. Bunu burada ayrıntılı olarak anlatmayacağım, çünkü muhtemelen çok az kişinin başına gelebilecek bir sorun. Eğer birisi gerçekten bu sorunu yaşarsa, o zaman benimle irtibat kurabilir. Önceden de bahsettiğim gibi, maksadım internet ortamında Golden Gate'in SQL Server ile çalışması konusunda bilgiye ulaşabilmeniz, en azından yazdıklarım ilk etapta size fikir verir.

Çok özetlemek gerekirse, oluşturduğum otomatik çözüm şöyle çalışıyor:
- Kaynak ile hedef arasında bir "Heartbeat" sistemi oluşturdum. Her 15 saniyede bir, kaynaktan hedefe Timestamp bilgisi gönderiliyor.
- Şayet hedefteki en son Timestamp, o anki saatten 10dk. gerideyse, o zaman SQL Error Log'una ilgili Extract ile bir kayıt kaydediliyor.
- HP OpenView hedefteki bu kaydı algılıyor (bunun yerine başka bir uygulama veya yöntem de kullanılabilir) ve kaynaktaki yazdığım uygulamayı çalıştırıyor.
- Yazdığım uygulama, SEND STATUS komutu ile Extract'ın Timestamp bilgisini o anki saat ile karşılaştırıyor ve eğer 10 dakika fark varsa, o zaman "Current status" bilgisine bakıyor, eğer hem Current Read Position'ın Timestamp'i 10 dk gerideyse ve Current status de "Recovery complete: At EOF" ise, o zaman ilgili Extract, STOP EXTRACT komutuyla durduruluyor. Hemen ardından tekrar SEND STATUS komutları gönderiliyor ilgili Extract'a ve "ERROR: EXTRACT E_INT01 not currently running." sonucu geldiğinde de START EXTRACT komutuyla ilgili Extract başlatılıyor.

Programa bir log'lama sistemi de eklediğim için, yeniden başlatmalar hakkında ayrıntılı bilgi de edinebiliyorum. Şayet olur da bir gün bu sorun ile karşılaşırsanız haber verin, uygulamamı paylaşabilirim.

Sorunuçta dediğim gibi, bu geçici bir çözüm ve Oracle kalıcı çözüm için çalışıyor. Ama bizim gibi günü kurtarmak zorundaysanız, o zaman böyle bir şeye muhakkak ihtiyacınız var demektir.

Selamlar,
Ekrem

SQL Server & Oracle Golden Gate

2011-07-12T15:16:00.000+03:00

HATA:

2011-07-12 09:08:20 ERROR OGG-01296 Error mapping from DBA.KAYNAK_TABLOM to DBA.HEDEF_TABLOM.

veya

2011-07-12 09:08:20 WARNING OGG-01154 SQL error 100 mapping DBA.KAYNAK_TABLOM to DBA.HEDEF_TABLOM No data found.

Açıklama:

Bildiğim kadarıyla Golden Gate ile bu sorunu sadece SQL Server'da değil, Oracle Database'de de yaşayabilirsiniz. Bu sorun, kaynaktan hedefe aktarılacak kayıdın hedefte bulunmamasından kaynaklanıyor. "Bir şekilde" aktarılamayan kayıt, kaynaktaki Extract tarafından yakalanamıyor. Bu konuda üzerinde Oracle Support ile çalıştığımız bir SR mevcut, fakat henüz bir sonuca ulaşamadık. Ulaşınca onun hakkında da bilgi veririm.

Sorunu gidermek için ise benim uyguladığım yöntem oldukça doğrudan ve pratik, yaptığım şey ilk önce (eğer değilse, ki mümkünse olmasın) hedefteki Replicat'ın parametre dosyasında kullanılan aşağıdaki parametrelerin

(değerler örnektir)
grouptransops 2000
maxtransops 2000

aşağıdaki gibi değiştirilmesi:

grouptransops 1
maxtransops 1

Böylece Discard dosyası Replicat tekrar çalıştırıldığında dolup taşmayacak ve o anda sorun yaşanan kayda ulaşabileceksiniz. Sorun yaşanan Replicat'ın Discard dosyasından parametrelerini elde ettiğiniz kaydı kaynaktan hedefe elle aktarmanız gerekiyor. Bunun için benim şimdiye kadar bulduğum en pratik yöntem, sorunlu kaydı kaynaktan hedefe SQL Server'ın Import\Export Wizard'ını kullanarak aktarmak.

Bu işlemi yaptıktan sonra hedefteki Replicat'ı doğrudan çalıştırabilirsiniz. Bu işlemi bazen art arda birkaç kere yapmak gerekebiliyor, kaynaktan kaç tane kayıt kaçırıldığına bağlı olarak değişebilir.

Bu sorun besbelli ki Oracle Golden Gate'in bir BUG'ı. Sorun hakkında Case açalı 2 ay olacak neredeyse, istenilen her bilgi ve dosya paylaşılmasına rağmen maalesef bir sonuca varamadık. Bununla birlikte bu sorunu bu yazımda belirttiğim geçici çözümle geçici olarak aşabilir, en azından günü kurtarabilirsiniz.

Ahh bu arada, sorunu düzelttikten sonra, yani tüm eksik kayıtları kaynaktan hedefe attıktan sonra grouptransops ve maxtransops parametrelerini eski değerleriyle değiştirmeyi unutmayın, yoksa hedefte kayıtların işlenmesi çoook çok yavaş olur. Bu parametreler hakkında daha fazla bilgi için Oracle Golden Gate Reference Guide'a bakabilirsiniz.

Selamlar,
Ekrem

Üretim sunucularımızdan birisi

2011-07-06T19:18:00.000+03:00

Gerçekten sağlam üretim sunucularımız var ;)

Ekrem

SQL Server Replication, Sybase Replication Server, Oracle Golden Gate

2011-07-06T16:55:00.000+03:00

Verileri etkin bir şekilde biriktirmek ve depolamak işin sadece bir tarafı, diğer tarafı da bu bilginin kullanılabilir hale getirilmesi. Bu maksatla her türlü 3. parti üründen de yararlanabilme fırsatını kolluyoruz. Dünya çapındaki yenilikleri takip ediyoruz ve işimize yarayabileceğini düşündüğümüz yazılım ve donamını test ortamlarımızda deniyoruz veya ürünler hakkında sunumlar talep ediyoruz.

Bu kapsamda geçen ayın son günlerinde Sybase Türkiye'den Evren Tokçelik (Teknik Danışman) ve Borga Kaşdoğan (Satış Yöneticisi) bize Sybase'in Replication ürünü olan Replication Server ürününü tanıttı.

Adından da anlaşılabileceği üzere Sybase Replication Server, temel olarak A noktasında bulunan verilerin heterojen (farklı RDBMS'lerden farklı RDBMS'lere) B, C .. ortamlarına aktarılması amacıyla kullanılabilecek bir Replikasyon (veri aktarımı) uygulaması. Bu uygulamanın temel olarak yaptığı şey Oracle Golden Gate veya SQL Server Replication'ın yaptığı şey olan veri aktarımı. Bazı arkadaşlarımın aklına Database Mirroring ile Log Shipping de veri aktarımı için kullanılabilir gibi bir fikir gelebilir, tabii ki öyle, ama hepsi de farklı ihtiyaçlara göre farklı durumlarda kullanılır ve bu konulara önceden zaten çok değinmiştik, o yüzden bu yazıda bu teknolojilerden bahsetmeyeceğim.

Bu yazımda daha ziyade doğrudan SQL Server Replication, Oracle Golden Gate ve Sybase Replication Server'ı karşılaştırıp size bir fikir vermek istiyorum.

Birbirine daha yakın olduklarından dolayı öncelikle SQL Server Replication ve Sybase Replication Server arasındaki ufak farklardan bahsedeyim:

Sybase Replication Server'ın, SQL Server Replication'a karşı olan en temel üstünlüğü heterojen ortamlardaki desteği. Birçok farklı RDBMS'ten birçok farklı diğer RDBMS'e veri aktarma özelliği bulunuyor, SQL Server Replication'ın ise bu konudaki desteği çok kısıtlı. Sybase Replication Server'ın bir başka özelliği ise (biz bu konuda herhangi bir POC testi yapmadık, bu nedenle vurgulamak istiyorum ki bu konuda tabiri caizse Evren ve Borga'nın yalancısıyım) SQL Server Replication'dan daha hızlı olması. Fakat elimizde bu konuda bir dokümantasyon, karşılaştırma, Benchmark vs. bulunmuyor. Bununla birlikte, SQL Server (Transactional) Replication'ın (SQL Server 2008'den itibaren) Partition Switch desteği bulunuyor, fakat Sybase Replication Server her ne kadar DDL değişikliklerini aktarma özelliğini barındırsa da, Partition Switch işlemini desteklemiyor ne yazık ki.

Bu karşılaştırma sonrasında bir iki maddede şöyle diyebilirim:
SQL SERVER Replication :
+ SQL Server Replication ek bir maliyet gerektirmiyor. Ayrıca ürün ve destek ekibi aynı olduğundan dolayı, destek konusundaki maliyetler de düşük olur.
+ Partition Switch desteği, özellikle arşivleme vb. amaçlarla tablolarında Partition yapısını kullanan firmalar için güzel oldu.
- Heterojen ortamlardaki destek çok düşük.
- (İddiaya göre) yeterince hızlı değil.

Sybase Replication Server:
+ Eğer büyük bir firmada iseniz veya küçük ama çeşitli bir ortamınız varsa heterojenliğe olan desteğin ne kadar önemli olduğunu bilirsiniz. Bu açıdan Sybase Replication Server yeterince destek sağlayabiliyor.
+ (İddiaya göre )SQL Server Replication'dan daha hızlı.
- Partition Switch desteği yok.
- Ekstra lisans maliyeti söz konusu. Bununla birlikte personelin de bu yeni ürün için eğitim ihtiyacı oluşacak. Yeterli know-how'ın oluşması da vakit alacak ve bu süreçte zorluk çekilecek.
- Sybase Replication Server ürününün şu anda Türkiye'de SQL Server ile birlikte kullanıldığına dair referans olarak gösterilebileceği bir ortam yok ne yazık ki. Bu da ürün konusunda etrafınızda danışabileceğiniz birilerini bulmanın zorluğunu işaret ediyor. Google'da aradığımda hakkında bir şey bulamadığım üründen pek haz etmiyorum açıkçası...

Önceden birçok kere SQL Server Replication kurdum ve yönettim, Oracle Golden Gate'i de bulunduğum firmada 2 senedir ben kurup yönetiyorum, her türlü sorunuyla da (ITD ve Oracle Support'un da destekleriyle) ben uğraşıyorum. Şimdi de bugüne kadar edindiğim deneyimlere göre SQL Server Replication ile Oracle Golden Gate'in karşılaştırmasını yapmak istiyorum.

Bu sefer öncelikle madde madde iki ürünün birbirlerine olan artı ve eksilerinden bahsedeyim.

Oracle Golden Gate:
+ Transaction Log Backup'lardan, Transaction Log dosyasında bulunmayan kayıtları okuyabiliyor. Şu anda piyasada bildiğimiz kadarıyla bunu yapabilen başka bir uygulama yok.
+ Index bakımı yapılan zamanlarda (5-6 saatte 850GB Transaction Log yedek dosyası oluştuğunu düşünün) biraz yavaşlasa da, genel anlamda oldukça hızlı. Gündüz çalışması esnasında çok ender 1 dakikanın üzerinde gecikme yaşıyoruz.
+ Golden Gate ürünü geçen sene sanıyorum Ekim veya Kasım ayındaydı, Oracle tarafından satın alındı. Bunun hem artı hem de eksi yanları olduğunu düşünüyorum. Sonuçta Oracle ve Microsoft'un çok iyi anlaşamadığı genel olarak bilinir, ama tabii ki ticari çıkarlar söz konusu olunca orta yolu da buluyorlar. Bu mânâda özellikle ilk satın alma sonrası zor zamanlar geçirdik, ama bu noktadan sonra artı kısmını yaşayacağımızı düşünüyorum, çünkü Oracle sonuçta çok güçlü bir firma ve bu ürünü daha güçlü desteklemesini bekliyorum.
- DDL değişikliklerini aktarmıyor.
- Partition Switch desteği yok.
- Ürünün varsayılan arayüzü Komut İstemcisinden (Command Prompt) çalışıyor. Kendi dili ve sistemi var haliyle. Bunları öğrenmek deneyimli mühendisler için bir zaman alabilir. Google'da Golden Gate için de herhangi bir bilgiye ulaşmak çok zor.
- Lisans ücretleri çok yüksek.

SQL Server Replication:
+ DDL değişikliklerini aktarabiliyor.
+ Partition Switch desteği var.
+ Ekstra lisansa gerek yok.
+ Yukarıda Sybase için belirttiğim gibi, ekstra eğitim masrafına genelde gerek kalmıyor. Ayrıca Google'da SQL Server Replication konusunda okuyamayacağınız kadar çok Microsoft dokümanına, Blog'a ve Forum mesajlarına ulaşabilirsiniz.
- Maalesef Transaction Log Backup'lardan okuma işlemi yapamıyor.
- Golden Gate'ten daha hızlı çalışmıyor.

Sonuç olarak Sybase Replication Server'ın büyük bir artısını göremedim ben. Oracle Golden Gate ile karşılaştırınca tercih etmeyi düşünmeyeceğim bir ürün. Oracle Golden Gate'i de SQL Server ile karşılaştırınca yukarıda da gördüğünüz gibi birçok eksi tarafı var, ama özellikle Transaction Log Backup'lardan veri okuyabilmesi ölümcül derecede önemli. Çünkü bu özellik olmadığında (ki diğer iki üründe yok) kaynaktan veri okuyan Agent (bu her üründe farklı isimlendiriliyor, örneğin Oracle Golden Gate için Extract) hata verdiğinde, eğer bu özellik olmazsa Transaction Log dosyası Recovery Model'i SIMPLE bile olsa, defalarca Transaction Log Backup'ı da alınsa Truncate edilemez (yani içi boşaltılamaz). Bu da üretim sisteminizi (Production) büyük tehlikeye atar. İlk etapta eğer Transaction Log diskinizde yeterince boş alan varsa ve bu dosyanın mantıksal AutoGrowth ayarı sınırsızsa ilk önce disk dolmaya başlar ve ardından herhangi yeni bir işlem yapılamaz. Daha sonra bu işin içinden çıkmak gerçekten çok baş ağrıtıcı olabiliyor, başıma gelmişti... Oracle Golden Gate bu konuda tamamen kusursuz değil, ama eğer bu ürünle de bu şekilde biraz tecrübe edinebilirseniz, bunlarla nasıl başaçıkabileceğinizi öğreniyorsunuz. Fakat ne SQL Server Replication'da ne de Sybase Replication Server'da, ancak yeniden Initial Load, Snapshot Initialization vs. yaparak sistemin prangalarını çözebilirsiniz; tabii ki patlama sorunu çözmüş olmazsınız, o tamamen ayrı bir konu.

Eğer bir gün kullanacak olursanız, ortamlarınızda yapacağınız POC testlerine sırtlarınızı tamamen dayamayın. Emin olun POC'de göreceğiniz sadece size fikir verecektir. Daha sonrasında türlü türlü sorunlarla karşılaşabilirsiniz. Tavsiyem, bu ürünler için referans isteyin ve esas kullanıcılarıyla konuşun. Size ürünü en iyi onlar anlatacaktır.

Kolay gelsin,
Ekrem

SQL Server & Oracle Golden Gate: WARNING OGG-00091 VAM Client Report <[TruncMgr::Timer] Unable to execute procedure. The database is not published. Ex

2011-07-06T16:40:00.000+03:00

Merhaba,

Son zamanlarda Oracle Golden Gate ile yaşadığım bir sorunu paylaşmak istiyorum sizlerle.

Bu sorunda maalesef başka çeşitli ürünlerde de yaşayabildiğim hatalı hata mesajı sorununu yaşadım. Tabii ki karşıma çıkan hata mesajının çok yanıltıcı olduğunu, sorunu tespit edince anladım.

Hata mesajı şuydu:
"WARNING OGG-00091 VAM Client Report <[TruncMgr::Timer] Unable to execute procedure. The database is not published. Execute the procedure in a database that is published for replication. Error (-2147217900): Unable to execute procedure. The database is not published. Execute the procedure in a database that is published for replication."

Bu hatayı, kaynak sunucuda Extract'ı başlattıktan kısa bir süre sonra Extract'ın Report dosyasında (dirrpt klasöründeki) görüyordum. Bununla birlikte Extract ABENDED veya STOPPED durumlarına gelmiyor, hâlâ RUNNING görünüyordu.

Sorunu yeniden oluşturmak için şöyle bir yol izleyebilirsiniz:
- Yeni bir Extract ekleyin (ADD EXTRACT).
- Extract'ın parametre dosyasını ihtiyacınıza göre düzenleyin, yalnız ODBC adını başka bir veritabanına giden bir ODBC adı olarak verin (evet, bizim durumumuzdaki sorun buydu). Örneğin Extract işlemini yapacağınız veritabanı XXX, ama o Extract'ın parametre dosyasında kullanılan ODBC'deki veritabanı YYY.
- Başarılı bir şekilde DBLOGIN SOURCEDB ile o ODBC'ye bağlanın.
- Yine başarılı bir şekilde ADD TRANDATA ile, Extended Logging'i etkinleştirmek istediğiniz tablolar bu işlemi gerçekleştirin.
- Extract'ı çalıştırın.

Yukarıdaki işlemleri gerçekleştirdikten sonra Extract'ın Report dosyasında bu hatayı göreceksiniz.

Biz bu hata konusunda Oracle Support ile birlikte çalıştık ve neredeyse 1 ay sonra, o da kazayla başka bir şeye bakarken sorunun bu olduğunu gördük. Gördüğünüz gibi hata mesajının sorunun kendisiyle doğrudan hiçbir ilgisi yok. Hata mesajına bakınca gidip CDC'yi veya başka bilumum şeyi kontrol etmek geliyor akla, ama ODBC adını Extract parametre dosyasında doğru mu yanlış mı yazdığınızı kontrol etmek gelmiyor maalesef.

Kolay gelsin,
Ekrem

More VRP

2011-05-25T14:23:00.000+03:00

Uzun bir aradan sonra, henüz bugün tanımını aldığımız More VRP yazılımından bahsetmek istiyorum sizlere. Bu uygulamadan size, bize sunumu yapan Michael Rozhkovsky gibi ayrıntılı bir şekilde bahsetmeyeceğim tabii ki. Fakat Veritabanı Yöneticiliği yapan ve kritik noktalarda görevli kişilerin bu konuda bilgisi olmasını istediğim için bu uygulamadan kısa da olsa bahsetmek istedim.

More VRP, temel olarak bir Kriz Yönetim uygulaması ve yine temel olarak yaptığı şey ise İşlem Yönetimi (Transaction Management). Bu uygulamanın henüz piyasada bir eşi benzeri olmadığını da vurgulamak isterim, en azından firmanın bize verdiği bilgi bu yönde. Uygulamanın Türkiye'deki distribütörü ise Aktek Bilgi İletişim Tek. San. Tic. A.Ş.

Uygulamanın izleme modülüyle, sistemde çalışan tüm işlemleri görebiliyorsunuz. CPU, IO masraflarını ve bu işlemlere ait birçok ayrıntıyı anlık bilgilerle izleyebiliyorsunuz. Ayrıca bu arayüzü birçok grafiklerle de süslemişler.

Bu bahsettiğim şeyler elbette bu uygulamayı eşsiz yapan bir özellik değil, bu uygulamayı eşsiz yapan ve patenti sadece bu firmada bulunan ve tabii ki bizi de büyüleyen özelliği ise, seçtiğiniz sorguların CPU ve IO masraflarını anlık olarak daraltabilmeniz.

Bir örnek vermek gerekirse: örneğin ortamınızda iki tane sorgu çalışıyor, biri CPU kaynağının %30'unu, diğeri de %50'sini harcıyor diyelim. Bu sorgulardan herhangi birini seçerek, o anda harcıyor olduğu kaynakların değerini %30'dan %10'a anlık olarak çekebiliyorsunuz. Bu işlem saniyeler içerisinde gerçekleşiyor. Dediğim gibi, bu teknolojinin patenti sadece merkezi İsrail'de olan bu firmaya ait.

Uygulamanın Console denilen bölümü ayrı bir sunucuya kuruluyor. Bu sunucu öyle ahım şahım bir şey olmak zorunda değil. 4GB RAM'i olan PC gibi bir makine olabilir. Console ise takip edilecek sunucularla bir Agent vasıtasıyla haberleşiyor. Agent ise bir CPU'nun sadece %0.5'i kadar kaynak tüketiyor en fazla. Çünkü tüm işi yapan Console. Bu yüzden üretim sunucularınıza ek yük getirecek bir durum da söz konusu değil.

Ayrıca sistem Cluster\RAC yapılarını da destekliyor. Failover anlarında geçişler otomatik ve yöneticilere hissettirilmeden yapılıyor. RDBMS tarafındaki kesintilerin sonuna kadar hissedilmesi ise tabii ki ayrı bir konu.

Yine bize verilen bilgilere göre bu uygulamayı İsrail'de çok büyük Telekom ve Banka firmaları da dahil 400 firma kullanıyor, dünya çapında ise 600 firma. Önceden Oracle Golden Gate ile ilgili böyle bir facia yaşadığımız için haliyle hemen Türkiye'de bu ürünü SQL Server üretim ortamlarında kullanan olup olmadığını sordum, Aktek'ten arkadaşlar bana olumsuz yanıt verdiler. Onlar da 1 senedir bu uygulamayı Türkiye'de temsil ediyorlarmış ve bu süreçte birçok firmada POC (Proff of Concept) çalışması yapmışlar, fakat henüz üretim ortamında ürünü kullanan yok.

Açıkçası ürün benim oldukça ilgimi çekti. Kriz durumlarında sorun yaratan sorguları, SP'leri vb. dizginleyebilmek ve sorunu çözünceye kadar bu işlemleri belli sınırlar içinde tutabilmek oldukça mantıklı ve makul. Sorun çözülünce sınırlamaları kaldırmak da çok kolay.

Tabii ki ürünün başka birçok özellikleri de var, örneğin ne kadar isterseniz o kadar geçmişe dönük sorguları ve masraflarını saklayabilmek, yanyana sürüm yükseltme (Side by Side Upgrade) sonrasında iki sunucuyu karşılaştırıp kazanım ve kayıpları gösterebilmek, bir gün öncesi ve sonrası veya başka tarih aralıklarında gerçekleşen sistem değişikliklerini veritabanı bazında listeleyebilmek, değişen Execution Plan'ları çok rahat bir şekilde belirleyebilmek gibi...

Son olarak şunu söylemeliyim ki ürün sadece SQL Server ile çalışmıyor. Oracle, DB2 gibi RDBMS'leri de destekliyor. Ayrıca OS olarak da Platform Bağımsız bir ürün.

SQL Server'a özel olarak ise, SQL Server'ın sadece 2005 ve 2008 özelliklerini destekliyor şu anda. SQL Server 2008 R2 desteği henüz yok. SQL Server 2000 için ise Microsoft ile iş birliği yapmak istemişler, fakat Microsoft SQL Server 2000'i biz bile desteklemiyoruz artık demiş, gerisini siz düşünün.

Umarım ürün hakkında az çok fikir edinebilmenize yardımcı olur bu bilgiler.

Ekrem Önsoy

Could not load package "UpdatePreApprovalCampaignSSIS" because of error 0xC0014062.

2011-04-27T09:20:00.000+03:00

HATA: Could not load package "paketin adı" because of error 0xC0014062.
Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80040E4D (Login failed for user 'kullanıcı adı'.). The SQL statement that was issued has failed.

AÇIKLAMA:
Bir SSIS paketi yüklemeye çalıştığınızda böyle bir hata ile karşılaşabilirsiniz.

Çözüm:
Kullanıcının ("Login failed for user" bölünde yazan kullanıcının) ilgili sunucuda Login'i ve yeterli hakları bulunduğundan emin olun. Örneğin "msdb" veritabanının altındaki SSIS rollerini de kontrol edebilirsiniz.

ÖNEMLİ: SQL Server 2008 Online Index Rebuild'deki davranış değişikliği!

2011-04-05T10:30:00.000+03:00

Arkadaşlar dün yeni bir şey daha öğrenmiş olduk, fakat bu öğrendiğimiz şeyi geç öğrenmenin bedelini de ödedik.

SQL Server 2008'e geçtiğimizden beri Index bakımı yapılan zamanlarda Transaction Log yedeklerimizin eskiye nazaran çok büyüdüğünü gözlemledik ve Transaction Log yedeklerimizi aldığımız disk artık yetmez oldu. Acilen ekstra disk talep ederek bu sorunu atlattık, ama anlayamadığımız şey neden birden böyle bir sorunla karşılaştığımızdı. Kayıt sayılarında böyle ani bir artık beklenecek bir durum yoktu ortada, en azından işlemler açısından.

Sağolsun MS PFE'mizin bize ilgili KB'yi iletmesiyle sorun anlaşıldı. SQL Server 2008'den itibaren, Online Index Rebuild işlemleri Transaction Log dosyasına artık tam olarak işleniyormuş. SQL Server 2005'te bu işlem asgari seviyede yapılıyormuş. Bu sorunu kritik sistemlerimizi SQL Server 2008'e yükseltince farkettik, çünkü malum kritik sistemler en fazla kayıdın oluştuğu sistemler ve bu nedenle de Transaction Log'un en çok kullanıldığı, en büyük Transaction Log yedeklerinin oluştuğu sistemler.

Daha fazla bilgi için ilgili KB'yi incelemek isteyebilirsiniz: http://support.microsoft.com/kb/2407439

2011-2012 Microsoft SQL Server MVP Ödülü, 3. kere =)

2011-04-03T17:56:00.000+03:00

Selam arkadaşlar,

Bugün 3. kere Microsoft SQL Server MVP ödülünü kazandığımı öğrendim... Umarım bu sayede daha çok şey öğrenebilir ve sizlere de olabildiğince aktarabilirim.

Sevgiler,
Ekrem Önsoy

Package migration from version 3 to version 2 failed with error 0xC001700A "The version number in the package is not valid. The version number c

2011-03-07T20:03:00.000+02:00

HATA:
Package migration from version 3 to version 2 failed with error 0xC001700A "The version number in the package is not valid. The version number cannot be greater than current version number.

Açıklama:
Bir SSIS paketini doğrudan veya dolaylı olarak (örneğin bir toplu işlem dosyası (*.bat) ile) "dtexec" uygulaması kullanarak çalıştırmak isterseniz böyle bir hata ile karşılaşabilirsiniz. Örneğin ben bu sorunla karşılaştığımda, SSIS paketleri SQL Server 2008 versiyonuyla uyumluydu; paketler başka bir sunucudaydı ve paketler toplu işlem dosyaları ile çalıştırılıyordu. Paketler ise başka bir sunucudan UNC yolu kullanılarak (örn: \\...\...\...) çalıştırılıyordu. Yani çalıştırılan "dtexec" uygulaması aslında toplu işlem dosyalarına hangi makineden ulaşılıyorsa o makinedeki "dtexec" uygulaması kullanılmış oluyordu, SSIS paketlerinin bulunduğu sunucudaki "dtexec" değil.

Sorunu araştırırken şunu farkettim, operatörün bağlandığı makinede hem SQL Server 2005 hem de SQL Server 2008 kuruluydu ve operatör toplu işlem dosyasını çalıştırdığında aslında SQL Server 2005 versiyon olan "dtexec" uygulaması çalıştırılıyordu ve "eski yeniyi tanımaz" kuralına uygun olarak 2008 versiyon SSIS paketlerini tanımadığından yukarıdaki hatayı veriyordu.

Windows Environment Variables'ı kontrol ettiğimde SQL Server 2005 yolunun 2008 yolundan önce tanımlandığını gördüm, yani bir uygulama çalıştırılacağı zaman öncelikle 2005'in yollarında aranıyordu uygulama ve "dtexec" uygulaması SQL Server 2005'te de 2008'de de aynı isimle olduğundan dolayı 2005 versiyonu çalıştırılıyordu.

ÇÖZÜM:
Sorunu tespit ettiğimde geçici çözüm olarak SQL Server 2005'in "dtexec" uygulamasının adını "dtexec_" olarak değiştirdim ve artık varsayılan olarak SQL Server 2008'in "dtexec" uygulaması çalıştırılıyordu. Kalıcı çözüm olarak ise şayet gerekmiyorsa SQL Server 2005 tamamen kaldırılabilir (uninstallation). Şayet iki versiyona da ihtiyaç varsa yine ilk çözümde olduğu gibi dosya adı değiştirilebilir.

Bir taşıma tecrübesi...

2011-03-06T19:48:00.000+02:00

Bu haftasonu, çok önemli üretim veritabanı sunucularımızdan biri olan bir sunucuyu SQL Server 2005'ten SQL Server 2008'e taşıdık. Ayrıca işletim sistemi olarak da Windows Server 2003'ten Windows Server 2008 R2'ye geçmiş olduk. Bu konuda yaşadığımız bazı tecrübeleri sizinle de paylaşmak istedim.

Öncelikle akla gelen "Neden SQL Server 2008 R2'ye veya bu yılın sonunda çıkması beklenen SQL Server 2011'i (kod adı Denali) bekleyip de bu yeni versiyonlara geçiş yapmadınız da gittiniz 2 sene öncesinin versiyonuna geçiş yaptınız?" sorusunu yanıtlayayım da hepimiz rahatlayalım. Bunun nedeni, kullandığımız 3. parti bir uygulama olan Oracle Golden Gate uygulamasının henüz resmi olarak SQL Server 2008 R2'yi desteklememesi ve bu ürünü üretim ortamında kullanmamızın gerektiğidir. SQL Server 2008 R2'nin piyasaya sunulmasından sonra (RTM) 2 sene geçmiş olmasına rağmen hâlâ bu versiyona resmen desteğini açıklamamış olan Oracle'dan haliyle SQL Server 2011 için elini çabuk tutmasını beklemezsiniz. Zaten Golden Gate'i Oracle firmasına satan ve Golden Gate'in hâlâ CEO'su olan Ali Kutay Bey de geçen sene Oracle'a satış sonrası Dedeman'daki Golden Gate toplantısında şöyle demişti: "Golden Gate için artık iki geliştirme ekibimiz bulunuyor, birisi Oracle geliştirme ekibi, diğer ekip de diğer ürünleri destekleyen ekip." Golden Gate uygulamasının Oracle Database, Microsoft SQL Server, IBM DB2, Sybase vb. RDBMS'leri desteklediğini göz önüne alırsak sanırım ne demek istediğim daha net anlaşılır.

Bu taşımada, Detach\Attach ile kaybedilen zamanı kazanmak için başka değişik bir yöntem izlemek istedik. Bu yöntem ile izleyeceğimiz yol aşağıdaki gibi olacaktı:

- Veritabanları kaynak sunucuda OFFLINE duruma getirilir,
- Diskler kaynak sunucudan çekilir,
- Diskler hedef sunucuya gösterilir,
- İlgili diskler, Cluster SQL Server Resource'una bağlanılır (depend),
- Veritabanları hedef sunucuda ONLINE duruma getirilir.

Not: Hedefteki SQL Server sunucusuna önceden aynı disklerin klonları gösterilmiş ve veritabanları Attach edilmiş olmalı (ki bunu başka testler için de zaten yapmış oluyorsunuz) ve ardından da diskler geri çekilmeden önce veritabanları OFFLINE durumuna alınır ve böylece yukarıdaki sıralamış olduğum son adım gerçekleştirilebilir.

Bu yöntemi iki kere test ettik. İkisinde de ACCESS VIOLATION sorunlarıyla karşılaştık ve bu sorun da SQL Server'ın Dump almasına neden oldu. Bu sorunu araştırırken, sorunu veritabanı veri veya log dosyalarının disk kökünde (root) bulunduğu disklerde yaşadığımızı fark ettik. Diskler Mountpoint. Şayet diskin içinde bir klasör varsa ve dosyalar klasörün içindeyse, o zaman bu sorunu yaşamadan veritabanlarını ONLINE duruma aldığımızda veritabanlarının hem otomatik olarak SQL Server 2005'ten 2008'e sürüm yükseltmesi (upgrade) yapıldığını gördük, hem de başarıyla ONLINE duruma geldiklerini. Maalesef tüm disklerdeki tüm dosyaların (30 kusür diskteki yüzlerce dosyadan bahsediyorum) yerlerini değiştirmek ve testi tekrarlamak için zamanımız olmadığından dolayı bu yöntemden kısmen vazgeçtik ve aşağıdaki yöntemi izledik:

- Veritabanları kaynak sunucuda OFFLINE duruma getirilir,
- Diskler kaynak sunucudan çekilir,
- Diskler hedef sunucuya gösterilir,
- İlgili diskler, Cluster SQL Server Resource'una bağlanılır (depend),
- Veritabanları hedef sunucuda Attach edilir.

İşin garip tarafı, dosyalar Mountpoint'lerin kök dizininde de olsa elle Attach ettiğimizde herhangi bir sorunla karşılaşmamamıza rağmen, bunu SQL Server'daki OFFLINE durumda olan veritabanını ONLINE'a alarak SQL Server'a yaptırdığımızda ACCESS VIOLATION hatası almamızdı. Bunu Microsoft mühendisleriyle de paylaştık, fakat onlar da mantıklı bir açıklama bulamadı. Muhtemelen sorunu Amerika'ya taşırsak belki bir sonuç alabilirdik, ama buna da vakit yoktu. Ayrıca Microsoft'taki arkadaşlardan önceden bu tür bir sorunla karşılaşılmış senaryolar hakkında araştırma yapmalarını da rica ettik ve bizimki gibi yaşanılan bir senaryo daha bulduk (maalesef bunu bizden önce birileri bir kere denemiş anlaşılan!), fakat o sorun da yüzeysel olarak kapatıldığından ve net bir çözüm üretilemediğinden dolayı o senaryo da bizim için bir çözüm olmadı.

Bu geçiş için sabaha kadar ofisteydim ve bu sabah 9 gibi eve gelebildim. Biraz uyudum, ama şimdi Log Shipping ve Golden Gate ile ilgilenmem gerekiyor...

The EXECUTE permission was denied on the object 'xp_sqlagent_enum_jobs', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 2

2011-02-23T17:05:00.000+02:00

HATA:
The EXECUTE permission was denied on the object 'xp_sqlagent_enum_jobs', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 229)

AÇIKLAMA:
Bir SQL Server 2005 üretim sunucumuz vardı. Bunu, donanım açısından daha güçlü olan başka bir SQL Server 2005 sunucusuna taşıyorduk. Bu senaryoda, Job'ları, SSIS paketlerini (ki "msdb" veritabanının içerisindelerdi) daha kolay taşımak adına eski sunucudaki "msdb" veritabanını doğrudan taşıyarak aldık.

Her şey çok güzel gitti ve taşıma işlemimizi gerçekleştirdik. Birkaç gün sonra bir kullanıcı sunucudaki tüm Job'ları görmesi gerektiğini belirtti ve yetki talep etti. Yetki verildikten sonra kullanıcı bu gönderinin konusu olan hata mesajını aldığını belirtti.

Sorun üstünde araştırma yaparken Microsoft'un 2000274 numaralı KB'si ile karşılaştım: http://support.microsoft.com/kb/2000274

Yaşadığımız sorun tam anlamıyla bu KB'de anlatıldığı gibiydi. Fakat KB'deki yönlendirmeyi uygulamadan önce Microsoft'tan da destek almak istedik ve bir Advisory Case açtık. Microsoft destek personeli de bize bu KB'deki önerileri uygulayabileceğimizi, yurtdışında denenmiş senaryolar gördüğünü belirtti ve KB'deki önerileri tatbik ettik.

"msdb" veritabanındaki sertifikayı yeni sunucudaki "master" veritabanında Restore ettiğimizde şu uyarıyı aldık: "Warning: The certificate you created is expired."

Buna rağmen yaptığımız testlerden sonra bu hata mesajından kurtulduğumuzu gördük.

İPUCU: Windows Server 2008 R2 üzerinde SQL Server 2005'e çevrimiçi disk ekleme

2011-01-21T21:59:00.001+02:00

Selam arkadaşlar,

Bu testi henüz yaptık ve hemen sonucu sizlerle paylaşmak istedim.

İşletim Sistemi: Windows Server 2008 R2
SQL Server: 2 Düğümlü SQL Server 2005 (+SP3 + CU2) Cluster
Testin amacı: SQL Server 2005, Windows Server 2008 R2'nin çevrimiçi disk büyütme işlemi ile uyumlu olarak çalışıyor mu?

Testimizde 2 tane 2GB boyunda SAN disk kullandık. Diskleri test yapacağımız sunucuya tanıttık ve bir SQL Server veritabanı oluşturduk. Veritabanının veri dosyasını bir diske, Log dosyasını diğer diske kaydettik. Dosyaların boyutunu da her biri 1,5GB olacak şekilde ayarladık. Daha sonra SAN mühendisi arkadaşımız diskleri 3GB boyutunu büyüttü ve biz de her bir dosyayı 2,5GB'a büyüttük. SQL Error Log'larını kontrol ettik, sorun yok. Daha sonra tekrar emin olmak için diskleri 4GB boyutuna getirdik ve oluşturduğumuz veritabanının veri ve Log doysalarının boyutlarını da 3,5GB boyutuna getirdik ve tüm bu büyütme işlemlerinin tamamının çevrimiçi, kesintisiz ve sorunsuz bir şekilde gerçekleştirildiğini gördük.

Diyeceğim odur ki, Windows Server 2008 R2 üzerinde bulunacak ve SQL Server için kullanılacak disklerinizi gönül rahatlığı ile çevrimiçi büyütebilirsiniz!

Hepimize kolay gelsin.
Ekrem

İPUCU: "Awaiting first complete passive cluster node 'Virtual Server Name'"

2011-01-21T09:30:00.000+02:00

SQL Server 2005 Cluster kurulumunu yaptıktan sonra Service Pack veya Cumulative Update kurarken, kurulum ekranı bu mesaj yazar halde kalıyor olabilir.

Bu durumda, sadece kurulum yapıyor olduğunuz düğümde oturum açtığınıza ve diğer düğümlerde siz dahil kimsenin oturum açmadığından emin olmalısınız. Bu tedbiri aldığınız sürece bu sorunu yaşamazsınız.

SQLServer Error: 17750, Could not load the DLL xplog70.dll, or one of the DLLs it references. Reason: 126(The specified module could not be found.). [

2011-01-17T09:45:00.000+02:00

HATA:
SQLServer Error: 17750, Could not load the DLL xplog70.dll, or one of the DLLs it references. Reason: 126(The specified module could not be found.). [SQLSTATE 42000] (ConnCacheSubsystems)

AÇIKLAMA:
SQL Server Agent servisinin çalışmayabilir ve bu hatayı da SQL Agent'ın Error Log dosyasında görebilirsiniz.

ÇÖZÜM:
"xplog70.dll" dosyası bozulmuş olabilir, aynı versiyondaki bir SQL Server sunucusundan bu dosya temin edilip, sorun yaşanan SQL Server kurulumundaki bozuk dosyanın üzerine yazılabilir. Sorun bu şekilde çözülecektir.

SSAS: ascmd ile birden fazla veritabanının yedeğini zaman ayarlı olarak almak

2011-01-03T13:52:00.000+02:00

Senaryo: Windows Server 2008 R2 İşletim Sistemi üzerinde çalışan bir sunucumuz var, talep edilen ise sunucuya sadece bir tane SQL Server 2008 R2 Analysis Services Instance'ının kurulması. Yedekleme uygulamamız olan Commvault SSAS veritabanlarının yedeğini alamadığı için DBA olarak yapmamız gereken ise SSAS'teki veritabanlarının yedeklerinin zaman ayarlı olarak alınmasının sağlanması.

Bu gereksinimi gidermek için sevgili arkadaşım Batuhan Yıldız (Microsoft PFE)'dan destek aldık, çünkü konu hakkında çözüm için gereken araç gerece ulaşmak kolay değildi.

Eğer sunucuda bir SQL Server 2008 Database Engine kurulu olsaydı işimiz çok kolay olacaktı, çünkü SQL Server Agent hem XMLA kodlarını çalıştırıyor (ki veritabanlarının Backup Script'lerini çalıştırmak için bu işlevselliğe ihtiyaç var) hem de zaman ayarlı olarak çalışabiliyor.

Fakat bizim durumumuzda bir SQL Server Agent yok. SQLCMD ise XMLA kodlarını çalıştırmıyor. SQL Server'ın doğrudan kendi parçası olan başka da bir araç gereci yok.

Batuhan'dan adını ilk defa duyduğum "ascmd" isimli aracın varlığını da bu sorunla öğrenmiş oldum. "ascmd" isimli araç, tam da aradığımız gibi, SQLCMDvari bir araç ve XMLA Script'lerini çalıştırabiliyor. Fakat bu araç ile ilgili bir sorun var, SQL Server 2005 versiyonunu Codeplex'te bulabiliyorsunuz; fakat SQL Server 2008 versiyonunu internette bulmak konusunda ben muvaffak olamadım. Ancak Microsoft'taki diğer arkadaşlardan doğrudan elden alarak edinebildik bu aracı. Ayrıca şunu da belirtmek isterim ki, bu aracın uygulama halini (exe) doğrudan edinemiyorsunuz. Bu aracın kaynak kodlarını edinebiliyorsunuz ve bu kodları indirdikten sonra derlemeniz gerekiyor. Derlemek için de cscript.exe yetmiyor, Visual Studio'nun C# bileşenlerinin de yüklü olması gerekiyor.

Bizim durumumuzda birden fazla SSAS veritabanının yedeklenmesi gerekiyordu. Böyle bir durumda da aşağıdaki gibi bir Script'inin kullanılması gerekiyor. Yani "Batch" bloğunun içinde olmalı yedek alma Script'leri.

Veritabanim1

X:\BACKUP\Veritabanim1.abf
true

Veritabanim2

X:\BACKUP\Veritabanim2.abf
true

Velhasıl, "ascmd" uygulamasını ve yedekleme Script'lerini edindikten sonrası bildik hikâye. Bu Script'i bir XMLA dosyasına kaydedip aşağıdaki gibi bir komut dizisiyle Windows Task Scheduler kullanarak zaman ayarlı olarak çalıştırabilirsiniz:

ascmd -S DWANALIZ -i X:\BACKUP\ASBackupScript.xmla

Error 1075: The dependency service does not exist or has been marked for deletion.

2010-12-31T13:41:00.000+02:00

HATA:
Error 1075: The dependency service does not exist or has been marked for deletion.

AÇIKLAMA:
Windows Server 2008 R2 İşletim Sistemi üzerinde Clustered SQL Server 2005 Enterprise Edition kurduktan sonra servisleri Failover Manager ile test ettiğimde SQL Server Fulltext Search servisinin çalışmadığını gördüm.

Bunun nedeni, Fulltext servisinin "NTLM Security Support Provider (NTLMSSP)" adında bir servisi kullanmak istemesi, fakat bu servisin Windows Server 2008'de bulunmaması.

ÇÖZÜM:
Eğer SQL Server 2005 SP2'yi yüklerseniz sorun çözülüyor.

Ya da alternatif olarak aşağıda belirttiğim Registry (Regedit) yolunda olan "NTLMSSP" anahtarını silin ve işletim sistemini yeniden başlatın.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\msftesql\DependOnService

Property ErrorLogFile is not available for JobServer 'sunucu_adı'. This property may not exist for this object.

2010-12-28T22:47:00.000+02:00

HATA:
Property ErrorLogFile is not available for JobServer 'sunucu_adı'. This property may not exist for this object.

AÇIKLAMA:
SQL Server Management Studio'daki, Object Explorer'da bulunan SQL Server Agent'ın üzerine farenin sağ tuşuna tıkladığınızda bu hata mesajını alabilirsiniz.

ÇÖZÜM:
Bu sorunun SQL Server Agent için kullanılan bir kayıt defteri (registry editor) değerinin "bir şekilde" silinmesinden kaynaklandığını görmüştüm. Kayıt değerinin bulunduğu yola örnek aşağıdadır:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.MSSQLSERVER\SQLServerAgent

Eğer bu yoldaki ErrorLogFile isimli anahtara aşağıdaki gibi bir değer (sizin sisteminizde yukarıdaki yol da, aşağıdaki değer de farklı olabilir, bunlar sadece örnek) girerseniz sorununuz çözülecektir:

C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\SQLAGENT.OUT

Description: The package is encrypted with a password. The password was not specified, or is not correct. End Error Could not load package "\MSDB\SS

2010-12-24T17:41:00.000+02:00

HATA:
Description: The package is encrypted with a password. The password was not specified, or is not correct. End Error Could not load package "\MSDB\SSISPaketi_adi" because of error 0xC0014037. Description: Failed to remove package protection with error 0xC0014037 "The package is encrypted with a password. The password was not specified, or is not correct.". This occurs in the CPackage::LoadFromXML method

AÇIKLAMA:
Aşağıdaki gibi bir kod ile bir SSIS paketini çalıştırmak istediğinizde böyle bir hata alabilirsiniz:

dtexec /DTS "\MSDB\SSISPaketi_adi" /SERVER DWSQL /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING V

Bu hatayı almanızın nedeni, SSIS paketinin şifreli olması ve sizin bunu dtexec uygulamasında "/De" parametresiyle belirtmemiş olmanızdır.

ÇÖZÜM:
Bu SSIS peketini "dtexec" ile çalıştırırken "/De" parametresini de kullanarak şöyle çalıştırın:

dtexec /DTS "\MSDB\SSISPaketi_adi" /SERVER DWSQL /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING V /De 1234

The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Fai

2010-12-23T15:30:00.001+02:00

HATA:
The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

AÇIKLAMA:
SQL Server Error Log'unda böyle bir mesaj görebilirsiniz. Bu mesajı almanız mutlak şekilde sunucunuza olan bağlantıların KERBEROS değil, NTLM olacağı anlamına gelmiyor. Bu hatayı, gerekli yetkileri olmayan bir Windows Domain hesabıyle çalışan SQL Server servisi açıldığında Active Directory'den SPN kaydı yapmaya çalışıyor diye alıyorsunuz.

ÇÖZÜM:
Öncelikle ilgili sunucuya yaptığınız bağlantının NTLM mi yoksa KERBEROS mu olduğundan emin olmanızı tavsiye ederim; bunu, aşağıdaki kodu ilgili sunucuda çalıştırarak görebilirsiniz:

SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID

Eğer dönen sonuç KERBEROS ise, zaten Active Directory'de ilgili sunucunun SPN kayıtları mevcut demektir; eğer dönen sonuç NTLM ise, o zaman SPN kaydı mevcut değildir ve bu durumda şirket organizasyonunuza göre SPN kayıtlarını siz de oluşturabilirsiniz, bunu sistem yöneticilerinin yapmasını da isteyebilirsiniz.

SPN kayıtlarının oluşturulması hakkında daha fazla bilgi için aşağıdaki KB'den yararlanabilirsiniz:

SQL Server 2011: Kod adı "Denali" - CTP1

2010-12-13T17:19:00.000+02:00

SQL Server'ın yeni versiyonuna ait ilk tanıdım sürümünü aşağıdaki adresten indirebilirsiniz.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6a04f16f-f6be-4f92-9c92-f7e5677d91f9&displaylang=en

Dokümantasyona da aşağıdaki adresten ulaşabilirsiniz:
http://msdn.microsoft.com/en-us/library/ms130214%28v=sql.110%29.aspx

Benim en çok gözüme batan bir kaç özellik şöyle:

HADR: Bu teknoloji daha ziyade sürekli kullanılabilirlik (high availibility) ve afet durumları (disaster recovery) için tasarlanmıştır. Bir başka amacı ise, ikincil sunucudaki veritabanı kopyalarının raporlama amacıyla kullanımının sağlanması ve böylelikle ana veritabanının sırtından yük alınmasının sağlanmasıdır. Bu sistemin kurulması için Windows Failover Cluster Servisleri ve Database Mirroring kullanılmaktadır. Bu sistem ile bir Failover anında belirlenen veritabanları grup halinde diğer sunucuda ayağa kaldırılabilmektedir.

Containment: HADR'da olduğu gibi bu özellik de CTP1'de tam olarak kullanılamıyor. Sadece belli bir kısmı kullanılabiliyor. Fakat özetlemek gerekirse bu sistem ile veritabanının başlı başına yönetimi söz konusu. Misal olarak eğer bir veritabanındaki nesneler "Application Boundary" denilen sınır içerisindeyse "Contained" oluyor ve bu veritabanı başka bir SQL Server Instance'ına aktarıldığında, bu veritabanıyla birlikte herhangi bir sunucu düzeyindeki nesnelerden biri olan Login gibi bir nesnenin aktarılması da zorunluluk olmuyor. Çünkü veritabanına ulaşım için yine veritabanı içerisinde tanımlanan kullanıcılar (artık SQL Server veritabanlarında sadece Database User'lar olmayacak, Database Login'ler de olacak) bağlantı için yeterli olabiliyor.

Sequences: Sequence'ler tablo bazında çalışan Identity'ler gibidir, fakat veritabanı bazındadır ve birçok tablo tarafından kullanılabilirler. Yine Identity'den farklı olarak sürekli aynı sayı bloğu içinde tekrarlanmaları sağlanabilir, meselâ sürekli 1-100 arası sayı üretebilir. Bir Insert'ten önce de bir Sequence'ten sayı talebinde bulunabilirsiniz ve böylece kayıt yapmadan önce hangi sayıyı kullanarak kayıt yapacağınızı bilirsiniz. Ayrıca sadece bir değil, bir dizi şeklinde de sayı talebinde bulunabilirsiniz.

Denali CTP1'de benim en çok gözüme batan yenilikler böyle. Yakın zamanda HADR için bir test yapacağız. Bunun için iki tane sunucu talebinde bulunduk. Sunucular bize verilir verilmez uygun bir vakitte bu testi yapmak istiyoruz. Umarım test sonuçlarını da sizlerle paylaşma şansı bulacağım.

Şimdilik Denali CTP1 hakkında verebileceğim bilgiler bu kadar.

Ekrem

Itanium desteği

2010-12-13T14:38:00.001+02:00

Daha önceki gönderilerimden birinde de bu konudan bahsettiğimi anımsıyorum.

Bugün Denali'nin Books Online bölümünü okurken gördüğümü sizinle de paylaşmak istiyorum.

http://msdn.microsoft.com/en-us/library/bb500459%28v=SQL.110%29.aspx

Yukarıdaki sayfada aşağıdaki ibareyi bulacaksınız sayfanın en altında.

Itanium Support: Starting with SQL Server Code-Named “Denali”, SQL Server Itanium editions are no longer supported.

(Türkçesi: Itanium Desteği: Kod adı "Denali" olan SQL Server'dan itibaren SQL Server Itanium versiyonları artık desteklenmeyecek)

Bilginize ;)

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)

2010-12-08T16:28:00.000+02:00

HATA:
"Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: xxx.35.1.26]

Error: 18452, Severity: 14, State: 1.

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)"

AÇIKLAMA:
Bir SQL Server Instance'ına uzaktan SSMS ile bağlanmak istediğinizde böyle bir hata alabilir ve SQL Error Log'unda da böyle bir hata görebilirsiniz.

ÇÖZÜM:
Ben bu hata ile, ilgili SQL Server Instance'ının servis hesabını başka bir Domain servis hesabıyla değiştirdiğimde karşılaşmıştım.

Sorun, Active Directory'deki ilgili SPN kayıtlarının güncellenmemesinden oluşmuştu. İlgili SPN kayıtlarımız güncellendikten sonra bu sorundan kurtulduk.

An invalid schema or catalog was specified for the provider "Local Server" for linked server "(null)".

2010-12-08T09:19:00.001+02:00

HATA:
"An invalid schema or catalog was specified for the provider "Local Server" for linked server "(null)"."

AÇIKLAMA:
Ben bu hata mesajını, bir Linked Server kullanarak aşağıdakine benzer bir komutu çalıştırdığımda almıştım:

SELECT * FROM LinkedServerSunucum.Veritabanim..Tablom

ÇÖZÜM:
Linked Server kullandığınız sorgularda Fully Qualified Name (tam hedef yolu) kullandığınızdan emin olun. Bunun taslağı da aşağıdaki gibidir:

[Linked Server adı].[Veritabanı adı].[Schema adı].[Nesne adı]

Örnek:

SELECT * FROM LinkedServerSunucum.Veritabanim.Şemam.Tablom

An error occurred while executing batch. Error message is: Invalid attempt to GetBytes on column 'xxx_tarihi'. The GetBytes function can on

2010-12-03T17:32:00.000+02:00

HATA:
An error occurred while executing batch. Error message is: Invalid attempt to GetBytes on column 'xxx_tarihi'. The GetBytes function can only be used on columns of type Text, NText, or Image.

AÇIKLAMA:
SQL Server Management Studio'dan bir SQL Server 2008 veritabanındaki tabloya karşı sorgu çalıştırdığınızda böyle bir hata mesajıyla karşılaşabilirsiniz.

ÇÖZÜM:
Benim durumumda sorun, SQL Server 2008 veritabanına karşı çalıştırdığım bir sorguyu SQL Server Management Studio'nun 2005 versiyonundan çalıştırmamdı.

SQLServerAgent could not be started (reason: Error creating a new session).

2010-10-22T10:14:00.000+03:00

HATA:
SQLServerAgent could not be started (reason: Error creating a new session).

AÇIKLAMA:
SQL Server Configuration Manager'dan SQL Server Agent servisini çalıştırmak istediğinizde SQL Server Agent servisinin başlatılamadığına dair genel bir hata mesajı alabilirsiniz ve Application Windows Event Log'unda da bu konu başlığını oluşturan SQLServerAgent could not be started (reason: Error creating a new session). hata mesajını görebilirsiniz.

ÇÖZÜM:
Bu sorunu gidermek için SQL Server Agent servis hesabının, SQL Server Instance'ında gerekli haklara sahip olduğundan emin olmalısınız.

An invalid schema or catalog was specified for the provider "SQLNCLI" for linked server "sunucu adı"

2010-10-21T09:43:00.000+03:00

HATA:
An invalid schema or catalog was specified for the provider "SQLNCLI" for linked server "sunucu adı"

AÇIKLAMA:
Örneğin Linked Server'ınızın adına "Contoso" diyelim ve Contoso sunucusundaki "Management" isimli veritabanından "Customers" isimli tabloyu başka bir sunucudan sorgulamak istediğimizi varsayalım:

SELECT * FROM CONTOSO.Management..Customers

Böyle bir kod kullanırsanız bu hata mesajını alırsınız.

An invalid schema or catalog was specified for the provider "SQLNCLI" for linked server "CONTOSO"

ÇÖZÜM:
Bu hatayı almamak için sorgulamak istediğimiz nesneyi belirtirken tam adresini (Fully Qualified Name) kullanmamız gerekir, örneğin:

SELECT * FROM CONTOSO.Management.dbo.Customers

Yanyana Sürüm Yükseltme Kontrol Listesi (Side by side upgrade check list) : SQL Server 2005 ve üstü için...

2010-10-20T15:57:00.000+03:00

Selam arkadaşlar,

Aşağıda, kendi çalışmalarımda iki sunucu arasında taşıma yaparken aşağıdaki kontrol listesini kullanıyorum. Sizin de işinize yarayabileceğini düşünerek burada da sizlerle paylaşmak istedim bu listeyi.

Örneğin hangi durumda kullanıyorum bu listeyi? Bir sunucumuz var, fakat donanım olarak artık değiştirilmesi gerekiyor. Eski SQL Server Instance'ının donanım olarak daha iyi bir sunucuya taşınması gerekiyor. İşte bu gibi durumlarda bu liste benim çok işime yarıyor.

Listeyi ihtiyacınıza göre güncelleyebilirsiniz veya gözünüze çarpan bir şey varsa bana da bildirebilirsiniz, ben de listeyi ona göre güncellerim.

Listede Database Mirroring veya Log Shipping gibi konular şimdilik yok, belki ileride bu konulardaki en iyi pratikleri de bu listeye ekler ve burada güncellerim; ama şimdilik bunlar yok.

Temel olarak listeyi üç bölüme ayırdım. İlk aşamada, taşıma öncesi işlemler yapılıyor. İkinci aşamada, taşıma sırasında yapılacaklar. Üçüncü aşamada da taşımalardan sonra yapılacaklar var.

İLK AŞAMA (GEÇİŞ ÖNCESİ)
• WINDOWS
o Computer Management: SQL Server'da kullanılan yerel Windows hesaplarının aktarılıp aktarılmadığı, aktarıldıysa da doğru yetkilerle aktarıldığı kontrol edilmeli.
o Computer Properties: System Properties->Advanced->Performance->Performance Options->Advanced->Processor scheduling: Adjust for best performance of ”Background services” ve Memory usage: Adjust for best performance of ”Memory usage” olmalı.
o NIC (Public): File and Printer Sharing for Microsoft Network Properties->”Maximize data throughput for file sharing” olduğundan emin olunmalı.
o Local Security Policy: SQL Server Database Engine için kullanılan servis hesabının şu Policy'lerde hakkının olduğundan emin olunmalı: “Lock Pages in Memory”, “Perform Volume Maintenance”, “Log on as a service”.
o SSCM: Yeni sunucudaki SQL Server servislerinin eski sunucudaki SQL Server servis hesaplarını kullanıp kullanmadığı kontrol edilmeli.
o SSMS: SQL Server Database Engine servis hesabının Active Directory'ye erişimi olduğundan emin olunmalı. Bunu kontrol etmek için aşağıdaki komut kullanılabilir.

xp_logininfo 'kullanıcı adı'

• SQL SERVER
o Server Properties: Ayarlar taşınacak.
o Security: Login'ler taşınacak.

EXEC sp_help_revlogin2

Not: Bu Script'e şu adresten ulaşabilirsiniz:

o Security: Login’lerin Server Level Role’leri çıkarılacak ve hedefte Login’lere üyelikleri verilecek. Aşağıdaki Script’ler kullanılabilir.
SELECT s.name, s.type_desc, p.permission_name, p.state_desc FROM sys.server_principals s INNER JOIN sys.server_permissions p ON s.principal_id = p.grantee_principal_id
WHERE permission_name <> 'CONNECT SQL' AND type_desc <> 'CERTIFICATE_MAPPED_LOGIN' ORDER BY s.name

SELECT p1.name AS UserName, p2.name AS RoleName FROM sys.server_principals p1 JOIN sys.server_role_members m ON p1.principal_id = m.member_principal_id
JOIN sys.server_principals p2 ON m.role_principal_id = p2.principal_id

o Security: Sistem veritabanlarındaki kullanıcı hakları ve veritabanı rolleri de taşınacak.
o Security: Credential'lar taşınacak. Örnek kod aşağıdadır.

EXEC sp_xp_cmdshell_proxy_account 'domain\proxy_adı', 'şifresi'

o Server Objects: Linked Server'lar taşınacak. Taşıma yapıldıktan sonra Linked Server’ların bağlantı kurup kuramadığı test edilecek.
o Server Objects: Server Level DDL Trigger'lar taşınacak.
o Management: SQL Server Log'lar için hedefte ayar yapılıp yapılmadığı kontrol edilecek. (Varsayılan değer = 50)
o Management: Database Mail Account ve Profile'ları aktarılacak.
o Management: Legacy bir bileşen kullanılıyorsa onlar aktarılacak.
o SQL Server Agent: SQL Server Agent ayarları aktarılacak.
o SQL Server Agent: Proxy’ler taşınacak ve Create Script’leri oluşturularak durumlarının “Enabled” olduğu teyit edilecek. Şayet “Enabled” değillerse, o zaman aşağıdaki kod yardımıyla “Enabled” duruma getirilecekler.

EXEC msdb.dbo.sp_update_proxy @proxy_name = N'proxy adı', @enabled = 1

o Security: Proxy’leri kullanan Login’ler aşağıdaki sorgu ile tespit edilip ve bu Login’lere ilgili Proxy’ler için kullanım yetkisi verilmeli.
SELECT DISTINCT j.name as job_name, l.name as login_name, j.enabled FROM msdb..sysjobs j INNER JOIN msdb..sysjobsteps js ON j.job_id = js.job_id INNER JOIN master..syslogins l ON j.owner_sid = l.sid WHERE js.subsystem = 'SSIS' ORDER BY 2

EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'proxy_adı', @login_name=N'domain\login_adı'

o SQL Server Agent: Job'lar taşınacak.
o SQL Server Agent: Her pazar günü yeni Error Log kullanılması için eğer yoksa bir Job oluşturulmalı. ("exec sp_cycle_errorlog" kullanılarak)
o SQL Server Agent: Operator'ler aktarılacak.
o Query Editor: Disabled olan Job’ların listesi alınacak. Bunun için aşağıdaki komut kullanılabilir.

SELECT j.name, l.name FROM master..syslogins l INNER JOIN msdb..sysjobs j ON l.sid = j.owner_sid WHERE j.enabled = 0)

o SSIS: SSIS Paketleri taşınacak. Eğer doğrudan hedefteki Integration Services'a aktarım yapılacaksa, o zaman aktarım sırasında Protection Level "Rely on server storage and roles for access control" olarak seçilmeli. Eğer doğrudan hedefin Integration Services'ına erişilemiyorsa, o zaman paket dosya sistemindeki bir klasöre Protection Level'ı "Encrypt sensitive data with password" olarak seçilerek kaydedilmelidir. Paket hedefte içe aktarılırken kaynakta paket dosya sistemine aktarılırken kullanılan şifre kullanılacaktır.
o SSMS: Detach edilecek veritabanlarının CREATE DATABASE Script’leri alınır ve her bir veritabanı için oluşturulan CREATE DATABASE Script’inin sonuna FOR ATTACH komutu eklenir.
o SSMS: Her bir veritabanı için ikinci aşamada Detach işleminin daha hızlı yapılabilmesi için Detach Script’leri hazırlanır.
o SSMS: Sistem veritabanlarında oluşturulmuş nesneler varsa (tablolar, SP’ler vs.) hedef sunucuya taşınmalı.

İKİNCİ AŞAMA (GEÇİŞ)
• SQL SERVER
o SSMS: Veritabanlarını Detach etmek için önceden hazırlanan Detach Script’leri kullanılır.
o SAN Bölümü: Diskler taşınacak. Tempdb diski, geri dönme olasılığı göz önüne alınarak taşınmayacak. Aynı harfle, yeni sunucu için aynı boyutta yeni bir disk verilecek.
o Sistem Alt Yapı Bölümü: Yeni sunucunun adını ve IP bilgilerini değiştirecek, varsa Share’ler kullanıcı haklarıyla beraber taşınacak.

ÜÇÜNCÜ AŞAMA (GEÇİŞ SONRASI)
• SQL SERVER
o Query Editor: Windows tarafında bilgisayar adı değiştirildikten sonra “sp_dropserver 'old_name'” ve “sp_addserver 'new_name', local” komutları çalıştırılacak. Daha sonra “SELECT @@SERVERNAME” komutu çalıştırarak sağlama yapılacak.
o Query Editor: Tempdb dosyalarının yolu, yeni verilen disk gösterilecek şekilde değiştirilir. Örnek kod aşağıdadır.

USE tempdb
GO
EXEC sp_helpfile
GO
USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'X:\Sqldata\tempdb.mdf')
GO
USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'X:\Sqllog\templog.ldf')
GO

o Query Editor: İşlemci sayısı kadar Tempdb veri dosyası olduğu teyit edilir, yoksa olması sağlanır.
o Databases: Veritabanları, önceden hazırlanan CREATE DATABASE ... FOR ATTACH Script’leri kullanılarak Attach edilecek.
o Databases: Veritabanlarında Orphaned User olup olmadığı kontrol edilecek.
o Security: (Varsa) Credential’ların Domain isimleri yeni bilgisayar adına göre düzenlenecek.
o Management: Database Mail Account’larının çalışıp çalışmadığı (test e-postası gönderilerek) test edilecek.
o Security: Yerel Windows Login’leri tekrar oluşturulacak.
o SQL Server Agent: Credential değişikliği nedeniyle bazı Job’larda Job Owner için kullanılan kullanıcı adı geçerliliğini yitirmiş olabileceğinden dolayı Job Owner’lar kontrol edilecek.

Ve beklenen oldu! Microsoft Türkçe Technet forumları açılmaya başladı!

2010-10-20T15:27:00.000+03:00

Bir süredir beklediğimiz ve Microsoft'ta yaptığımız toplantılarda da dile getirilen Microsoft'un Türkçe Technet, MSDN ve MS Answers Forum desteği geldi!

Bu blog sayfamın sağ tarafına da bu adresleri kalıcı olarak yerleştirdim. Örneğin SQL Server, Windows Server ve Exchange Server hakkında sorular sormak için Technet sayfasına gidebilirsiniz. SQL Server tarafında değerli arkadaşlarım ve ben sorularınızı yanıtlamaya çalışacağız.

Microsoft Türkiye tarafında bu konuda bizleri, ihtiyaçları dinleyen ve desteğini esirgemeyen Baransel'e teşekkürler!

Property Size is not available for Database. This property may not exist for this object, or may not be retrievable due to insufficient access rights.

2010-10-17T15:53:00.000+03:00

HATA:
"Property Size is not available for Database. This property may not exist for this object, or may not be retrievable due to insufficient access rights. (Microsoft.SqlServer.Smo)"

AÇIKLAMA:
SQL Server Management Studio'da bir veritabanının özelliklerine bakmak istediğinizde böyle bir hata mesajıyla karşılaşabilirsiniz.

ÇÖZÜM:
Bu hata mesajıyla karşılaştığımda, EXEC sp_helpdb 'veritabanı adı' komutunu çalıştırarak veritabanının dosyalarına baktığımda bir Transaction Log dosyasının Size özelliğinin 1MB olarak ayarlandığını gördüm. Aklıma bir dosyanın boyutunun 2MB'tan küçük olamayacağı ve sorunun da bundan kaynaklanabileceği geldi ve ALTER DATABASE 'veritabanı adı' MODIFY FILE ( NAME = N'dosyanın mantıksal adı', SIZE = 3072KB ) komutunu çalıştırarak dosyanın boyutunun büyümesini sağladım.

Bu işlemden sonra veritabanının özellikler penceresini açabildiğimi ve bu hata mesajıyla karşılaşmadığımı gördüm.

An error occurred during the installation of assembly 'Microsoft.VC80.CRT,version="8.0.50727.4027",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitec

2010-10-05T18:40:00.000+03:00

HATA:
"An error occurred during the installation of assembly 'Microsoft.VC80.CRT,version="8.0.50727.4027",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86",type="win32"'. Please refer to Help and Support for more information. HRESULT:"

AÇIKLAMA:
SQL Server 2008 R2 kurulumunda, Setup Support Files yüklemesi sırasında bu hata ile karşılaşabilirsiniz. En azından bu hata mesajıyla karşılaştığımda sorun Setup Support Files'ta idi.

Bu sorun benim başıma geldiğinde hatanın nedeni Setup Support Files'ta bir çeşit sorun olmasından kaynaklanıyordu. Bu dosyaların standart yolu:

..\1033_ENU_LP\'mimari'\Setup\sqlsupport_msi\

ÇÖZÜM:
Ben bu sorunu çözmek için aynı versiyonun başka bir Edition (meselâ SQL Server 2008 R2 Enterprise Edition) Setup dosyasının yukarıda belirttiğim klasöründeki dosyaları sorun yaşadığım Edition'ın yine yukarıda belirttiğim Setup dosyalarının bulunduğu klasöre kopyaladım.

SQL Server 2008 Log Shipping Secondary sunucularda bazı veritabanlarının Single User durumunda kalmaları

2010-10-04T14:29:00.001+03:00

Sadece SQL Server 2008 versiyon SQL Server Instance'larının Secondary Log Shipping sunucularında bulunan veritabanlarında yaşadığımız bu sorunu sizlerle de paylaşmak istedim.

Soruna ait resmi aşağıda görebilirsiniz:

Sorunun ne zaman, neden ve hangi veritabanında olacağı belli olmuyor. Fakat bazen 3 ayda bir veya ayda bir herhangi bir veritabanı Standby \ Read-only olması gerekirken Standby \ Single User \ Read-only durumda kalabiliyor. Single User'a geçmesinin nedeni Transaction Log yedeğinin restore edilmesi, fakat Restore'dan sonra henüz nedenini anlayamadığım bir nedenden dolayı SQL Server veritabanını Multi User durumuna getiremiyor. Bu nedenden dolayı da bahsi geçen sunucuda Transaction Log yedekleri Restore edilemiyor ve bu nedenle de sunucudaki veritabanı güncelliğini kaybediyor, üretim sunucusundaki asıl veritabanının gerisinde kalıyor ve işe yaramaz bir duruma geliyor.

Veritabanını tekrar Multi User duruma getirmek için aşağıdaki kodu kullanabilirsiniz:

USE [master]
GO
ALTER DATABASE ['veritabanı adı'] SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO

[298] SQLServer Error: 14537, Execution in the context of disabled proxy (proxy_id = 1) is not allowed. Contact your system administrator. [SQLSTATE 4

2010-10-01T14:27:00.000+03:00

HATA:
"[298] SQLServer Error: 14537, Execution in the context of disabled proxy (proxy_id = 1) is not allowed. Contact your system administrator. [SQLSTATE 42000]"

AÇIKLAMA:
Bir Job'ı çalıştırmak istediğinizde aşağıdaki gibi bir hata mesajı alabilirsiniz:

"Unable to start execution of step 1 (reason: JobOwner sa doesn't have permissions to use proxy 1 for subsystem SSIS). The step failed."

Bu hatanın esas nedeni ise, büyük ihtimalle bu yazının başlığındaki hata olabilir. Çünkü "sa" hesabı bildiğiniz üzere "sysadmin" rolünün bir üyesidir ve "sysadmin" rolüne üye olan herkes her Proxy'yi kullanabilir. Bu açıklama bölümündeki hata mesajında ise Job Owner olan "sa" hesabının Proxy 1'i kullanmaya yetkisinin olmadığından bahsediyor. Yani bu hata mesajı çelişkili.

Bu yazıdaki hata bölümünde bulunan hata mesajına ise SQL Server Agent Error Log'undan ulaşabilirsiniz.

-> SSMS
-> Object Explorer
-> SQL Server Agent
-> Error Logs
-> Current adındaki Log'un üzerine çift tıklayarak Log'un içeriğini görüntüleyebilirsiniz.

İşte buradaki Error Log'da bu yazının hata bölümündeki hatayı görebilirsiniz.

ÇÖZÜM:
Bu durumda bahsi geçen Proxy'yi "Enabled" duruma getirmelisiniz. Bunun için aşağıdaki kodu kullanabilirsiniz:

EXEC msdb.dbo.sp_update_proxy @proxy_name = N'', @enabled = 1

"Remote table-valued function calls are not allowed."

2010-10-01T11:51:00.000+03:00

HATA:
Remote table-valued function calls are not allowed.

AÇIKLAMA:
Tam adresleme ve NOLOCK kullanarak (4 isim sunucu_adı.veritabanı_adı.schema_adı.tablo_adı) yaptığınız bir sorgu sonucunda böyle bir hata mesajı alabilirsiniz.

Örnek:
SELECT * FROM sunucu_adı.veritabanı_adı.schema_adı.tablo_adı (NOLOCK)

ÇÖZÜM:
Eğer sorgunuzda NOLOCK kullanmak istiyorsanız o zaman WITH (NOLOCK) şeklinde kullanmalısınız, aşağıdaki örnekte olduğu gibi:

SELECT * FROM sunucu_adı.veritabanı_adı.schema_adı.tablo_adı WITH (NOLOCK)

\. File attachment or query results size exceeds allowable value of 1000000 bytes. [SQLSTATE 42000] (Error 22050). The step failed.

2010-09-30T11:39:00.000+03:00

HATA:
\. File attachment or query results size exceeds allowable value of 1000000 bytes. [SQLSTATE 42000] (Error 22050). The step failed.

AÇIKLAMA:
Örneğin bir sorgu sonucunu Database Mail'de tanımlı bir posta hesabıyla göndermeye çalışırken bu hatayı alabilirsiniz.

Aslında bu, Database Mail'deki bir parametre ayarından kaynaklanıyor ve bir kontrollü bir hatadır eğer buna hata denilebilirse.

ÇÖZÜM:
Bu ayarda düzenleme yapmak için ilgili SQL Server Instance'ına SQL Server Management Studio'dan bağlanın ve aşağıdaki yolu takip edin:

-> Object Explorer
-> Management
-> Database Mail Properties
-> View or change system parameters
-> Maximum File Size (Bytes)

SQL Server 2008 SP2 çıktı!

2010-09-30T11:24:00.001+03:00

SQL Server 2008 SP2 bugün çıktı, ayrıntılar için aşağıdaki bağlantıları kullanabilirsiniz:

SQL Server 2008 SP2: http://go.microsoft.com/fwlink/?LinkId=196550
SQL Server 2008 SP2 Express : http://go.microsoft.com/fwlink/?LinkId=196551
SQL Server 2008 SP2 Feature Packs : http://go.microsoft.com/fwlink/?LinkId=202815

User 'dbo' could not execute stored procedure 'master.dbo.sp_enable_sql_debug' on SQL Server

2010-09-30T11:03:00.000+03:00

HATA:
User 'dbo' could not execute stored procedure 'master.dbo.sp_enable_sql_debug' on SQL Server

AÇIKLAMA:
SQL Server 2008'de bir Stored Procedure'ı Debug etmeye çalışırsanız bu hata ile karşılaşabilirsiniz.

ÇÖZÜM:
SQL Server 2008'de Stored Procedure'leri Debug etmek için "sysadmin" Server Fixed Role'ünün üyesi olmanız gerekmektedir.

A system assertion check has failed. Check the SQL Server error log for details. Typically, an assertion failure is caused by a software bug or data c

2010-09-29T11:16:00.001+03:00

HATA:
A system assertion check has failed. Check the SQL Server error log for details. Typically, an assertion failure is caused by a software bug or data corruption. To check for database corruption, consider running DBCC CHECKDB. If you agreed to send dumps to Microsoft during setup, a mini dump will be sent to Microsoft. An update might be available from Microsoft in the latest Service Pack or in a QFE from Technical Support.

AÇIKLAMA:
Ben bu hata ile, bir kullanıcının üretim sunucularımızdan bir tanesine aşağıdaki gibi bir sorgu gönderdiğinde karşılaştım:

SELECT TOP 100 * FROM . WHERE IN (...)

Sorgudaki IN içerisinde o kadar çok değer vardı ki, soruna neden olan buydu.

Bu sorguya ise Dump kayıt dosyalarından ulaştım. Dump dosyasının nerede olduğunu Dump mesajlarının da bulunduğu SQL Error Log'da bulabilirsiniz.

ÇÖZÜM:
Böyle durumlarda kullanıcının IN yerine Temp Tablo veya Table Variable kullanması gerekiyordu.

Msg 14262, Level 16, State 1, Procedure sp_verify_proxy_identifiers, Line 51 The specified @proxy_name ('xxxKullanicisi') does not exist.

2010-09-23T10:32:00.000+03:00

HATA:
Msg 14262, Level 16, State 1, Procedure sp_verify_proxy_identifiers, Line 51
The specified @proxy_name ('xxxKullanicisi') does not exist.

AÇIKLAMA:
Bu hatayı ben, bir Job oluşturmaya çalışırken aldım. Job Owner olarak "xxxKullanicisi" isimli kullanıcıyı kullanmıştım.

ÇÖZÜM:
Sorun, aslında hata mesajında da belirtildiği gibi "xxxKullanicisi" isimli bir Proxy'nin bulunmamasıydı. Eğer siz de böyle bir sorun yaşıyorsanız, öncelikle bu Proxy'yi oluşturmanız gerekiyor.

Msg 515, Level 16, State 2, Procedure sp_validate_user, Line 19 Cannot insert the value NULL into column 'permission path', table '@temp'; column does

2010-09-22T10:39:00.000+03:00

HATA:
Msg 515, Level 16, State 2, Procedure sp_validate_user, Line 19
Cannot insert the value NULL into column 'permission path', table '@temp'; column does not allow nulls. INSERT fails.
The statement has been terminated.
Msg 14607, Level 16, State 1, Procedure sp_send_dbmail, Line 136
profile name is not valid

AÇIKLAMA:
Ben bu hata ile, ilgili sunucudan aşağıdaki koda benzer bir kod ile Database Mail vasıtasıyla eposta göndermeye çalışırken karşılaştım:

Örnek Kod:
EXECUTE msdb.dbo.sp_send_dbmail
@profile_name = 'SMTP'
,@recipients = 'ekrem.onsoy@test.com'
,@body = 'test_mesaj'
,@subject = 'test_konu'

Bahsi geçen SQL Server Instance'ında iki tane Database Mail Profile ve Account'u mevcuttu.

ÇÖZÜM:
Sorun, iki Database Mail Profile'ının da Public olmamasıydı. Yukarıdaki örnekte de kullanılan "SMTP" isimli Database Mail Profile'ı da Public değildi.

Ya ilgili Database Mail Profile'ını Public olarak ayarlayın ya da ilgili Login'i Private Database Mail Profile'ını kullanabilecek şekilde ayarlayın.

Bu ayarları da ister T-SQL ile isterseniz de SQL Server Management Studio aracılığıyla yapabilirsiniz. Değişikliği SSMS'ten yapmak için: Object Explorer->Management->Database Mail->Manage Profile Security->Public Profiles\Private Profiles.

Msg 15404, Level 16, State 19, Procedure xp_logininfo, Line 62 Could not obtain information about Windows NT group/user 'DOMAIN\USER', error code 0x5

2010-09-21T09:10:00.000+03:00

HATA:
Msg 15404, Level 16, State 19, Procedure xp_logininfo, Line 62 Could not obtain information about Windows NT group/user 'DOMAIN\USER', error code 0x5

AÇIKLAMA:
Ben bu hata ile ilk kez xp_logininfo 'DOMAIN\USER' komutunu çalıştırdığımızda karşılaştık. Fakat bu daha genel bir sorundu, sadece bu komut ile ilgili değil. Örneğin EXECUTE AS LOGIN = 'DOMAIN\USER' komutunu çalıştırdığımızda da bu hata ile karşılaşıyorduk.

ÇÖZÜM:
Sorunun nedeni, ilgili SQL Server Instance'ının Database Engine servisini çalıştıran Windows servis hesabının Active Directory'de herhangi bir özel yetkiye sahip olmayan (bu servis kullanıcısı, SQL Server sunucusunda Yerel Yöneticiler grubunun bir üyesiydi) yerel bir Windows servis hesabı olmasıydı.

"Active Directory'de herhangi bir özel yetkiye sahip olmayan" bunu özellikle belirttim, çünkü bu sorun ile, eski bir SQL Server Instance'ımızı daha yeni bir donanıma sahip olan sunucuya "Side by Side" şeklinde taşıdıktan sonra karşılaştık. Önceki sunucudaki SQL Server Database Engine servisi de yine aynı isimli bir yerel Windows servis hesabıyla "bir şekilde" çalışmaktaydı. Henüz nasıl çalışmakta olduğunu anlayamadık, umarım zaman bulur da en kısa zamanda anlayabiliriz. Normal şartlar altında Active Directory ortamında en iyi pratik SQL Server servis hesabı olarak bir Domain servis hesabı kullanmaktır, fakat nedense zamanında bu sunucu için böyle yerel bir servis kullanıcısı kullanılmış.

Kısa kesersem, bu sorundan kurtulmak için SQL Server servis hesabınız için ya bir Domain servis hesabı kullanın ya da Local System hesabını kullanın; çoğu durumda birincisi tercih nedeni olmalı.

Failed to decrypt protected XML node "DTS:Password" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to a

2010-09-20T17:54:00.000+03:00

HATA:
Failed to decrypt protected XML node "DTS:Password" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error: 2010-09-20 17:06:12.90 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTS:Password" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error: 2010-09-20 17:06:56.19 Code: 0xC002F210 Source: DTSTask_DTSExecuteSQLTask_1... The package execution fa... The step failed.

AÇIKLAMA:
Biz bu hatayı aldığımızda sorun, ilgili SSIS paketinin içindeki adımlardan birisinin hata almasıydı.

ÇÖZÜM
Eğer böyle bir hata ile karşılaştıysanız, ilgili SSIS paketini Export edip incelemenizi tavsiye ederim. Örneğin bu hata mesajındaki sorun, "DTSTask_DTSExecuteSQLTask_1" adındaki adımdan kaynaklanıyordu. Paketi doğrudan gidip siz çalıştırdığınızda hatanın daha ayrıntılı açıklamasını görebilirsiniz.

Unable to start execution of step 1 (reason: Error authenticating proxy DOMAIN\KULLANICI, system error: ConnGetProxyPassword). The step failed.

2010-09-20T17:50:00.000+03:00

HATA:
Unable to start execution of step 1 (reason: Error authenticating proxy DOMAIN\KULLANICI, system error: ConnGetProxyPassword). The step failed.

AÇIKLAMA:
Ben bu hata ile bir Job çalıştırılırken karşılaştım. Söz konusu hata, Job'ın içindeki SSIS paketinin bir Proxy ile çalıştırılması sonucu oluşuyordu. Proxy hesabı da bir Credential kullanıyor ve sorun, Credential tanımında kullanıcı için hatalı şifre tanımlanmasından kaynaklanıyordu.

ÇÖZÜM:
İlgili Credential ayarlarının doğru yapıldığından emin olun. Kullandığınız kullanıcı bilgilerinin doğru girildiğinden emin olun.

The client was unable to reuse a session with SPID 117, which had been reset for connection pooling. This error may have been caused by an earlier ope

2010-09-17T21:40:00.000+03:00

HATA:
The client was unable to reuse a session with SPID xxx, which had been reset for connection pooling. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.

AÇIKLAMA:
Bir SQL Server Instance'ımızı donanım yükseltmesi nedeniyle başka bir sunucuya taşıyorduk (Side by Side Upgrade). Bu sırada yeni sunucumuzdaki SQL Error Log'unda bol bol bu hata mesajına rastladık ve bu sırada test yapan analistler bir takım hatalar aldıklarını söylüyorlardı... Hatanın nedeninin uygulama kullanıcısının (Login'inin) varsayılan dil ayarının (Default Language) "Türkçe" yerine "English" olarak ayarlanmasından kaynaklandığını bulduk. Bunu değiştirdikten sonra Error Log'da hâlâ zaman zaman bu hata mesajından görmekteydik. Bunun nedeninin de havuzdaki bağlantılardan olduğunu anladık.

ÇÖZÜM:
Öncelikle ilgili kullanıcıların varsayılan dil ayarlarını olması gerektiği gibi düzelttik ve ardından da bu değişikliği yaptığımız andan önce oluşturulan oturumları (Session) sonlandırdık (KILL).

Bu oturumları "SELECT * FROM master..SYSPROCESSES WHERE spid>50" komutuyla bulabilirsiniz. "login_time" değerleri de o oturumun kullanıldığı en son andır. Eski olanları veya temiz olsun diye tüm oturumları sonlandırabilirsiniz.

Proxy (1) is not allowed for subsystem "SSIS" and user "xxxUser". Grant permission by calling sp_grant_proxy_to_subsystem or sp_grant_login_to_proxy

2010-09-16T15:03:00.000+03:00

HATA:
Proxy (1) is not allowed for subsystem "SSIS" and user "xxxUser". Grant permission by calling sp_grant_proxy_to_subsystem or sp_grant_login_to_proxy.

AÇIKLAMA:
Aslında hata mesajında ne yapılacağı belirtiliyor. Hatanın alınma nedeni, paketi çalıştırmak istediğiniz Login'in, ilgili Proxy hesabını kullanma hakkının bulunmamasıdır. Ben bu hatayı, bir Job'ı oluşturmaya çalışırken aldım.

ÇÖZÜM:
EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'', @login_name=N'xxxUser'

"Cannot insert the value NULL into column 'owner_sid', table 'msdb.dbo.sysjobs'; column does not allow nulls. INSERT fails."

2010-09-16T14:35:00.000+03:00

HATA:
"Cannot insert the value NULL into column 'owner_sid', table 'msdb.dbo.sysjobs'; column does not allow nulls. INSERT fails."

AÇIKLAMA:
Bir sunucumuz fiziksek olarak değiştirileceği için bir SQL Server Instance'ımızın aynısını yeni sunucuda oluşturuyorduk. Bilirsiniz, Login'ler, Linked Server'lar, SSIS paketleri, Job'lar aktarılıyordu... Tam bu sırada bir Job'k aktarırken bu hata mesajını aldık.

ÇÖZÜM:
Eğer bu hata mesajını alıyorsanız, aktarmaya çalıştığınız Job'ın Owner'ı aktarım yaptığınız hedef SQL Server Instance'ında yoktur. sp_add_job sistem SP'sinin @owner_login_name parametresinin değeri olarak belirtilen Login'in hedef sunucuda bulunduğundan emin olun. Yoksa da oluşturun veya uygun başka bir Login ile değiştirin.

İpucu: Uzaktaki sunucunuza RDP yapacaksınız ama kullanılabilecek oturum yok!

2010-09-07T14:06:00.000+03:00

Bu konu doğrudan SQL Server ile alakalı olmasa da, DBA olarak işinize yarayacak bir ipucu olduğunu düşünüyorum. En azından ben gün içerisinde sık sık kullanmak durumunda kalabiliyorum.

Eğer benim ortamımda olduğu gibi sizin ortamınızda da bol bol SQL Server sunucusu varsa ve bunlara sistem yöneticileri, operasyon, SAN bölümü, uygulama bölümü gibi bölümlerden arkadaşların zaman zaman bağlanmaları gerekiyor ve bağlandıktan sonra da oturumlarını kapatmak yerine doğrudan bağlantılarını koparıyor ve oturumlarını açık bırakıyorlarsa, sunucuya RDP yapmak istediğiniz zaman müsait oturumun olmadığına dair şöyle bir mesajla karşılaşırsınız: "The terminal server has exceeded the maximum number of allowed connections."

İşte o anda ya Admin\Console olarak bağlanacaksınız ya da o sunucuda oturum açmış kişileri tahmin edebiliyorsanız veya biliyorsanız onları arayıp size oturum açmalarını isteyeceksiniz veya en kötü ihtimalle işinizi erteleyeceksiniz.

Çözüm olarak ise, eğer işletim sistemi olarak bilgisayarınızda bir Server OS kullanıyorsanız o zaman "tsadmin" konsolunu kullanıp uzaktaki sunucuda bulunan oturumları görüp bunları kapatabilirsiniz. Veya ister bir Server OS ister bir Client OS olsun, Command Prompt'tan kullanabileceğiniz "Query User" komutuyla uzaktaki sunucuda (eğer yeterli haklarınız varsa, portlarınız açıksa) bulunan oturumları görüp, bu oturumları sonlandırabilirsiniz.

Veya kısayol olarak "qwinsta" ve "rwinsta" komutlarını kullanabilirsiniz. "qwinsta" komutunu, uzaktaki sunucuda bulunan oturumları sorgulamak için, "qwinsta" komutunu ise uzaktaki sunucuda bulunan oturumları sonlandırmak için kullanabilirsiniz.

Bu komutlar hakkında daha fazla bilgi almak için örneğin "qwinsta /?" komutunu çalıştırabilirsiniz.

Bu komuta bir örnek vermek gerekirse, "qwinsta" veya doğrudan "Query User /server:" komutuyla uzaktaki sunucuda bulunan oturumları ve ID'lerini gördükten sonra aşağıdaki komut ile örneğin 2 ID numaralı oturumu sonlandırabilirsiniz. Bu örnekte uzaktaki sunucunun adı "PRODSQLSRV"dir.

"qwinsta 2 /server:"

İpucu: "sp_validatelogins" ve "sp_change_users_login"

2010-09-06T15:36:00.000+03:00

sp_validatelogins

Bu sistem SP'si ile, bir SQL Server Instance'ınızda Active Directory'den silinmiş Windows Login'lerinizi tespit edebilirsiniz.

SP'yi "master" veritabanı altında çalıştırabilirsiniz, eğer Active Directory'den silinmiş bir Windows Login'iniz var ise, o zaman bu SP size aşağıdaki gibi bir sonuç döndürür:

SID NT Login
0x010500000000000515000000AE78308265B37A613F005BB0A00C0000 CONTOSO\ONSOYEK

Bu Login, herhangi bir Active Directory kullanıcısıyla bağlantılı olmadığı için zaten bir işe yaramamaktadır, bu nedenle rahatlıkla silinebilir.

Bu SP hakkında daha fazla bilgi için Books Online'ı kurcalayabilirsiniz: http://msdn.microsoft.com/en-us/library/ms181728.aspx

Bu SP'yi "sp_change_users_login" sistem SP'sine de benzetebilirsiniz. Bu SP ile de veritabanı seviyesinde yetim kalmış (orphaned) SQL User'larını tespit edebilir ve Login'leriyle eşleştirebilirsiniz.

sp_change_users_login

Bir veritabanında yetim SQL kullanıcılarını tespit etmek için aşağıdaki gibi bir komut çalıştırabilirsiniz:

USE
GO
EXEC sp_change_users_login 'report'
GO

Eğer bir sonuç dönerse o zaman bu, o veritabanında yetim kalmış SQL User'larının olduğu anlamına geliyordur. Bunu düzeltmek için de aşağıdaki gibi bir komut çalıştırabilirsiniz:

USE
GO
EXEC sp_change_users_login 'Auto_Fix', ''
GO

sp_change_users_login hakkında daha fazla bilgi için: http://msdn.microsoft.com/en-us/library/ms174378.aspx

Özetle, sp_validateusers, yetim Windows Login'lerini tespit etmek için; sp_change_users_login de yetim kalmış SQL User'larını tespit etmek içinn kullanılabilir.

The SELECT permission was denied on the object 'extended_properties', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 229)

2010-09-06T14:50:00.001+03:00

HATA:
The SELECT permission was denied on the object 'extended_properties', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 229)

AÇIKLAMA:
Bir veritabanında yetkileriniz olsa dahi (örneğin db_owner veritabanı rolünün bir üyesi olsanız bile) herhangi bir tablo için SELECT ile bir sorgu çalıştırdığınızda böyle bir hata mesajıyla karşılaşabilirsiniz.

Beni yaşadığım sorunda bunun nedeni, o tabloda veya veritabanında sizin kullanıcınıza veya dahil olduğunuz bir Windows Domain Group'una ilgili SQL Server Instance'ındaki ilgili veritabanında "db_denydatareader" veya "db_denydatawriter" haklarının verilmesidir.

ÇÖZÜM:
Doğrudan kullanıcınızın veya kullanıcınızın dahil olduğu bir gruba bu yetkinin atanmadığından emin olun.

The database principal owns a schema in the database, and cannot be dropped. (Microsoft SQL Server, Error: 15138)

2010-09-05T10:48:00.002+03:00

HATA:
"The database principal owns a schema in the database, and cannot be dropped. (Microsoft SQL Server, Error: 15138)"

AÇIKLAMA:
Bir veritabanı kullanıcısını silmeye çalıştığınızda böyle bir hata mesajıyla karşılaşabilirsiniz.

ÇÖZÜM:
Veritabanı kullanıcısını silmeden önce, bu kullanıcının sahibi olduğu Schema' ları silmelisiniz.

Schema' a SSMS' ten:
Object Explorer -> Server Name-> Databases -> -> Security -> Schemas

veya

T-SQL ile:
USE
GO
SELECT dp.name [Veritabanı kullanıcısı], s.name [Schema adı] FROM sys.schemas s
INNER JOIN sys.database_principals dp ON s.principal_id = dp.principal_id
WHERE dp.name = 'EKREM-PC\EKREM'

Not: Bu T-SQL örneğinde veritabanındaki silinecek kullanıcının adı EKREM-PC sunucusundaki EKREM' dir. Yani "EKREM-PC\EKREM"

Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not hav

2010-09-05T10:48:00.001+03:00

HATA:
"Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission."

AÇIKLAMA:
Çeşitli nedenlerden dolayı bir veritabanının sahibi silinebilir veya boş kalabilir. Bir veritabanının sahibi olmadığında ve bir nesne oluşturulmaya çalışıldığında böyle bir hata mesajıyla karşılaşılabilinir.

ÇÖZÜM:
İlgili veritabanının geçerli bir sahibi olmasını sağlarsanız bu hatayı atlatabilirsiniz.

Bir veritabanının sahibini değiştirmek için aşağıdaki komutu kullanabilirsiniz:

USE
GO
sp_changedbowner ''

SSIS Error Code DTS_E_OLEDB_EXCEL_NOT_SUPPORTED: The Excel Connection Manager is not supported in the 64-bit version of SSIS, as no OLE DB provider is

2010-09-05T10:46:00.000+03:00

HATA:
"SSIS Error Code DTS_E_OLEDB_EXCEL_NOT_SUPPORTED: The Excel Connection Manager is not supported in the 64-bit version of SSIS, as no OLE DB provider is available."

AÇIKLAMA:
Bir SSIS paketi ile SQL Server’ dan Excel’ e aktarım işlemi yapmaya çalıştığınızda bu hata mesajı ile karşılaşabilirsiniz.

ÇÖZÜM:
Eğer bu SSIS paketini bir Job’ ın içerisinde çalıştırıyorsanız (ki benim durumumda böyleydi) o zaman Job’ ın Özelliklerinden, ilgili Step’ in özelliklerine gidin ve General sayfasında bulunan “Execution options” sekmesindeki “Use 32 bit runtime” seçim kutusunun işaretli olduğundan emin olun.

İpucu: Indexed View

2010-09-05T10:45:00.000+03:00

Indexed View' lerin, Query Optimizer tarafından uygun görüldüğü takdirde SQL Server 2005 ve üst versiyonlarının Enterprise Edition'ları tarafından otomatik olarak kullanılabileceğini biliyor muydunuz?

SQL Server 2005'in diğer Edition'ları için ise, Query Optimizer'ın Indexed View'leri kullanması için "NOEXPAND" Table Hint' ini kullanmanız gerekiyor.

Bir Database Snapshot' ı Silmek

2010-09-05T10:44:00.002+03:00

Normalde, kullanıcıların bağlı olduğu bir veritabanını doğrudan DROP DATABASE komutuyla silemezsiniz; fakat bu veritabanı eğer bir Database Snapshot ise, o zaman doğrudan "DROP DATABASE" gibi bir komutla kaç kullanıcı bağlı olursa olsun bu veritabanını silebilirsiniz. Burada dikkat edilmesi gereken ise, bu komutu çalıştıracak kullanıcının bu Database Snapshot' a o anda bağlantısı olmaması gerektiğidir. Aksi takdirde "Cannot drop database because it is currently in use." hatasını alırsınız.

Database Snapshot' tan dönmek

2010-09-05T10:44:00.001+03:00

Veritabanınızın Database Snapshot' ını kullanarak, herhangi bir nedenden dolayı veritabanınızı eski haline getirmek için Database Snapshot' ın alındığı ana geri dönebileceğinizi biliyor muydunuz?

Örneğin, aynı günün sabahı saat 9:00' da veritabanınızın Database Snapshot' ını oluşturdunuz diyelim ve saat 10:00' da veritabanınızda toplu bir güncelleştirme yapıldı ve bunun hatalı bir güncelleştirme olduğunu anladınız fakat elinizde ne yedek var ne de SQL Server bu işlemi geri almanıza izin vermiyor. İşte bunun gibi durumlarda "RESTORE DATABASE 'veritabanı_adı' FROM DATABASE_SNAPSHOT = 'database_snapshot_adı'" komutuyla veritabanınızı saat 9:00' daki haline döndürebilirsiniz.

Bu dönme işlemi boyunca ne Database Snapshot' ınız ne de veritabanınız kullanılabilir olmayacaktır, ayrıca ana veritabanınıza ait o anda sadece bir tane Database Snapshot olmalıdır; eğer birden fazla aynı veritabanına ait Database Snapshot varsa, sadece bir tane kalana kadar diğerleri silinmelidir.

SSMS: GO 'sayı'

2010-09-05T10:43:00.001+03:00

Query Editor' de bir komutu bir döngüye sokmak için GO komutunu kullanabileceğinizi biliyor muydunuz?

Örnek: "SELECT GetDate() GO 1000" komutu, GetDate() fonksiyonunun 1000 kere çalışmasını sağlayacaktır.

Sorgu çalıştırma süresi

2010-09-05T10:42:00.000+03:00

Bazen şöyle bir soru alıyorum: "Bir sorguyu Query Analyzer' da veya Query Editor' de çalıştırdığım zaman, çalışma süresi olarak en az saniyeyi görebiliyorum, süreyi milisaniye olarak nasıl görebilirim?"

Eğer bir sorgunun çalışma süresi, çalışırken derlenme ve optimizasyon için ne kadar CPU zamanı harcadığı gibi bilgileri pratik olarak görmek için SET STATISTICS TIME ON komutunu kullanabilirsiniz. Ayrıca bu komut, SSMS' teki Tools\Options->Query Execution->SQL Server->Advanced bölümünden varsayılan hale de getirilebilir.

DİKKAT: SSMS - Database Properties penceresi...

2010-09-05T10:41:00.002+03:00

SQL Server Management Studio 2008' deki Database Properties -> Files penceresini kullanarak bir veritabanının veri dosyalarında değişiklikler istediğinizde bunu bu pencereden yapmamanızı tavsiye ederim. Çünkü bu arayüzden yapılınca, SQL Server veritabanı dosyalarını Shrink etmeye çalışıyor. Bu da genelde, özellikle de üretim ortamında yapılıyorsa iyi bir şey değildir.

Bunun yerine, yine aynı pencereyi kullanarak istediğiniz değişiklikleri yapabilirsiniz; fakat OK tuşuna basmayın, bunun yerine pencerenin üst tarafındaki Script tuşunu kullanın ve işlemi Script' leyin ve Shrink komutlarını çıkartarak yapmak istediğiniz değişikliklere ait komutları Query Editor' de çalıştırın.

SQL Server Profiler

2010-09-05T10:41:00.001+03:00

Profiler' daki "Duration" alanındaki değerler, SQL Server 2005 ve daha sonrası için eğer istenirse mikrosaniye veya milisaniye olarak gösterilebiliyor (Tools->Options).

Eğer mikrosaniye olarak gösterilmesi için ayarlamazsanız örneğin Profiler' da "1694" gibi gördüğünüz bir değeri, bu Trace' i bir tabloya aktardığınızda "1694850" olarak göreceksiniz. Yani aslında sizin Tools->Options' tan yapacağınız ayar sadece arayüzde yeniden biçimlendirme yapar, verinin öyle kaydedilmesini sağlamaz. Veri her zaman mikrosaniye olarak kaydedilir. Bilginize ;)

SQL Server 2008 R2: Reporting Services

2010-09-05T10:40:00.001+03:00

SQL Server 2008 R2' dan itibaren Reporting Services, Windows Server 2003 ve Windows Server 2003 R2 Itanium versiyonlar için desteklenmeyecek.

Eğer SQL Server 2008 R2' nun Reporting Services bileşenini Itanium bir sunucuda kullanmak istiyorsanız, İşletim Sisteminizi Windows Server 2008 veya Windows Server 2008 R2 Itanium versiyonuna yükseltmeniz gerekmektedir.

Internal I/O request 0x4BD9EAE8: Op: Write, pBuffer: 0x05350000, Size: 983040, Position: 369629696, UMS: Internal: 0x103, InternalHigh: 0x0, Offset:

2010-09-05T10:39:00.000+03:00

HATA:
"Internal I/O request 0x4BD9EAE8: Op: Write, pBuffer: 0x05350000, Size: 983040, Position: 369629696, UMS: Internal: 0x103, InternalHigh: 0x0, Offset: 0x16081A00, OffsetHigh: 0x0, m_buf: 0x05350000, m_len: 983040, m_actualBytes: 0, m_errcode: 112, BackupFile: C:\xxx\veritabani_adi.bak"

AÇIKLAMA:
Yedek alma işlemi sırasında böyle bir hata ile karşılaşabilirsiniz.

ÇÖZÜM:
Ben bu sorunla karşılaştığımda, sorunun nedeni yedek alınmaya çalışılan diskte yeterli boşlukta yer olmayışıydı.

Eğer bu hata ile karşılaşırsanız tavsiyem, yedek alıyor olduğunuz diskte yeterli boş alanın olup olmadığından emin olmanızdır.

"RESTORE cannot process database 'veritabanı adı' because it is in use by this session. It is recommended that the master database be used when perfor

2010-09-05T10:38:00.000+03:00

HATA:
"RESTORE cannot process database 'veritabanı adı' because it is in use by this session. It is recommended that the master database be used when performing this operation."

AÇIKLAMA:
Log Shipping sisteminizdeki Restore Job' ında böyle bir hata ile karşılaşabilirsiniz.

ÇÖZÜM:
Ben bu hata ile, bir Log Shipping kurulumumuzun Secondary sunucusundaki Restore Job' ında karşılaştım.

Bu hata mesajını Restore Job' ının History' sinde gördüm. Yaptığım ilk iş, veritabanının SINGLE_USER modunda mı yoksa MULTI_USER modunda mı olduğunu kontrol etmekti. Yaptığım kontrol sonucu gördüm ki, veritabanı SINGLE_USER modundaydı. Bu ayarı aşağıdaki gibi bir kod ile MULTI_USER olarak değiştirdikten sonra bu hatadan kurtuldum.

USE [master]
GO
ALTER DATABASE [veritabanı adı] SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO

SQL Login'in şifresi ne zaman değiştirildi?

2010-09-05T10:37:00.000+03:00

Gün gelir lâzım olur da bir SQL Login'in şifresinin ne zaman değiştirildiğini öğrenmeniz gerekirse ne yaparsınız?

SELECT LOGINPROPERTY('kullanıcı adı', 'PasswordLastSetTime') komutunu kullanıp, ilgili kullanıcının şifresinin değiştirildiği zaman bilgisini ayrıntılı olarak görebilirsiniz.

Bir SQL Server 2005 Failover Cluster Bug'ı

2010-09-05T10:36:00.000+03:00

SQL Server 2005 Failover Clustering kurulumundan sonra, Cluster Administrator'dan SQL Server Resource Group'taki SQL Server Resource' unun Properties->Advanced penceresinde bulunan "Affect the group" seçim kutusu boş geliyor.

Halbuki bunun seçili olması gerekiyor. SQL Server 2005 SP3' te de durum aynı, bu sorun hâlâ düzeltilmiş değil. SQL Server 2000 ve 2008'de ise böyle bir sorun yok. Bu nedenle SQL Server 2005 Failover Clustering kurulumlarınızdan sonra, SQL Server Resource Group' u için "Affect the group" seçeneğini elle seçili hale getirmelisiniz.

SQL Server Failover Clustering' te Aktif Düğüm Hangisi?

2010-09-05T10:33:00.000+03:00

SQL Server 2005 ve üstü versiyonlarda SQL Server Failover Clustering' in aktif düğümünü, SELECT SERVERPROPERTY('ComputerNamePhysicalNetBios') komutuyla tespit edebilirsiniz.

SQL Server ve Oracle Golden Gate hakkında yazılar...

2009-12-27T11:38:00.001+02:00

Merhaba Arkadaşlar!

Şu anda çalışıyor olduğum banka, Online Reporting (Gerçek zamanlı) projeleri için "Oracle Golden Gate" ürününü kullanmaya karar verdi ve bu yönde yatırımlar yaptı. Bu ürünün yönetimi, bakımı, kurulumu vb. sorumlulukları bana ait. Bu nedenle bu ürünü önceden hiç bilmiyor olmama rağmen (hâlâ da iyi biliyorum gibi bir iddiam yok), geçen 3-4 aylık kullanım sürecinde birçok şey öğrendim. Bu konuda ITD isimli, Golden Gate' in distribütörlüğünü yapan firma ile de çalışıyoruz.

Zaman zaman bu ürünle ilgili sorunlar yaşadık ve hâlâ da yaşıyoruz. Sorun yaşadığımızda, ulu Google' ın bu sorunlar hakkında hiçbir şey bilmediğini gördüm. Ne yerli ne de yabancı herhangi bir kayıt, yazı vs. yok. Bunun nedenini, bu ürünü daha ziyade büyük şirketlerin kullanmasına (çünkü gerçekten maliyeti yüksek bir ürün) ve bu şirketlerin de bu ürünün distribütörleri ile bakım anlaşmaları olmasına bağlıyorum. Bu nedenle sorun çıktığında, doğrudan bakım anlaşması yapılan şirket aranıyor ve böylece Google vb. aradan çıkarılmış oluyor... Çalışıyor olduğum şirket de bir istisna değil.

Oracle Golden Gate' in Oracle Database gibi "platform free" olması ve birçok (10~) DBMS ürününü desteklemesi, bu ürünün SQL Server ile olan iş birliği hakkındaki olası bilgi paylaşımını daha da azaltıyor. Biz bu ürünü şirketimizde SQL Server ile birlikte kullanıyoruz ve bu konuda şirket içindeki Proses Talimatlarını da ben hazırlıyorum. Bu yazılarımı ve tecrübelerimi -her ne kadar küçük ve orta ölçekli şirketlerin bu yazılarımdan çok faydalanamayacağını biliyor olsam da- sizlerle de paylaşmak istedim.

Peki Golden Gate nedir? Golden Gate, aynen SQL Server Replication' ı gibidir ve TDM (Transactional Data Management) ürünüdür. Hatta SQL Server 2005 SP2, CU6 öncesi versiyonlar için birebir SQL Server Replication bileşenlerini kullanır. Yine aynen SQL Server Replication topolojileri gibi çeşitli topolojileri vardır. Tek yönlü veya çift yönlü veri aktarımı (replikasyon) yapabilir. Tabii bu noktada akla gelen soru "peki farkı nedir? neden SQL Server Replication değil de Oracle Golden Gate?". Bu sorunun özet yanıtı şu: Oracle Golden Gate ürününün topolojileri çok daha esnek, bu nedenle veri aktarımı çok daha hızlı oluyor. Bununla birlikte, kritik veritabanınızın Transaction Log dosyasının dolmasına neden olmayacak şekilde ayarlanabiliyor (bunun bazı durumlarda doğrulup kayı yok, bu konuya ileride, başka yazılarımda ayrıca değineceğim çünkü çok önemli). LSN' i kaçırdığı zaman ise, ilgili kayıtları Transaction Log yedek dosyalarından okuyabiliyor... Bunların hiçbirisini SQL Server Replication yapamıyor maalesef. Ayrıca (adı bende kalsın) bu konuda Türkiye' de uzman olan ve Microsoft için çalışıyor olan bir arkadaşım, bir MVP toplantısında yaptığımız muhabbette Golden Gate ürününün SQL Server Replication' dan çok daha hızlı olduğunu ve bu ürünü Oracle satın almadan önce (ki bu satın alma olayı bildiğim kadarıyla 2-3 ay önce oldu) Online Reporting ihtiyacı olan şirketlere kendilerinin önerdiğini iletmişti bana.

Bu kapsamda, Golden Gate' in Windows Server' da kurulumu, SQL Server 2005 ve Golden Gate ile Partition Switch işleminin nasıl yapılabileceği, kopan bir Golden Gate senkronizasyonunun nasıl tekrar sağlanabileceği, yeni tabloların replikasyona nasıl dahil edilebileceği, Golden Gate Best Practices gibi çeşitli konularda yazılar yazıyor olacağım. Umarım bir gün birilerinin işine yarar.

Ekrem Önsoy

"Failed to install and configure assemblies C:\Program Files\Microsoft SQL Server\90\DTS\Tasks\Microsoft.SqlServer.MSMQTask.dll in the COM+ catalog. E

2009-12-27T11:36:00.000+02:00

HATA MESAJI:
"Failed to install and configure assemblies C:\Program Files\Microsoft SQL Server\90\DTS\Tasks\Microsoft.SqlServer.MSMQTask.dll in the COM+ catalog. Error: -2147467259 Error message: Unspecified error Error description: Error HRESULT E_FAIL has been returned from a call to a COM component."

AÇIKLAMA:
Sorun, Microsoft.SqlServer.MSMQTask.dll' in İşletim Sistemine kayıt olamamasından kaynaklanıyor. Özellikle 64Bit Integration Services kurmaya çalışırken, sistem üzerinde 32Bit .Net Framework bileşenleri varsa bu hatayla karşılaşılabiliyor.

ÇÖZÜM:
Sorunu çözmek için aşağıdaki gibi Microsoft.SqlServer.MSMQTask.dll’i unregister ve reregister yapabilirsiniz.

Unregister etmek için:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>regsvcs /u "C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Tasks\Microsoft.SqlServer.MSMQTask.dll"

Microsoft (R) .NET Framework Services Installation Utility Version 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. Uninstallation of assembly 'C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Tasks\Microsoft.SqlServer.MSMQTask.dll' succeeded.

Register etmek için:
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727>regsvcs.exe "C:\Program Files\Microsoft SQL Server\90\DTS\Tasks\Microsoft.SqlServer.MSMQTask.dll"

Microsoft (R) .NET Framework Services Installation Utility Version 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved.

"The SQL server specified in SSIS service configuration is not present or is not available. This might occur when there is no default instance of SQL

2009-12-27T11:35:00.000+02:00

HATA MESAJI:
"The SQL server specified in SSIS service configuration is not present or is not available. This might occur when there is no default instance of SQL Server on the computer. For more information, see the topic "Configuring the Integration Services Service" in Server 2005 Books Online."

AÇIKLAMA:
SSMS’ ten SSIS servisine bağlanıp MSDB altındaki paketlere bakmak istediğinizde bu hata ile karşılaşabilirsiniz.

ÇÖZÜM:
http://msdn.microsoft.com/en-us/library/ms137789.aspx

"SystemOutOfMemory"

2009-12-27T11:34:00.000+02:00

HATA MESAJI:
SystemOutOfMemory

AÇIKLAMA:
Örneğin SQL Server Management Studio' da bir SP çalıştırdığınızda Messages penceresinde böyle bir hata mesajıyla karşılaşabilirsiniz.

ÇÖZÜM:
Bu sorunun yaşandığı durumda, çalıştırılan SP' de yapılan her işlem için bir SELECT sorgusu kullanıldığını gördüm ve sonuç penceresinde binlerce sonuç dönüyordu. SSMS’ teki Messages penceresi de bu kadar çok mesajı depolayamadığından System.SystemOutOfMemory hatası alınıyordu. Yani sorun aslında SSMS’ ten kaynaklanıyordu...

Bu sorunu aşmak için gereksiz SELECT cümleciklerini kaldırabilirsiniz. Ayrıca SET NOCOUNT ON komutunu kullanabilirsiniz.

"The database could not be exclusively locked to perform the operation"

2009-12-27T11:33:00.000+02:00

HATA MESAJI:
The database could not be exclusively locked to perform the operation

AÇIKLAMA:
Bir veritabanında işlem yaparken (meselâ veritabanın adını değiştirmek veya Collation ayarını değiştirmek gibi...) böyle bir hata ile karşılaşabilirsiniz.

ÇÖZÜM:
Bu tarz işlemleri yapmak için veritabanına bağlı başka bir kullanıcı olmaması gerekiyor. Bunu da, aşağıdaki gibi bir komut bloğu ile sağlayabilirisiniz:

ALTER DATABASE Veritabanim SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
USE Veritabanim GO sp_renamedb N'Veritabanim', N'Veritabanim_Eski'
GO
ALTER DATABASE Veritabanim_Eski SET MULTI_USER GO

"The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 1 (YYYY-MM-DDTHH:MM:SS). Exception Messa

2009-12-27T11:32:00.000+02:00

HATA MESAJI:
"The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 1 (YYYY-MM-DDTHH:MM:SS). Exception Message: Could not write to temp attachment file. (There is not enough space on the disk)"

AÇIKLAMA:
Database Mail kullanarak ekli bir eposta göndermeye çalışırken böyle bir hata ile karşılaşabilirsiniz.

ÇÖZÜM:
Eğer Sistem Diskinizde (İşletim Sisteminin çalıştığı disk) yeterince yer yoksa böyle bir hata ile karşılaşırsınız. Sistem Diskinizde (ki bu genelde C:' dir) yeterince boş yer olduğundan emin olun.

Dedicated Administrator Connection Portu

2009-11-01T13:25:00.000+02:00

Merhaba arkadaşlar,

Her zaman başınıza gelebilecek birşey değiş, fakat geçenlerde benim başıma geldi ve açıkçası bu konuda bir kaynak bulmakta zorlandım. Hatta bulamadım, fakat biraz kurcalayınca çözümü kendim buldum.

Dedicated Administrator Connection (DAC) Portunun nereden ve neden değiştirilebileceği hiç aklınıza geldi mi? Geçenlerde yeni kurduğum bir SQL Server 2008 Instance' ının DAC' nin portunun standardizasyon ve Güvenlik Duvarı tarafındaki Kural tanımları için değiştirmem istendi.

İlk etapta aklıma birşey gelmedi, çünkü ne SQL Server Configuration Manager' da ne de başka bir arayüzde bu ayarla ilgili bir bölüm gördüğümü hatırlamamıştım. Tabii ki yapılabilecek en mantıklı şey olarak hemen Google' a sordum. Tam bir hayal kırıklığıydı, konu hakkında neredeyse hiçbir bilgiye ulaşamadım. Kim bilir, belki de ben yanlış kelimeleri arattım?

Neyse, daha fazla gevezelik etmeden çözümü ve konuyu açıklamaya başlayayım.

Öncelikle, her SQL Server 2005 ve üzeri Instance' ına, kurulum esnasında bir DAC portu atanır. SQL Server Instance' ınızın DAC portunu, SQL Error Log' unun başlangıcında aşağıdaki örnekte verilen satırdaki gibi görebilirsiniz:

SQL Error Log' dan örnek satır:
Dedicated admin connection support was established for listening locally on port 49486.
Server is listening on [ 127.0.0.1 49486].

DAC portunun değiştirilmesi gerektiği söylendiğinde aklıma birşeyin gelmemesi normalmiş. Çünkü gerçekten de aradım taradım ve bu ayarın nereden değiştirilebileceğini gösteren herhangi bir yazı, resim, arayüz vs. bulamadım.

Aklıma, bu tür ayarların Kayıt Defterinde (Registry) saklandığı geldi ve DAC' ye atanan portu Kayıt Defterinde arattım ve aşağıdaki anahtara ulaştım:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.S08\MSSQLServer\SuperSocketNetLib\AdminConnection\Tcp

Eğer bu anahtarı elle değiştirirseniz ve SQL Server servisini durdurup tekrar başlatırsanız, yeni DAC portunuzun artık sizin atadığınız port olduğunu göreceksiniz. DAC portu, Dynamic bir port değildir. Bu nedenle her SQL Server servisinin kapanıp açılmasıyla değişmez. Hangi port belirtilmişse, hep o port kullanılmaya çalışılır.

"[Microsoft][ODBC SQL Server Driver]Unspecified error occured on SQL Server. Connection may have been terminated by the server. OS Error: 0"

2009-11-01T13:24:00.000+02:00

HATA MESAJI:
"[Microsoft][ODBC SQL Server Driver]Unspecified error occured on SQL Server. Connection may have been terminated by the server. OS Error: 0"

AÇIKLAMA:
SQL Server' a bağlantı kurduktan hemen sonra veya birkaç dakika sonra bu hata mesajını alarak kopma sorunları yaşayabilirsiniz.

ÇÖZÜM:
Bu sorun, Windows Server 2003 ile ilgili bir sorundur. Sorunu çözmek için şu KB’ deki Fix’ i kullanabilirsiniz:

“http://support.microsoft.com/kb/948496”

"DROP DATABASE statement cannot be used inside a user transaction"

2009-11-01T13:23:00.000+02:00

HATA MESAJI:
"DROP DATABASE statement cannot be used inside a user transaction"

AÇIKLAMA:
“DROP DATABASE” komutuyla bir veritabanını silmeye çalıştığınızda bu hata mesajını alabilirsiniz.

ÇÖZÜM:
Bu hata mesajını alıyorsanız, bu komutu çalıştırdığınız oturumdaki (Session) Transaction açık kalmıştır. ROLLBACK veya COMMIT komutlarını kullanarak bu Transaction’ ı sonlandırın veya başka bir oturum açın ve “DROP DATABASE” komutunu tekrar çalıştırın.