SQL Server tanılaması, eski okumalar veya kayıp yazmalar nedeniyle raporlanmayan G/Ç sorunlarını algılar

Bu makalede, SQL Server Tanılama'nın eski okumalar veya kayıp yazmalar nedeniyle oluşan raporlanmayan giriş veya çıkış sorunlarını algılamaya nasıl yardımcı olduğu açıklanmaktadır.

Özgün ürün sürümü: SQL Server
Özgün KB numarası: 826433

Belirtiler

İşletim sistemi, sürücü veya donanım sorunları G/Ç yolunda yazma veya eski okuma koşullarının kaybolmasına neden oluyorsa, SQL Server'da 605, 823, 3448 ve 3456 hataları gibi veri bütünlüğüyle ilgili hata iletileri görebilirsiniz. Aşağıdaki örneklere benzer hata iletileri alabilirsiniz:

2003-07-24 16:43:04.57 spid63 Getpage: bstat=0x9, sstat=0x800, cache
2003-07-24 16:43:04.57 spid63 pageno is/should be: objid is/should be:
2003-07-24 16:43:04.57 spid63 (1:7040966)/(1:7040966) 2093354622/2039782424
2003-07-24 16:43:04.57 spid63 ... IAM indicates that page is allocated to this object
2003-07-24 16:52:37.67 spid63 Error: 605, Severity: 21, State: 1
2003-07-24 16:52:37.67 spid63 Attempt to fetch logical page (1:7040966) in database 'pubs' belongs to object 'authors', not to object 'titles'..
2003-07-24 16:52:40.99 spid63 Error: 3448, Severity: 21, State: 1
2003-07-24 16:52:40.99 spid63 Could not undo log record (63361:16876:181), for transaction ID (0:159696956), on page (1:7040977), database 'pubs' (database ID 12). Page information: LSN = (63192:958360:10), type = 2. Log information: OpCode = 2, context 1..
2003-07-09 14:31:35.92 spid66 Error: 823, Severity: 24, State: 2
2003-07-09 14:31:35.92 spid66 I/O error (bad page ID) detected during read at offset 0x00000016774000 in file 'h:\sql\MSSQL\data\tempdb.mdf'..
2010-02-06 15:57:24.14 spid17s Error: 3456, Severity: 21, State: 1.
2010-02-06 15:57:24.14 spid17s Could not redo log record (58997:5252:28), for transaction ID (0:109000187), on page (1:480946), database 'MyDatabase' (database ID 17). Page: LSN = (58997:5234:17), type = 3. Log: OpCode = 2, context 5, PrevPageLSN: (58997:5243:17). Restore from a backup of the database, or repair the database.

SQL Server'da yeni G/Ç tanılama özellikleri

SQL Server, SQL Server 2000 Service Pack 4'ten başlayarak yeni G/Ç tanılama özellikleri kullanıma sunulmuştur ve bu tanılamalar o zamandan beri ürünün bir parçası olmuştur. Bu özellikler, dış G/Ç ile ilgili sorunları algılamaya ve Belirtiler bölümünde açıklanan hata iletilerini gidermeye yardımcı olmak için tasarlanmıştır.

Belirtiler bölümünde listelenen hata iletilerinden herhangi birini alırsanız ve bunlar fiziksel sürücü hatası gibi bir olayla açıklanmamışsa SQL Server, işletim sistemi, sürücüler ve donanımla ilgili bilinen sorunları gözden geçirin. Tanılama, aşağıdaki iki koşul hakkında bilgi sağlamaya çalışır:

• Kayıp Yazma: WriteFile API'sine yapılan başarılı bir çağrı, ancak SQL Server'a yazma işleminin başarılı olduğu bildirilmesine rağmen işletim sistemi, sürücü veya önbelleğe alma denetleyicisi verileri doğru bir şekilde fiziksel medyaya boşaltmaz.

• Eski Okuma: ReadFile API'sine yapılan başarılı bir çağrı, ancak işletim sistemi, sürücü veya önbelleğe alma denetleyicisi hatalı bir şekilde verilerin eski bir sürümünü döndürür.

