4 Şubat 2008 Pazartesi

"Error: 602: Could not find row in sysindexes for database ID 8, object ID 1, index ID 1. Run DBCC CHECKTABLE on sysindexes."

HATA MESAJI:
"Error: 602: Could not find row in sysindexes for database ID 8, object ID 1, index ID 1. Run DBCC CHECKTABLE on sysindexes."

AÇIKLAMA:
Bu hatayı iki durumda alabilirsiniz,
1- SQL Server 2000 Instance' ınıza iliştirmek istediğiniz veritabanı, bir SQL Server 2005 (veya üstü) Instance' ında oluşturulmuşsa,

2- Bir SQL Server 2000 Instance' ında oluşturulmuş veritabanınızı, bir SQL Server 2005 Instance' ına iliştirdikten ve ayırdıktan sonra tekrar SQL Server 2000 Instance' ınıza eklemeye çalıştığınızda.

Yani bu durumda, veritabanınızı bir SQL Server 2000 Instance' ınıza iliştiremezsiniz artık. Çünkü yapısı SQL Server 2005 Instance' ına göre ayarlanmıştır.


ÇÖZÜM:
Maalesef bunun için bir çözümüm yok, sadece nedenini bilin diye yazdım bu yazıyı.

SQL Server 2008: "Declare" ile bir değişken tanımlarken...

SQL Server 2008' de, "Declare" ile bir değişken tanımlarken aynı satırda o değişkene veri de atayabileceğiz! Bunu, SQL Server' ın önceki versiyonlarında yapamıyorduk. Ancak değişkeni tanımladıktan sonra başka bir satırda "SET" komutunu kullanarak değişkene veri atayabiliyorduk.

Peki bunu SQL Server 2008' de nasıl yapacağız? Meselâ şöyle:

"Declare @Ulke_Sayisi INT = (SELECT Count(*) FROM [dbo].[Ulkeler])"

Query Editor ile SSMS-Object Explorer' ın yakın dostluğu

SQL Server Management Studio' da, Object Explorer' daki öğeleri fare ile tutup Query Editor' deki metinlerinize ekleyebileceğinizi biliyor muydunuz? Meselâ SSMS' i açın ve bir veritabanı içerisindeki bir tablonun altında bulunan "Columns" öğesini fare ile tutun ve Query Editor penceresine taşıyıp ne kadar kullanışlı olabileceğini kendiniz görün!

"The log or differential backup cannot be restored because no files are ready to rollforward."

HATA MESAJI:
"The log or differential backup cannot be restored because no files are ready to rollforward."

AÇIKLAMA:
Bu hata mesajını bir kaç yedek dosyasını arka arkaya açmak istediğinizde alabilirsiniz.

ÇÖZÜM:
SQL Server' da yedek dosyanızdan geri dönmek istediğinizde ve eğer birden fazla yedek açacaksanız (Restore) o zaman ilk yedekten başlayıp en sondan bir önceki yedeğe kadar RESTORE komutuyla birlikte WITH NORECOVERY anahtarını da kullanmanız gerekir.

Meselâ "Sirketim" isminde bir veritabanınız olduğunu varsayın. Haftada bir kere tam (FULL), diğer günler de fark (DIFFERENTIAL) yedeğini alıyorsunuz.

Pazar = FULL
Pazartesi = DIFFRENTIAL
Salı = DIFFRENTIAL
Çarşamba = DIFFRENTIAL
Perşembe = Veritabanınız bozuldu ve eskisini silip yedekten dönebildiğiniz kadar dönmeye çalışacaksınız.

Şu yolu takip edersiniz:
1- RESTORE DATABASE [Sirketim] FROM DISK = N'C:\test\Sirketim.bak' WITH FILE = 1, NORECOVERY
2- RESTORE DATABASE [Sirketim] FROM DISK = N'C:\test\Sirketim.bak' WITH FILE = 4, RECOVERY

Dikkat ederseniz ilk adımda RESTORE işlemiyle veritabanımın yedeğini açarken "NORECOVERY" anahtarını kullandım. Bu, şu anlama geliyor: "Bu, açacağım son yedek değil, bundan sonra daha açacaklarım var." İşte bu nedenle en son açacağımız yedeğe kadar "NORECOVERY" anahtarını kullanmalıyız.

En son yedekte ise gördüğünüz gibi "RECOVERY" anahtarını kullandım. Bu da şu anlama gelir: "Bundan sonra artık açacağım herhangi bir yedek yok. Bu nedenle artık dosyamı kullanılabilir hale getir".

Evet, "kullanılabilir hale getir." diyorum, çünkü bir yedeği "NORECOVERY" anahtarı ile açarsanız o veritabanını kullanamazsınız. Ne sorgulayabilirsiniz ne de yeni bir kayıt ekleyip değiştirebilirsiniz.

