"An error occurred while processing the log for database ‘veritabanı_adı’ - SQL Server Assertion: File: , line=1905 - Stack Signature for the dump is

HATA MESAJI:
"An error occurred while processing the log for database ‘veritabanı_adı’ - SQL Server Assertion: File: , line=1905 - Stack Signature for the dump is 0xC121BB7C "

AÇIKLAMA:
SQL Server Error Log dosyalarında böyle hata mesajlarıyla karşılaşabilirsiniz.

Benim yaşadığım durumda, bu hata mesajları Transaction Log dosyası RESTORE edilirken ortaya çıkmıştı ve nedeni ise veri dosyalarının (database data files) bulunduğu diskte yeteri kadar yer kalmayışıydı.

ÇÖZÜM:
Veritabanı veri ve Transaction Log dosyalarının bulunduğu disklerde yeteri kadar yer olduğundan emin olun.

"SQL Server blocked access to procedure 'dbo.sp_set_sqlagent_properties' of component 'Agent XPs' because this component is turned off as part of the

HATA MESAJI:
"SQL Server blocked access to procedure 'dbo.sp_set_sqlagent_properties' of component 'Agent XPs' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'Agent XPs' by using sp_configure. For more information about enabling 'Agent XPs', see "Surface Area Configuration" in SQL Server Books Online. (Microsoft SQL Server, Error: 15281)"

AÇIKLAMA:
SQL Server sunucunuzda Replication kurmak isterken böyle bir hata mesajı ile karşılaşabilirsiniz. Örneğin ben bu hata mesajıyla Distributor' ü yapılandırmak için Distributor Configuration penceresini açmak istediğimde karşılaşmıştım...

ÇÖZÜM:
Aslında hata mesajında ne yapmanız gerektiği belirtilmiş, fakat yine de bu hata mesajının daha anlaşılabilir olması için bir açıklama yapmak istedim.

Agent XPs adındaki SQL Server Extended Stored Procedure' leri etkinleştirmek için öncelikle SQL Server Instance' ınıza SQL Server Management Studio (GUI) veya SQLCMD (Komut istemcisinden) ile bağlanmalı ve aşağıdaki komutları çalıştırmalısınız.

USE MASTER
GO

sp_configure 'show advanced options', 1;
GO

RECONFIGURE;
GO

sp_configure 'Agent XPs', 1;
GO

RECONFIGURE;
GO

sp_configure 'show advanced options', 0;
GO

RECONFIGURE;
GO

"SQL Server replication requires the actual server name to make a connection to the server. Connections through a server alias, IP address, or any oth

HATA MESAJI:
"SQL Server replication requires the actual server name to make a connection to the server. Connections through a server alias, IP address, or any other alternate name are not supported. Specify the actual server name, 'xxx-6J02WD\SQL2005'. (Replication.Utilities)"

AÇIKLAMA:
SQL Server sunucunuzda Replication kurmak isterken böyle bir hata mesajı ile karşılaşabilirsiniz. Aslında bu hata mesajıyla başka bir işlem yapmaya çalışırken de karşılaşabilirsiniz...

Sorun, sunucu adının olması gerektiğinden farklı olmasından kaynaklanıyordu.

Biliyorum, açıklamam gerekiyor =)

SELECT SERVERPROPERTY('SERVERNAME')

ve

SELECT @@SERVERNAME

komutları ideal dünyada aynı sonuçları döndürür. Fakat benimki gibi ideal olmayan bir dünyada yaşıyorsanız duruma göre farklı sonuçlar döndürebilirler. Ama şunu söyleyebilirim ki, SELECT SERVERPROPERTY('SERVERNAME') karşılaştığım her durumda doğru sonucu döndürüyordu. Bu iki komut da belli ki farklı yerlere bakıyorlar, tam olarak nereye baktıklarını ben de bilemiyorum...

Peki... Ben neden bunlardan bahsettim? Çünkü, eğer yukarıda Mesaj Başlığı bölümünde yazan mesaj ile karşılaştıysanız, büyük bir ihtimalle bu iki komutu çalıştırdığınızda farklı sonuçlar aldığınızı göreceksiniz.