Microsoft, WriteFile API çağrısının başarılı bir durum döndürdüğü ancak aynı veri bloğunun hemen, başarılı bir şekilde okunması, donanım okuma önbelleğinde depolanmış olabilecek veriler de dahil olmak üzere eski verileri döndürdüğü senaryoları doğruladı. Bazen bu sorun, okuma önbelleği sorunu nedeniyle oluşur. Diğer durumlarda, yazma verileri hiçbir zaman fiziksel diske yazılır.

Tanılamayı etkinleştirme

SQL Server 2017 ve sonraki sürümlerinde bu tanılama özelliği varsayılan olarak etkindir. SQL Server 2016 ve önceki sürümlerde bu tanılamalar yalnızca izleme bayrağı 818 kullanılarak etkinleştirilebilir. SQL Server örneği için başlangıç parametresi olarak -T818 izleme bayrağı 818 belirtebilir veya çalışma zamanında etkinleştirmek için aşağıdaki T-SQL deyimini çalıştırabilirsiniz:

DBCC TRACEON(818, -1)

İzleme bayrağı 818, sıralama ve iş dosyası G/Ç'leri dahil olmak üzere SQL Server çalıştıran bilgisayar tarafından gerçekleştirilen son 2.048 başarılı yazma işlemini izlemek için kullanılan bir bellek içi halka arabelleği etkinleştirir. 605, 823 veya 3448 gibi hatalar oluştuğunda, gelen arabelleğin günlük dizisi numarası (LSN) değeri son yazma listesiyle karşılaştırılır. Okuma işlemi sırasında alınan LSN yazma işleminde kullanılandan daha eskiyse, SQL Server hata günlüğüne yeni bir hata iletisi kaydedilir. SQL Server yazma işlemlerinin çoğu denetim noktaları veya gecikmeli yazma işlemleri olarak gerçekleşir (yavaş yazma, zaman uyumsuz G/Ç kullanan bir arka plan görevidir). Halka arabelleğinin uygulanması hafiftir ve sistem üzerindeki performans etkisi göz ardı edilebilir.

Hata günlüğündeki iletiyle ilgili ayrıntılar

Aşağıdaki ileti, WriteFile API'sinden veya ReadFile API'sinden sql Server'ın çağırdığı açık hataları göstermez. Bunun yerine, LSN gözden geçirildiğinde ve beklenen değeri doğru olmadığında sonuçlanan mantıksal bir G/Ç hatası gösterir:

SQL Server 2005'den başlayarak, görüntülenen hata iletisi şöyledir:

SQL Server, mantıksal tutarlılık tabanlı G/Ç hatası algılandı: Eski Okuma. bu, dosyasındaki <FILE NAME>uzaklıkta <PHYSICAL OFFSET> veritabanı kimliğindeki <DBID> bir <Read/Write> sayfa <PAGEID> sırasında oluştu. SQL Server hata günlüğündeki veya sistem olay günlüğündeki ek iletiler daha fazla ayrıntı sağlayabilir. Bu, veritabanı bütünlüğünü tehdit eden ve hemen düzeltilmesi gereken ciddi bir hata koşuludur. Tam veritabanı tutarlılığı denetimini (DBCC CHECKDB) tamamlayın. Bu hata birçok faktörden kaynaklanabilir. Daha fazla bilgi için bkz. SQL Server Books Online.

Hata 824 hakkında daha fazla bilgi için bkz . MSSQLSERVER_824.

Bu noktada veya bu hatayı bildirerek, okuma önbelleği sayfanın eski bir sürümünü içeriyor veya veriler fiziksel diske doğru yazmıyordu. Her iki durumda da (kayıp yazma veya eski okuma), SQL Server işletim sistemi, sürücü veya donanım katmanlarıyla ilgili bir dış sorun bildirir.

Hata 605 veya 823 olan bir işlemi geri almaya çalıştığınızda hata 3448 oluşursa, SQL Server örneği veritabanını otomatik olarak kapatır ve açmayı ve kurtarmayı dener. Hata 605 veya 823 ile karşılaşan ilk sayfa hatalı bir sayfa olarak kabul edilir ve sayfa kimliği SQL Server çalıştıran bilgisayar tarafından tutulur. Hatalı sayfa kimliği okunduğunda kurtarma sırasında (yineleme aşamasından önce), sayfa üst bilgisi hakkındaki birincil ayrıntılar SQL Server hata günlüğüne kaydedilir. Bu eylem, Kayıp Yazma ve Eski Okuma senaryolarını ayırt etmeye yardımcı olduğundan önemlidir.

