SQL Server tanılama, 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 raporlanmamış 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 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 ile başlayan 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 olay tarafından 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 yazma işleminin başarılı olduğu bildirilmesine rağmen işletim sistemi, sürücü veya önbelleğe alma denetleyicisi verileri fiziksel medyaya doğru bir şekilde boşaltmaz.

• Eski Okuma: ReadFile API'sine yapılan başarılı bir çağrıdı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ı durumunu döndürdüğü ancak aynı veri bloğunun hemen, başarılı bir şekilde okunduğu senaryoları doğruladı ve büyük olasılıkla donanım okuma önbelleğinde depolanan veriler de dahil olmak üzere eski verileri döndürüyor. Bu sorun bazen okuma önbelleği sorunu nedeniyle oluşur. Diğer durumlarda, yazma verileri hiçbir zaman fiziksel diske yazılmamıştır.

Tanılamayı etkinleştirme

SQL Server 2017 ve sonraki sürümlerde 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. İzleme bayrağı 818'i SQL Server örneği için başlangıç parametresi (-T818) olarak belirtebilir veya çalışma zamanında etkinleştirmek üzere 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 bellek içi halka arabelleğe olanak tanır. 605, 823 veya 3448 gibi hatalar oluştuğunda, gelen arabelleğinin 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. çoğu SQL Server yazma işlemi denetim noktaları veya yavaş yazma 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 SQL Server ReadFile API çağrılarından gelen açık hataları göstermez. Bunun yerine, LSN gözden geçirildiğinde ve beklenen değeri doğru olmadığında ortaya çıkan mantıksal G/Ç hatasını gösterir:

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

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üğü 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. çevrimiçi kitaplar SQL Server.

824 hatası 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 3448 hatası oluşursa, SQL Server örneği veritabanını otomatik olarak kapatır ve veritabanını açmaya ve kurtarmaya çalışır. 605 veya 823 hatasıyla 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 çalıştırdığınızda DBCC DROPCLEANBUFFERS (bellekten tüm veritabanı sayfalarını kaldırmak için) ve ardından deyimini veritabanında çalıştırdığınızda DBCC CHECKDB , en son yazılan veriler döndürülür.

Önceki paragrafta bahsedilen 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 önbelleği geçersiz kılmaya 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 ardından 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 aynı LSN değeriyle iki kez güncelleştirilmiş gibi görünür. 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 ilgili 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), sayfadaki (1:1787100), veritabanı 'authors' (7) için günlük kaydı (276666:1664:19) yinelanamadı. Sayfa: LSN = (276658:4501:9), tür = 1. 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

sort SQL Server 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ı kullanmak üzere 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 yazma kaybının beklenen bir veri depolama alanıyla sonuçlanmadığından, çok çeşitli davranışlar oluşabilir. Eksik veriler olarak görünebilir, ancak eksik verilerin daha yaygın etkilerinden bazıları dizin bozulmaları olarak görünür, örneğin hata 644 veya 625:

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

Hata 625 Önem Derecesi 21 İleti Metni Yuva kimliği (%d) geçerli olmadığından %S_PGID sayfasından RID tarafı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.

Microsoft'un nadir ve ağır G/Ç yükleri altında bazı donanım platformlarının eski bir 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, hemen izleme için donanım satıcınıza başvurun ve SQLIOSim yardımcı programıyla test edin.

SQL Server, sistemlerin SQL Server G/Ç Güvenilirlik Programı Gereksinimleri altında açıklandığı gibi 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.