Örneğin benim durumumda SELECT SERVERPROPERTY('SERVERNAME') komutunu çalıştırdığımda dönen sonuç şöyleydi: "EKREM-PC\SQL2005" (tabii ki bu değildi); fakat SELECT @@SERVERNAME komutunu çalıştırdığımda aldığım sonuç xxx-6J02WD\SQL2005 idi. Bunun nedeni ise, SQL Server Instance' ını kurduktan sonra bilgisayar adını değiştirmemdi.

ÇÖZÜM:
Böyle bir durumda yapmanız gereken ise şudur, öncelikle SQL Server' ınızda kayıtlı olan yerel bilgisayar adını aşağıdaki komut ile silersiniz:

sp_dropserver 'xxx-6J02WD\SQL2005'
GO

Daha sonra doğru yerel bilgisayar adını aşağıdaki komut ile eklersiniz:

sp_addserver 'EKREM-PC\SQL2005', 'Local'
GO

Bu işlemleri yaptıktan sonra SQL Server Database Engine servisini SQL Server Configuration Manager' dan veya Services MMC' den durdurup yeniden başlatırsınız.

Artık SELECT SERVERPROPERTY('SERVERNAME') komutunu da çalıştırsanız SELECT @@SERVERNAME komutunu da çalıştırsanız aynı sonucu alırsınız ve Mesaj Başlığında belirtilen hata mesajıyla veya türevleriyle artık karşılaşmazsınız.

"Database '' is in warm-standby state (set by executing RESTORE WITH STANDBY) and cannot be backed up until the entire load sequence i

HATA MESAJI:
"Database '' is in warm-standby state (set by executing RESTORE WITH STANDBY) and cannot be backed up until the entire load sequence is completed."

AÇIKLAMA:
Veritabanınızın yedeğini alırken böyle bir hata mesajı ile karşılaşabilirsiniz.

ÇÖZÜM:
Eğer veritabanınız örneğin bir Log Shipping senaryosunda Secondary veritabanıysa veya bir Database Mirroring senaryosunda Mirror veritabanıysa, yani özetle eğer "Restoring..." dumundaysa, o zaman bu veritabanının yedeğini BACKUP DATABASE komutuyla alamazsınız.

Veritabanınızın yedeğini almak için Primary veritabanınızın yedeğini alın.

"BackupIoRequest::WaitForIoCompletion: read failure on backup device ''. Operating system error 38(Reached the end of the fil

HATA MESAJI:
"BackupIoRequest::WaitForIoCompletion: read failure on backup device ''. Operating system error 38(Reached the end of the file.)."

"Internal I/O request 0x67BAE6D8: Op: Read, pBuffer: 0x0F410000, Size: 65536, Position: 60536320, UMS: Internal: 0x103, InternalHigh: 0x0, Offset: 0x39BB600, OffsetHigh: 0x0, m_buf: 0x0F410000, m_len: 65536, m_actualBytes: 0, m_errcode: 38, BackupFile: "

"The backup data in '' is incorrectly formatted. Backups cannot be appended, but existing backup sets may still be usable.

AÇIKLAMA:
Transaction Log yedeğinizi RESTORE etmeye çalışırken (tek tek veya Log Shipping ile) böyle hata mesajlarıyla karşılaşabilirsiniz.

ÇÖZÜM:
Bu sorun ile, Log Shipping' te karşılaşmıştım. Bu sorunu, Secondary veritabanına yeni Log yedeklerinin Restore edilmediğinde farkettim. SQL Server Error Log dosyasını incelediğimde bu hata mesajlarıyla karşılaştım.

Nedenini kesin olarak bilemediğim bir sebepten dolayı bu hata mesajının oluşmasına neden olan Transaction Log yedeği, Secondary sunucuya ulaştığında bir şekilde bozulmuş (Corrupt). Aynı dosyanın doğru halini tekrar Secondary sunucusuna gönderdiğimde Log Shipping kaldığı yerden başarılı bir şekilde çalışmaya devam etti, bilginize...