"NORECOVERY" anahtarına alternatif olarak "STANDBY" anahtarını da kullanabilirsiniz. İşlev olarak aynı işlevi görecektir, fakat "STANDBY" anahtarının "NORECOVERY" anahtarına göre olan farkuı şudur: Bir veritabanını "STANDBY" anahtarını kullanarak açarsanız, o veritabanının üstüne daha başka yedekler de açabilirsiniz. Bunun yanında o veritabanını "NORECOVERY" nin aksine, sorgulayabilirsiniz de. Fakat sadece SELECT komutuyla sorgulayabilirsiniz, o kadar. Yani yeni bir kayıt ekleyemez, veri değiştiremez veya silemezsiniz. Ayrıca STANDBY ile açtığınız veritabanının üstüne başka bir yedek daha açtığınızda, o anda veritabanına bağlı olan kullanıcılar otomatik olarak veritabanından dışarı atılırlar. Açma işlemi bittikten sonra tekrar veritabanını sorgulayabilirler elbette.

"The preceding restore operation did not specify WITH NORECOVERY or WITH STANDBY. Restart the restore sequence, specifying WITH NORECOVERY or WITH STA

HATA MESAJI:
"The preceding restore operation did not specify WITH NORECOVERY or WITH STANDBY. Restart the restore sequence, specifying WITH NORECOVERY or WITH STANDBY for all but the final step."

AÇIKLAMA:
Bu hata mesajını bir kaç yedek dosyasını arka arkaya açmak istediğinizde alabilirsiniz.

ÇÖZÜM:
SQL Server' da yedek dosyanızdan geri dönmek istediğinizde ve eğer birden fazla yedek açacaksanız (Restore) o zaman ilk yedekten başlayıp en sondan bir önceki yedeğe kadar RESTORE komutuyla birlikte WITH NORECOVERY anahtarını da kullanmanız gerekir.

Meselâ "Sirketim" isminde bir veritabanınız olduğunu varsayın. Haftada bir kere tam (FULL), diğer günler de fark (DIFFERENTIAL) yedeğini alıyorsunuz.

Pazar = FULL
Pazartesi = DIFFRENTIAL
Salı = DIFFRENTIAL
Çarşamba = DIFFRENTIAL
Perşembe = Veritabanınız bozuldu ve eskisini silip yedekten dönebildiğiniz kadar dönmeye çalışacaksınız.

Şu yolu takip edersiniz:
1- RESTORE DATABASE [Sirketim] FROM DISK = N'C:\test\Sirketim.bak' WITH FILE = 1, NORECOVERY
2- RESTORE DATABASE [Sirketim] FROM DISK = N'C:\test\Sirketim.bak' WITH FILE = 4, RECOVERY

Dikkat ederseniz ilk adımda RESTORE işlemiyle veritabanımın yedeğini açarken "NORECOVERY" anahtarını kullandım. Bu, şu anlama geliyor: "Bu, açacağım son yedek değil, bundan sonra daha açacaklarım var." İşte bu nedenle en son açacağımız yedeğe kadar "NORECOVERY" anahtarını kullanmalıyız.

En son yedekte ise gördüğünüz gibi "RECOVERY" anahtarını kullandım. Bu da şu anlama gelir: "Bundan sonra artık açacağım herhangi bir yedek yok. Bu nedenle artık dosyamı kullanılabilir hale getir".

Evet, "kullanılabilir hale getir." diyorum, çünkü bir yedeği "NORECOVERY" anahtarı ile açarsanız o veritabanını kullanamazsınız. Ne sorgulayabilirsiniz ne de yeni bir kayıt ekleyip değiştirebilirsiniz.

"NORECOVERY" anahtarına alternatif olarak "STANDBY" anahtarını da kullanabilirsiniz. İşlev olarak aynı işlevi görecektir, fakat "STANDBY" anahtarının "NORECOVERY" anahtarına göre olan farkuı şudur: Bir veritabanını "STANDBY" anahtarını kullanarak açarsanız, o veritabanının üstüne daha başka yedekler de açabilirsiniz. Bunun yanında o veritabanını "NORECOVERY" nin aksine, sorgulayabilirsiniz de. Fakat sadece SELECT komutuyla sorgulayabilirsiniz, o kadar. Yani yeni bir kayıt ekleyemez, veri değiştiremez veya silemezsiniz. Ayrıca STANDBY ile açtığınız veritabanının üstüne başka bir yedek daha açtığınızda, o anda veritabanına bağlı olan kullanıcılar otomatik olarak veritabanından dışarı atılırlar. Açma işlemi bittikten sonra tekrar veritabanını sorgulayabilirler elbette.

