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)