Eski okumalar ve kayıp yazmalarla gözlemlenen davranış

Eski okuma senaryolarında aşağıdaki iki yaygın davranışı görebilirsiniz:

• Veritabanı dosyaları kapatılır ve sonra açılırsa, kurtarma sırasında doğru ve en son yazılan veriler döndürülür.

• Bir denetim noktası oluşturup deyimini DBCC DROPCLEANBUFFERS çalıştırdığınızda (bellekten tüm veritabanı sayfalarını kaldırmak için) ve sonra veritabanında deyimini çalıştırdığınızda DBCC CHECKDB , en son yazılan veriler döndürülür.

Önceki paragrafta belirtilen davranışlar okuma önbelleği sorununu gösterir ve okuma önbelleği devre dışı bırakılarak sık sık çözülür. Önceki paragrafta özetlenen eylemler genellikle önbellek geçersiz kılınmasını zorlar ve gerçekleşen başarılı okumalar fiziksel medyanın doğru güncelleştirildiğini gösterir. Önbelleğe alma mekanizmalarının zorla boşaltılmasından sonra bile, geri okunan sayfa hala verilerin eski sürümü olduğunda kayıp yazma davranışı oluşur.

Bazen sorun bir donanım önbelleğine özgü olmayabilir. Filtre sürücüsüyle ilgili bir sorun olabilir. Bu gibi durumlarda, yedekleme yardımcı programları ve virüsten koruma yazılımları da dahil olmak üzere yazılımınızı gözden geçirin ve filtre sürücüsünde sorun olup olmadığına bakın.

Çeşitli eski okuma ve kayıp yazma senaryolarının açıklaması

Microsoft, hata 605 veya 823 ölçütlerini karşılamayan ancak aynı eski okuma veya kayıp yazma etkinliğinden kaynaklanan koşulları da belirtmiştir. Bazı durumlarda, bir sayfa iki kez güncelleştirilmiş gibi görünür, ancak aynı LSN değeriyle. Nesne Kimliği ve Sayfa Kimliği doğruysa (sayfa nesneye zaten ayrılmışsa) ve sayfada bir değişiklik yapılıp diske boşaltılırsa bu davranış oluşabilir. Sonraki sayfa alma işlemi daha eski bir görüntü döndürür ve ikinci bir değişiklik yapılır. SQL Server işlem günlüğü, sayfanın aynı LSN değeriyle iki kez güncelleştirildiğini gösterir. Bu eylem, bir işlem günlüğü dizisini geri yüklemeye çalıştığınızda veya yabancı anahtar hataları veya eksik veri girişleri gibi veri tutarlılığı sorunlarıyla karşılaştığınızda bir sorun haline gelir. Aşağıdaki hata iletisi bu koşulun bir örneğini gösterir:

Hata: 3456, Önem Derecesi: 21, Durum: 1 İşlem kimliği (0:825853240) için günlük kaydı (276666:1664:19), sayfadaki (1:1787100), veritabanı 'authors' (7) için yinelenmedi. Sayfa: LSN = (276658:4501:9), = 1 yazın. Günlük: OpCode = 4, bağlam 2, PrevPageLSN: (275565:3959:31)..

Bazı senaryolar aşağıdaki listelerde daha ayrıntılı olarak özetlenmiştir:

LSN SequenceAction
1   Checkpoint
2   Begin Transaction
3   Table created or truncated
4   Inserts (Pages allocated)
5   Newly allocated page written to disk by Lazy Writer
6   Select from table - Scans IAM chain, newly allocated page read back from disk (LRU | HASHED = 0x9 in getpage message), encounters Error 605 - Invalid Object ID
7   Rollback of transaction initiated

LSN SequenceAction
1   Checkpoint
2   Begin Transaction
3   Page Modification
4   Page written to disk by Lazy Writer
5   Page read in for another modification (stale image returned)
6   Page Modified for a second time but because of stale image does not see first modification 
7   Rollback - Fails - Transaction Log shows two different log records with the same PREV LSN for the page

