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

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.

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

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

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

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

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)

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)".

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

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

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ı"

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

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ı!

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.

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

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ı

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

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

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.

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ı!

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

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

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.

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

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

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

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.

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

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

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

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!

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"

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)

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)

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

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

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

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

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

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ı'

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

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

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

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

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:

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

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?

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'ı

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?

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