"System.Data.SqlClient.SqlError: The backup set holds a backup of a database other than the existing 'veritabanı_adı' database. (Microsoft.SqlServer.S

HATA MESAJI:
"System.Data.SqlClient.SqlError: The backup set holds a backup of a database other than the existing 'veritabanı_adı' database. (Microsoft.SqlServer.Smo)"

AÇIKLAMA:
Eğer işlem yaptığınız SQL Server Instance' ınızda açmak (Restore) için belirttiğiniz veritabanı adında bir veritabanı zaten varsa ve açmak istediğiniz veritabanından farklı bir veritabanıysa bu hatayı alırsınız.

ÇÖZÜM:
Meselâ kullandığınız SQL Server Instance' ında "Aksu" isminde bir veritabanınız var. Bir de "Kartel" veritabanına ait yedek dosyanız (*.bak) var, eğer bu yedek dosyasını SQL Server Instance' ınızda "Aksu" veritabanı adını kullanarak açmaya çalışırsanız bu hatayı alırsınız çünkü ikisi de farklı veritabanlarıdır.

Bu nedenle açmaya çalıştığınız "Kartel" veritabanının yedeği için ya "Kartel" ismini veritabanı adı olarak kullanın, ya da o anda çalıştığınız SQL Server Instance' ında varolmayan bir veritabanı ismi kullanın.

"Unable to start mail session (reason: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException: Mail configuration information could not b

HATA MESAJI:
"Unable to start mail session (reason: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException: Mail configuration information could not be read from the database. > System.Data.SqlClient.SqlException: profile name is not valid"

AÇIKLAMA:
Bu hatayı habergrubundan bir kullanıcının aldığını gördüm ve arşivlemek istedim. Sözkonusu kullanıcı bir Mail Profile ve Account oluşturmuş. Test postası da gönderebildiğini söylüyor. Fakat bu hesabı SQL Server Agent' ta kullanmak istediği zaman bu hatayı alıyor.

SQL Server Agent' ın özelliklerindeki Alert System' dan Mail Profile' ı Enable etmesini tavsiye etmiştim. Bunu da kontrol etmiş ve bu ayar da tammış. Sorunun çözümü ise çok ilginç.

ÇÖZÜM:
Sorunu yaşayan kişi Microsoft' ta bir "Case" açtığını söyledi ve ona çözüm olarak şunu önermişler:
- Surface Area Configuration' dan Database Mail' i Disable durumuna getir,
- SQL Server Agent Servisini durdur ve tekrar başlat,
- Surface Area Configuration' dan Database Mail' i Enable durumuna getir.

Çözüm bu ve işe yaramış.

Olur ya bir gün sizin veya benim de işime yarayabilir.

"An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that

HATA MESAJI:"An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.) (Microsoft SQL Server, Error: 10060)"

AÇIKLAMA:
Ben bu hata mesajı ile karşılaştığımda bir Alias kullanarak bir sanal makinedeki SQL Server Instance' ıma bağlanmaya çalışıyordum.

Alias' taki Sunucu ve SQL Server Instance adı doğruydu, fakat port numarası yanlıştı.

ÇÖZÜM:
Bağlanmaya çalıştığınız SQL Server Instance' ının port numarasının doğru olduğundan emin olun. Port numarası ayarları için SQL Server Configuration Manager' ı kullanabilirsiniz.

Benim durumumda Alias' taki port numarasını düzeltince sorun çözüldü.

"An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that

HATA MESAJI:
"An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: TCP Provider, error: 0 - No such host is known.) (Microsoft SQL Server, Error: 11001)"

AÇIKLAMA:
Varolmayan bir SQL Server sunucusuna bağlanmaya çalıştığınızda bu hatayı alırsınız.

Bununla ne demek istiyorum? Şunu, meselâ başka bir sanal veya fiziksel sunucudaki SQL Server Instance' ına bağlanmak için SQL Server Configuration Manager' da bir Alias oluşturdunuz. Bağlanmak istediğiniz SQL Server sunucusunun adı "Sunucum" olsun. Fakat Alias' ı ayarlarken "Server" kısmına "Sunucum" yazacağınıza "Sunucu" yazdınız. Bu durumda ağınızda "Sunucu" isminde bir sunucu olmadığından yukarıdaki hata mesajını alırsınız.

ÇÖZÜM:
Sanırım bu bölüme pek gerek kalmadı, ama ben gene de Alias' ta veya Connection String' te veya GUI' yi kullanırken doğru sunucu adını kullandığınızdan emin olun demeden geçemeyeceğim.