SQL Server sort işleçleri genellikle tempdb veritabanında G/Ç etkinlikleri gerçekleştirir. Bu G/Ç işlemleri arabellek G/Ç işlemlerine benzer; ancak, benzer sorunları çözmeye çalışmak için okuma yeniden deneme mantığını kullanacak şekilde zaten tasarlanmıştır. Bu makalede açıklanan ek tanılamalar bu G/Ç işlemleri için geçerli değildir.

Microsoft, aşağıdaki sıralama okuma hatalarının kök nedeninin genellikle eski bir okuma veya kayıp yazma olduğunu belirtmiştir:

2003-04-01 20:13:31.38 spid122 SQL Server Assertion: File: <p:\sql\ntdbms\storeng\drs\include\record.inl>, line=1447 Failed Assertion = 'm_SizeRec > 0 && m_SizeRec <= MAXDATAROW'.
2003-03-29 09:51:41.12 spid57 Sort read failure (bad page ID). pageid = (0x1:0x13e9), dbid = 2, file = e:\program files\Microsoft SQL Server\mssql\data\tempdb.mdf. Retrying.
2003-03-29 09:51:41.13 spid57 Error: 823, Severity: 24, State: 7
2003-03-29 09:51:41.13 spid57 I/O error (bad page ID) detected during read at offset 0x000000027d2000 in file 'e:\program files\Microsoft SQL Server\mssql\data\tempdb.mdf'..
* 00931097 Module(sqlservr+00531097) (utassert_fail+000002E3)
* 005B1DA8 Module(sqlservr+001B1DA8) (RecBase::Resize+00000091)
* 00407EE7 Module(sqlservr+00007EE7) (RecBase::LocateColumn+00000012)
* 00852520 Module(sqlservr+00452520) (mergerow+000000A4)
* 008522B3 Module(sqlservr+004522B3) (merge_getnext+00000285)
* 0085207D Module(sqlservr+0045207D) (mergenext+0000000D)
* 004FC5FB Module(sqlservr+000FC5FB) (getsorted+00000021)

Eski bir okuma veya kayıp yazma, veri depolamada beklenmeyen sonuçlara neden olduğundan, çok çeşitli davranışlar oluşabilir. Eksik veriler olarak görünebilir, ancak eksik verilerin daha yaygın etkilerinden bazıları 644 veya 625 hatası gibi dizin bozulmaları olarak görünür:

Hata 644 Önem Derecesi Düzey 21 İleti Metni %S_PGID dizin sayfasında,%d dizin kimliğinde, '%.*ls' veritabanında '%.*hs' RID'si için dizin girdisini bulamadı.

Hata 625 Önem Derecesi Düzey 21 İleti Metni Yuva kimliği (%d) geçerli olmadığından RID tarafından %S_PGID sayfasından satır alınamıyor.

Bazı müşteriler, satır sayısı etkinlikleri gerçekleştirdikten sonra eksik satırlar bildirdi. Bu sorun, kayıp yazma nedeniyle oluşur. Belki de sayfanın kümelenmiş dizin sayfa zincirine bağlanması gerekiyordu. Yazma işlemi fiziksel olarak kaybolduysa veriler de kaybolur.

Önemli

Davranışlardan herhangi biriyle karşılaşırsanız veya önbelleğe alma mekanizmalarını devre dışı bırakmayla birlikte benzer sorunlardan şüpheleniyorsanız Microsoft, SQL Server için en son güncelleştirmeyi edinmenizi kesinlikle önerir. Microsoft ayrıca işletim sisteminiz ve ilişkili yapılandırmaları üzerinde katı bir inceleme gerçekleştirmenizi kesinlikle teşvik eder.

Microsoft'un nadir ve ağır G/Ç yükleri altında bazı donanım platformlarının eski okuma döndürebileceğini onayladığını unutmayın. Genişletilmiş tanılamalar olası eski bir okuma veya kayıp yazma koşulu gösteriyorsa, sqliosim yardımcı programıyla anında izleme ve test için donanım satıcınıza başvurun.

SQL Server, SISTEMLERIn SQL Server G/Ç Güvenilirlik Programı Gereksinimleri altında özetlenen kararlı medyaya garantili teslimi desteklemesini gerektirir. SQL Server veritabanı altyapısının giriş ve çıkış gereksinimleri hakkında daha fazla bilgi için bkz . Microsoft SQL Server Veritabanı Altyapısı Giriş/Çıkış Gereksinimleri.