HATA MESAJI:
"The application failed to initialize properly (0xc0000135). Click on OK to terminate the application."
AÇIKLAMA:
SQL Server 2008' in Setup.exe' sini çalıştırdığınızda böyle bir hata mesajıyla karşılaşabilirsiniz.
ÇÖZÜM:
Bunun nedeni, sisteminize daha önceden .Net Framework 3.5' in yüklenmemiş olmasıdır.
Bu sorunu aşmak için ilk önce .Net Framework 3.5' i yükleyin (eğer yoksa Microsoft Download' tan da indirebilirsiniz), daha sonra Setup.exe' yi çalıştırmayı tekrar deneyin.
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.
16 Ağustos 2009 Pazar
"While acting as a mirroring partner for database 'veritabanı_adı', server instance 'EKREM-PC\SQL2008' encountered error 948, status 2, severity 20. D
HATA MESAJI:
"While acting as a mirroring partner for database 'veritabanı_adı', server instance 'EKREM-PC\SQL2008' encountered error 948, status 2, severity 20. Database mirroring will be suspended. Try to resolve the error and resume mirroring."
AÇIKLAMA:
İki farklı versiyon SQL Server Instance' ı arasında Database Mirroring yaparsanız, Automatic veya Manual Failover olduğunda böyle bir hata mesajıyla karşılaşabilirsiniz.
ÇÖZÜM:
Database Mirroring için, Database Mirroring tasarımınızdaki Principal ve Mirror Sunucularının Instance Versiyon ve Edition' ları aynı olmalıdır.
Database Mirroring için SQL Server' ın Standard veya Enterprise Edition sürümüne ihtiyacınız var. Eğer bir tasarım yapacaksanız, o zaman bu tasarımdaki Principal ve Mirror sunucuların ikisi de ya Standard Edition olmalı ya da Enterprise Edition. Ayrıca iki sunucu Instance' ına da aynı Servis Paketleri ve Cumulative Update' ler uygulanmalı. Bir Instance 2005, diğeri de 2008 olamaz. Yoksa böyle bir hata mesajıyla karşılaşırsınız.
Bununla birlikte, Mirror sunucudaki veritabanı da "Suspect" durumuna geçer.
Not:
Örneğin bir Instance' ı 2005, diğerini de 2008 olarak kurmayı denerseniz SQL Server buna kızmayacaktır ve izin verecektir, fakat Failover yaptığınızda bu hata mesajıyla (veya benzeriyle, çünkü versiyonlar farklı olabilir) karşılaşacaksınız.
"While acting as a mirroring partner for database 'veritabanı_adı', server instance 'EKREM-PC\SQL2008' encountered error 948, status 2, severity 20. Database mirroring will be suspended. Try to resolve the error and resume mirroring."
AÇIKLAMA:
İki farklı versiyon SQL Server Instance' ı arasında Database Mirroring yaparsanız, Automatic veya Manual Failover olduğunda böyle bir hata mesajıyla karşılaşabilirsiniz.
ÇÖZÜM:
Database Mirroring için, Database Mirroring tasarımınızdaki Principal ve Mirror Sunucularının Instance Versiyon ve Edition' ları aynı olmalıdır.
Database Mirroring için SQL Server' ın Standard veya Enterprise Edition sürümüne ihtiyacınız var. Eğer bir tasarım yapacaksanız, o zaman bu tasarımdaki Principal ve Mirror sunucuların ikisi de ya Standard Edition olmalı ya da Enterprise Edition. Ayrıca iki sunucu Instance' ına da aynı Servis Paketleri ve Cumulative Update' ler uygulanmalı. Bir Instance 2005, diğeri de 2008 olamaz. Yoksa böyle bir hata mesajıyla karşılaşırsınız.
Bununla birlikte, Mirror sunucudaki veritabanı da "Suspect" durumuna geçer.
Not:
Örneğin bir Instance' ı 2005, diğerini de 2008 olarak kurmayı denerseniz SQL Server buna kızmayacaktır ve izin verecektir, fakat Failover yaptığınızda bu hata mesajıyla (veya benzeriyle, çünkü versiyonlar farklı olabilir) karşılaşacaksınız.
"The database 'veritabanı_adı' cannot be opened because it is version 655. This server supports version 612 and earlier. A downgrade path is not suppo
HATA MESAJI:
"The database 'veritabanı_adı' cannot be opened because it is version 655. This server supports version 612 and earlier. A downgrade path is not supported."
AÇIKLAMA:
İki farklı versiyon SQL Server Instance' ı arasında Database Mirroring yaparsanız, Automatic veya Manual Failover olduğunda böyle bir hata mesajıyla karşılaşabilirsiniz.
ÇÖZÜM:
Database Mirroring için, Database Mirroring tasarımınızdaki Principal ve Mirror Sunucularının Instance Versiyon ve Edition' ları aynı olmalıdır.
Database Mirroring için SQL Server' ın Standard veya Enterprise Edition sürümüne ihtiyacınız var. Eğer bir tasarım yapacaksanız, o zaman bu tasarımdaki Principal ve Mirror sunucuların ikisi de ya Standard Edition olmalı ya da Enterprise Edition. Ayrıca iki sunucu Instance' ına da aynı Servis Paketleri ve Cumulative Update' ler uygulanmalı. Bir Instance 2005, diğeri de 2008 olamaz. Yoksa böyle bir hata mesajıyla karşılaşırsınız.
Bununla birlikte, Mirror sunucudaki veritabanı da "Suspect" durumuna geçer.
Not:
Örneğin bir Instance' ı 2005, diğerini de 2008 olarak kurmayı denerseniz SQL Server buna kızmayacaktır ve izin verecektir, fakat Failover yaptığınızda bu hata mesajıyla (veya benzeriyle, çünkü versiyonlar farklı olabilir) karşılaşacaksınız.
"The database 'veritabanı_adı' cannot be opened because it is version 655. This server supports version 612 and earlier. A downgrade path is not supported."
AÇIKLAMA:
İki farklı versiyon SQL Server Instance' ı arasında Database Mirroring yaparsanız, Automatic veya Manual Failover olduğunda böyle bir hata mesajıyla karşılaşabilirsiniz.
ÇÖZÜM:
Database Mirroring için, Database Mirroring tasarımınızdaki Principal ve Mirror Sunucularının Instance Versiyon ve Edition' ları aynı olmalıdır.
Database Mirroring için SQL Server' ın Standard veya Enterprise Edition sürümüne ihtiyacınız var. Eğer bir tasarım yapacaksanız, o zaman bu tasarımdaki Principal ve Mirror sunucuların ikisi de ya Standard Edition olmalı ya da Enterprise Edition. Ayrıca iki sunucu Instance' ına da aynı Servis Paketleri ve Cumulative Update' ler uygulanmalı. Bir Instance 2005, diğeri de 2008 olamaz. Yoksa böyle bir hata mesajıyla karşılaşırsınız.
Bununla birlikte, Mirror sunucudaki veritabanı da "Suspect" durumuna geçer.
Not:
Örneğin bir Instance' ı 2005, diğerini de 2008 olarak kurmayı denerseniz SQL Server buna kızmayacaktır ve izin verecektir, fakat Failover yaptığınızda bu hata mesajıyla (veya benzeriyle, çünkü versiyonlar farklı olabilir) karşılaşacaksınız.
"Error 15404: could not obtain information about Windows NT group/user 'Domain\User', error code 0x5."
HATA MESAJI:
"Error 15404: could not obtain information about Windows NT group/user 'Domain\User', error code 0x5."
AÇIKLAMA:
SQL Server' da bir işlem yaparken böyle bir hata ile karşılaşabilirsiniz.
Nedeni ise sunucunuzun Domain Controller ile haberleşemeyip, hesabınızın doğruluğunu kontrol edememesidir (authentication).
ÇÖZÜM:
Çözüm olarak ilgili sunucuyu kapatıp yeniden başlatmanızı tavsiye ederim, eğer sorun tekrar ediyorsa sistem yönetisine başvurmalısınız.
"Error 15404: could not obtain information about Windows NT group/user 'Domain\User', error code 0x5."
AÇIKLAMA:
SQL Server' da bir işlem yaparken böyle bir hata ile karşılaşabilirsiniz.
Nedeni ise sunucunuzun Domain Controller ile haberleşemeyip, hesabınızın doğruluğunu kontrol edememesidir (authentication).
ÇÖZÜM:
Çözüm olarak ilgili sunucuyu kapatıp yeniden başlatmanızı tavsiye ederim, eğer sorun tekrar ediyorsa sistem yönetisine başvurmalısınız.
"RegCreateKeyEx() returned error 5, 'Access is denied.' (Microsoft SQL Server, Error: 22002)"
HATA MESAJI:
"RegCreateKeyEx() returned error 5, 'Access is denied.' (Microsoft SQL Server, Error: 22002)"
AÇIKLAMA:
SQL Server' da bir işlem yaparken böyle bir hata ile karşılaşabilirsiniz.
Ben, Replication' daki Distribution Configuration ayarını yapmak istediğimde bu hatayla karşılaşmıştım.
ÇÖZÜM:
Öncelikle şunu belirteyim ki, bu hata tamamen SQL Server servisinin yetkileriyle alâkalı. Benim durumumda, SQL Server servisi için özel bir yerel hesap oluşturmuştum ve onu kullanıyordum. Bu servis hesabını da SQL Server Configuration Manager' dan atamıştım, fakat buna rağmen işlemler sırasında böyle bir hata mesajıyla ve daha başka çeşitli sorunlarla karşılaştım.
Bahsini ettiğim SQL Server Instance' ı bir test Instance' ı olduğu için servis hesabını Local Service olarak değiştirdim ve aynı işlemi tekrar yapmayı denedim ve bu sefer çalıştı.
"RegCreateKeyEx() returned error 5, 'Access is denied.' (Microsoft SQL Server, Error: 22002)"
AÇIKLAMA:
SQL Server' da bir işlem yaparken böyle bir hata ile karşılaşabilirsiniz.
Ben, Replication' daki Distribution Configuration ayarını yapmak istediğimde bu hatayla karşılaşmıştım.
ÇÖZÜM:
Öncelikle şunu belirteyim ki, bu hata tamamen SQL Server servisinin yetkileriyle alâkalı. Benim durumumda, SQL Server servisi için özel bir yerel hesap oluşturmuştum ve onu kullanıyordum. Bu servis hesabını da SQL Server Configuration Manager' dan atamıştım, fakat buna rağmen işlemler sırasında böyle bir hata mesajıyla ve daha başka çeşitli sorunlarla karşılaştım.
Bahsini ettiğim SQL Server Instance' ı bir test Instance' ı olduğu için servis hesabını Local Service olarak değiştirdim ve aynı işlemi tekrar yapmayı denedim ve bu sefer çalıştı.
"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.
"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 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.
"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.
"Database '
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...
"BackupIoRequest::WaitForIoCompletion: read failure on backup device '
"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 '
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...
Kaydol:
Kayıtlar (Atom)