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.
Microsoft SQL Server ve Microsoft SQL Server ile ilgili diğer uygulamalar, araçlar ve haberlerle ilgili Türkçe içeriği bu günlükte bulabilirsiniz.
17 Ekim 2010 Pazar
5 Ekim 2010 Salı
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.
"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.
4 Ekim 2010 Pazartesi
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
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
1 Ekim 2010 Cuma
[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
"[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'
"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)
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)
Kaydol:
Kayıtlar (Atom)