क्यों CHECKDB एक मेमोरी अनुकूलित तालिका के साथ डेटाबेस पर लेनदेन लॉग फ़ाइल पढ़ रहा है?

16

tl; dr : CHECKDB मेमोरी ऑप्टिमाइज़्ड टेबल वाले यूजर डेटाबेस के लिए ट्रांजेक्शन लॉग को क्यों पढ़ रहा है?

ऐसा प्रतीत होता है कि CHECKDB उपयोगकर्ता डेटाबेस के लेनदेन लॉग फ़ाइल को पढ़ रहा है जब यह मेरे डेटाबेस में से एक पर जाँच कर रहा है - विशेष रूप से, एक डेटाबेस जो इन-मेमोरी ओएलटीपी तालिकाओं का उपयोग करता है।

इस डेटाबेस के लिए CHECKDB अभी भी समय की एक उचित मात्रा में समाप्त होता है, इसलिए मैं ज्यादातर व्यवहार के बारे में उत्सुक हूं; लेकिन यह निश्चित रूप से इस उदाहरण पर सभी डेटाबेस के CHECKDB के लिए सबसे लंबी अवधि है।

पॉल रैंडल के महाकाव्य " CHECKDB एवरी एंगल से: संपूर्ण CHECKDB चरणों का पूरा विवरण, " देखने में , मुझे लगता है कि पूर्व SQL 2005 CHECKDB डेटाबेस का एक सुसंगत दृश्य प्राप्त करने के लिए लॉग को पढ़ने के लिए उपयोग किया जाता है । लेकिन 2016 के बाद से, यह एक आंतरिक डेटाबेस स्नैपशॉट का उपयोग करता है ।

हालांकि, स्नैपशॉट के लिए किसी और चीज में से एक है:

स्रोत डेटाबेस में MEMORY_OPTIMIZED_DATA फ़ाइल समूह नहीं होना चाहिए

मेरे उपयोगकर्ता डेटाबेस में इन फ़ाइलग्रुपों में से एक है, इसलिए ऐसा लगता है कि स्नैपशॉट तालिका से दूर हैं।

CHECKDB डॉक्स के अनुसार :

यदि कोई स्नैपशॉट नहीं बनाया जा सकता है, या TABLOCK निर्दिष्ट किया जाता है, DBCC CHECKDB आवश्यक स्थिरता प्राप्त करने के लिए ताले प्राप्त करता है। इस मामले में, आवंटन चेक करने के लिए एक विशेष डेटाबेस लॉक की आवश्यकता होती है, और टेबल चेक करने के लिए साझा टेबल लॉक की आवश्यकता होती है।

ठीक है, इसलिए हम स्नैपशॉट के बजाय डेटाबेस और टेबल लॉकिंग कर रहे हैं। लेकिन यह अभी भी स्पष्ट नहीं करता है कि इसे लेन-देन लॉग क्यों पढ़ना है। तो क्या देता है?

मैंने परिदृश्य को पुन: पेश करने के लिए नीचे एक स्क्रिप्ट प्रदान की है। यह sys.dm_io_virtual_file_statsलॉग फ़ाइल रीड्स की पहचान करने के लिए उपयोग करता है।

ध्यान दें कि अधिकांश समय यह लॉग के एक छोटे हिस्से (480 KB) को पढ़ता है, लेकिन यह कभी-कभी बहुत अधिक (483 एमबी) पढ़ता है। मेरे प्रोडक्शन परिदृश्य में, यह हर रात आधी रात को जब हम CHECKDB चलाते हैं, तो ज्यादातर लॉग फ़ाइल (2 जीबी फ़ाइल का ~ 1.3 जीबी) पढ़ता है।

यहाँ स्क्रिप्ट के साथ अब तक मिले आउटपुट का एक उदाहरण है:

collection_time            num_of_reads     num_of_bytes_read
2018-04-04 15:12:29.203    106              50545664

या यह:

collection_time            num_of_reads     num_of_bytes_read
2018-04-04 15:25:14.227    1                491520

यदि मैं नियमित रूप से तालिकाओं के साथ मेमोरी अनुकूलित वस्तुओं को प्रतिस्थापित करता हूं, तो आउटपुट इस तरह दिखता है:

collection_time            num_of_reads     num_of_bytes_read
2018-04-04 15:21:03.207    0                0

CHECKDB लॉग फ़ाइल क्यों पढ़ रहा है? और विशेष रूप से, यह कभी-कभार लॉग फाइल का एक बड़ा हिस्सा क्यों पढ़ता है?

यहाँ वास्तविक स्क्रिप्ट है:

-- let's have a fresh DB
USE [master];

IF (DB_ID(N'LogFileRead_Test') IS NOT NULL) 
BEGIN
    ALTER DATABASE [LogFileRead_Test]
    SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE [LogFileRead_Test];
END

GO
CREATE DATABASE [LogFileRead_Test]

GO
ALTER DATABASE [LogFileRead_Test]
MODIFY FILE
(
    NAME = LogFileRead_Test_log,
    SIZE = 128MB
);

-- Hekaton-yeah, I want memory optimized data
GO
ALTER DATABASE [LogFileRead_Test]
ADD FILEGROUP [LatencyTestInMemoryFileGroup] CONTAINS MEMORY_OPTIMIZED_DATA;

GO
ALTER DATABASE [LogFileRead_Test]
ADD FILE 
(
    NAME = [LatencyTestInMemoryFile], 
    FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\LogFileRead_Test_SessionStateInMemoryFile'
) TO FILEGROUP [LatencyTestInMemoryFileGroup];

GO
USE [LogFileRead_Test]

GO
CREATE TYPE [dbo].[InMemoryIdTable] AS TABLE (
    [InMemoryId] NVARCHAR (88) COLLATE Latin1_General_100_BIN2 NOT NULL,
    PRIMARY KEY NONCLUSTERED HASH ([InMemoryId]) WITH (BUCKET_COUNT = 240))
    WITH (MEMORY_OPTIMIZED = ON);

GO
CREATE TABLE [dbo].[InMemoryStuff] (
    [InMemoryId]   NVARCHAR (88)    COLLATE Latin1_General_100_BIN2 NOT NULL,
    [Created]     DATETIME2 (7)    NOT NULL,
    CONSTRAINT [PK_InMemoryStuff_InMemoryId] PRIMARY KEY NONCLUSTERED HASH ([InMemoryId]) WITH (BUCKET_COUNT = 240)
)
WITH (MEMORY_OPTIMIZED = ON);

GO
-- RBAR is the new black (we need some logs to read)
declare @j int = 0;
while @j < 100000
begin
    INSERT INTO [dbo].[InMemoryStuff](InMemoryId, Created) VALUES ('Description' + CAST(@j as varchar), GETDATE());
    set @j = @j + 1;
end

-- grab a baseline of virtual file stats to be diff'd later
select f.num_of_reads, f.num_of_bytes_read
into #dm_io_virtual_file_stats
from sys.dm_io_virtual_file_stats(default, default) f
where database_id = db_id('LogFileRead_Test') and file_id = FILE_IDEX('LogFileRead_Test_log');

-- hands off my log file, CHECKDB!
GO
DBCC CHECKDB ([LogFileRead_Test]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;

-- grab the latest virtual file stats, and compare with the previous capture
GO
select f.num_of_reads, f.num_of_bytes_read
into #checkdb_stats
from sys.dm_io_virtual_file_stats(default, default) f
where database_id = db_id('LogFileRead_Test') and file_id = FILE_IDEX('LogFileRead_Test_log');

select 
        collection_time = GETDATE() 
        , num_of_reads = - f.num_of_reads + t.num_of_reads
        , num_of_bytes_read = - f.num_of_bytes_read + t.num_of_bytes_read
into #dm_io_virtual_file_stats_diff
from #dm_io_virtual_file_stats f, #checkdb_stats t;

drop table #checkdb_stats;
drop table #dm_io_virtual_file_stats;

-- CHECKDB ignored my comment
select collection_time, num_of_reads, num_of_bytes_read
from #dm_io_virtual_file_stats_diff d
order by d.collection_time;

drop table #dm_io_virtual_file_stats_diff;

-- I was *not* raised in a barn
USE [master];

ALTER DATABASE [LogFileRead_Test]
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [LogFileRead_Test];

चूँकि यह रेप्रो आम तौर पर सिर्फ 1 या 106 लॉग फ़ाइल पढ़ता है, मुझे लगा कि मैं 1 में एक file_read और file_read_completed विस्तारित इवेंट सत्र के साथ खुदाई करूँगा।

name                timestamp                   mode        offset  database_id file_id size    duration
file_read           2018-04-06 10:51:11.1098141 Contiguous  72704   9           2       0       NULL    
file_read_completed 2018-04-06 10:51:11.1113345 Contiguous  72704   9           2       491520  1

और यहाँ DBCC LOGINFO()उन ऑफसेट और इस तरह के संदर्भ के लिए VLF विवरण ( ) है:

RecoveryUnitId  FileId  FileSize    StartOffset FSeqNo  Status  Parity  CreateLSN
0               2       2031616     8192        34      2       64      0
0               2       2031616     2039808     35      2       64      0
0               2       2031616     4071424     36      2       64      0
0               2       2285568     6103040     37      2       64      0
0               2       15728640    8388608     38      2       64      34000000005200001
0               2       15728640    24117248    39      2       64      34000000005200001
0               2       15728640    39845888    40      2       64      34000000005200001
0               2       15728640    55574528    0       0       0       34000000005200001
0               2       15728640    71303168    0       0       0       34000000005200001
0               2       15728640    87031808    0       0       0       34000000005200001
0               2       15728640    102760448   0       0       0       34000000005200001
0               2       15728640    118489088   0       0       0       34000000005200001

तो, CHECKDB ऑपरेशन:

  • पहले VLF में 63 KB (64,512 बाइट्स) पढ़ना शुरू किया,
  • 480 KB (491,520 बाइट्स) पढ़ें, और
  • था नहीं पढ़ VLF के अंतिम 1441 KB (1,475,584 बाइट्स)

मैंने कॉलस्टैक्स पर भी कब्जा कर लिया, मामले में वे सहायक हैं।

file_read कॉलस्टैक:

(00007ffd`999a0860)   sqlmin!XeSqlPkg::file_read::Publish+0x1dc   |  (00007ffd`999a0b40)   sqlmin!XeSqlPkg::file_read_enqueued::Publish
(00007ffd`9a825e30)   sqlmin!FireReadEvent+0x118   |  (00007ffd`9a825f60)   sqlmin!FireReadEnqueuedEvent
(00007ffd`9980b500)   sqlmin!FCB::AsyncRead+0x74d   |  (00007ffd`9980b800)   sqlmin!FCB::AsyncReadInternal
(00007ffd`9970e9d0)   sqlmin!SQLServerLogMgr::LogBlockReadAheadAsync+0x6a6   |  (00007ffd`9970ec00)   sqlmin!LBH::Destuff
(00007ffd`9970a6d0)   sqlmin!LogConsumer::GetNextLogBlock+0x1591   |  (00007ffd`9970ab70)   sqlmin!LogPoolPrivateCacheBufferMgr::Lookup
(00007ffd`9a9fcbd0)   sqlmin!SQLServerLogIterForward::GetNext+0x258   |  (00007ffd`9a9fd2d0)   sqlmin!SQLServerLogIterForward::GetNextBlock
(00007ffd`9aa417f0)   sqlmin!SQLServerCOWLogIterForward::GetNext+0x2b   |  (00007ffd`9aa418c0)   sqlmin!SQLServerCOWLogIterForward::StartScan
(00007ffd`9aa64210)   sqlmin!RecoveryMgr::AnalysisPass+0x83b   |  (00007ffd`9aa65100)   sqlmin!RecoveryMgr::AnalyzeLogRecord
(00007ffd`9aa5ed50)   sqlmin!RecoveryMgr::PhysicalRedo+0x233   |  (00007ffd`9aa5f790)   sqlmin!RecoveryMgr::PhysicalCompletion
(00007ffd`9aa7fd90)   sqlmin!RecoveryUnit::PhysicalRecovery+0x358   |  (00007ffd`9aa802c0)   sqlmin!RecoveryUnit::CompletePhysical
(00007ffd`9a538b90)   sqlmin!StartupCoordinator::NotifyPhaseStart+0x3a   |  (00007ffd`9a538bf0)   sqlmin!StartupCoordinator::NotifyPhaseEnd
(00007ffd`9a80c430)   sqlmin!DBTABLE::ReplicaCreateStartup+0x2f4   |  (00007ffd`9a80c820)   sqlmin!DBTABLE::RefreshPostRecovery
(00007ffd`9a7ed0b0)   sqlmin!DBMgr::SyncAndLinkReplicaRecoveryPhase+0x890   |  (00007ffd`9a7edff0)   sqlmin!DBMgr::DetachDB
(00007ffd`9a7f2cd0)   sqlmin!DBMgr::CreatePhasedTransientReplica+0x869   |  (00007ffd`9a7f3630)   sqlmin!DBMgr::StrandTransientReplica
(00007ffd`9a7f2ae0)   sqlmin!DBMgr::CreateTransientReplica+0x118   |  (00007ffd`9a7f2cd0)   sqlmin!DBMgr::CreatePhasedTransientReplica
(00007ffd`99ec6d30)   sqlmin!DBDDLAgent::CreateReplica+0x1b5   |  (00007ffd`99ec6f90)   sqlmin!FSystemDatabase
(00007ffd`9abaaeb0)   sqlmin!UtilDbccCreateReplica+0x82   |  (00007ffd`9abab000)   sqlmin!UtilDbccDestroyReplica
(00007ffd`9ab0d7e0)   sqlmin!UtilDbccCheckDatabase+0x994   |  (00007ffd`9ab0ffd0)   sqlmin!UtilDbccRetainReplica
(00007ffd`9ab0cfc0)   sqlmin!DbccCheckDB+0x22d   |  (00007ffd`9ab0d380)   sqlmin!DbccCheckFilegroup
(00007ffd`777379c0)   sqllang!DbccCommand::Execute+0x193   |  (00007ffd`77737d70)   sqllang!DbccHelp
(00007ffd`777e58d0)   sqllang!CStmtDbcc::XretExecute+0x889   |  (00007ffd`777e6250)   sqllang!UtilDbccSetPermissionFailure
(00007ffd`76b02eb0)   sqllang!CMsqlExecContext::ExecuteStmts<1,1>+0x40d   |  (00007ffd`76b03410)   sqllang!CSQLSource::CleanupCompileXactState
(00007ffd`76b03a60)   sqllang!CMsqlExecContext::FExecute+0xa9e   |  (00007ffd`76b043d0)   sqllang!CCacheObject::Release
(00007ffd`76b03430)   sqllang!CSQLSource::Execute+0x981   |  (00007ffd`76b039b0)   sqllang!CSQLLock::Cleanup

file_read_completed callstack:

(00007ffd`99995cc0)   sqlmin!XeSqlPkg::file_read_completed::Publish+0x1fc   |  (00007ffd`99995fe0)   sqlmin!XeSqlPkg::file_write_completed::Publish
(00007ffd`9a826630)   sqlmin!FireIoCompletionEventLong+0x227   |  (00007ffd`9a8269c0)   sqlmin!IoRequestDispenser::Dump
(00007ffd`9969bee0)   sqlmin!FCB::IoCompletion+0x8e   |  (00007ffd`9969c180)   sqlmin!IoRequestDispenser::Put
(00007ffd`beaa11e0)   sqldk!IOQueue::CheckForIOCompletion+0x426   |  (00007ffd`beaa1240)   sqldk!SystemThread::GetCurrentId
(00007ffd`beaa15b0)   sqldk!SOS_Scheduler::SwitchContext+0x173   |  (00007ffd`beaa18a0)   sqldk!SOS_Scheduler::Switch
(00007ffd`beaa1d00)   sqldk!SOS_Scheduler::SuspendNonPreemptive+0xd3   |  (00007ffd`beaa1db0)   sqldk!SOS_Scheduler::ResumeNoCuzz
(00007ffd`99641720)   sqlmin!EventInternal<SuspendQueueSLock>::Wait+0x1e7   |  (00007ffd`99641ae0)   sqlmin!SOS_DispatcherPool<DispatcherWorkItem,DispatcherWorkItem,SOS_DispatcherQueue<DispatcherWorkItem,0,DispatcherWorkItem>,DispatcherPoolConfig,void * __ptr64>::GetDispatchers
(00007ffd`9aa437c0)   sqlmin!SQLServerLogMgr::CheckLogBlockReadComplete+0x1e6   |  (00007ffd`9aa44670)   sqlmin!SQLServerLogMgr::ValidateBlock
(00007ffd`9970a6d0)   sqlmin!LogConsumer::GetNextLogBlock+0x1b37   |  (00007ffd`9970ab70)   sqlmin!LogPoolPrivateCacheBufferMgr::Lookup
(00007ffd`9a9fcbd0)   sqlmin!SQLServerLogIterForward::GetNext+0x258   |  (00007ffd`9a9fd2d0)   sqlmin!SQLServerLogIterForward::GetNextBlock
(00007ffd`9aa417f0)   sqlmin!SQLServerCOWLogIterForward::GetNext+0x2b   |  (00007ffd`9aa418c0)   sqlmin!SQLServerCOWLogIterForward::StartScan
(00007ffd`9aa64210)   sqlmin!RecoveryMgr::AnalysisPass+0x83b   |  (00007ffd`9aa65100)   sqlmin!RecoveryMgr::AnalyzeLogRecord
(00007ffd`9aa5ed50)   sqlmin!RecoveryMgr::PhysicalRedo+0x233   |  (00007ffd`9aa5f790)   sqlmin!RecoveryMgr::PhysicalCompletion
(00007ffd`9aa7fd90)   sqlmin!RecoveryUnit::PhysicalRecovery+0x358   |  (00007ffd`9aa802c0)   sqlmin!RecoveryUnit::CompletePhysical
(00007ffd`9a538b90)   sqlmin!StartupCoordinator::NotifyPhaseStart+0x3a   |  (00007ffd`9a538bf0)   sqlmin!StartupCoordinator::NotifyPhaseEnd
(00007ffd`9a80c430)   sqlmin!DBTABLE::ReplicaCreateStartup+0x2f4   |  (00007ffd`9a80c820)   sqlmin!DBTABLE::RefreshPostRecovery
(00007ffd`9a7ed0b0)   sqlmin!DBMgr::SyncAndLinkReplicaRecoveryPhase+0x890   |  (00007ffd`9a7edff0)   sqlmin!DBMgr::DetachDB
(00007ffd`9a7f2cd0)   sqlmin!DBMgr::CreatePhasedTransientReplica+0x869   |  (00007ffd`9a7f3630)   sqlmin!DBMgr::StrandTransientReplica
(00007ffd`9a7f2ae0)   sqlmin!DBMgr::CreateTransientReplica+0x118   |  (00007ffd`9a7f2cd0)   sqlmin!DBMgr::CreatePhasedTransientReplica
(00007ffd`99ec6d30)   sqlmin!DBDDLAgent::CreateReplica+0x1b5   |  (00007ffd`99ec6f90)   sqlmin!FSystemDatabase
(00007ffd`9abaaeb0)   sqlmin!UtilDbccCreateReplica+0x82   |  (00007ffd`9abab000)   sqlmin!UtilDbccDestroyReplica
(00007ffd`9ab0d7e0)   sqlmin!UtilDbccCheckDatabase+0x994   |  (00007ffd`9ab0ffd0)   sqlmin!UtilDbccRetainReplica
(00007ffd`9ab0cfc0)   sqlmin!DbccCheckDB+0x22d   |  (00007ffd`9ab0d380)   sqlmin!DbccCheckFilegroup
(00007ffd`777379c0)   sqllang!DbccCommand::Execute+0x193   |  (00007ffd`77737d70)   sqllang!DbccHelp

ये स्टैकट्रैक्स मैक्स के उत्तर के साथ सहसंबंधित हैं, जो यह दर्शाता है कि CHECKDB हेक्टन तालिकाओं की उपस्थिति के बावजूद एक आंतरिक स्नैपशॉट का उपयोग कर रहा है।

मैंने पढ़ा है कि स्नैपशॉट अवांछित लेनदेन को पुनर्प्राप्त करने के लिए वसूली करते हैं :

एक नए बनाए गए डेटाबेस स्नैपशॉट में Uncommitted लेन-देन को वापस रोल किया जाता है क्योंकि स्नैपशॉट बनाए जाने के बाद डेटाबेस इंजन पुनर्प्राप्ति चलाता है (डेटाबेस में लेनदेन प्रभावित नहीं होते हैं)।

लेकिन यह अभी भी स्पष्ट नहीं करता है कि लॉग फ़ाइल का एक बड़ा हिस्सा अक्सर मेरे उत्पादन परिदृश्य में क्यों पढ़ा जाता है (और कभी-कभी यहां प्रदत्त रिप्रो में भी)। मुझे नहीं लगता कि मेरे ऐप में दिए गए समय पर मेरे पास कई इन-फ्लाइट लेनदेन हैं, और निश्चित रूप से यहाँ कोई भी रेप्रो नहीं है।

sql-server  sql-server-2016  transaction-log  dbcc-checkdb 
— जोश डारनेल
स्रोत

जवाबों:

10

भले ही SQL सर्वर दस्तावेज़ीकरण बताता है कि "इन-मेमोरी" तालिकाओं वाले डेटाबेस स्नैपशॉट का समर्थन नहीं करते हैं, फिर भी "आंतरिक" स्नैपशॉट के लिए आवश्यक है, DBCC CHECKDBक्योंकि चेकडैब ऑपरेशन इन-मेमोरी टेबल को नहीं छूता है, और स्नैपशॉट केवल परिवर्तन को कैप्चर करता है। ऑन-डिस्क तालिकाओं पर।

संभवतः, Microsoft ने इन-मेमोरी टेबल के साथ डेटाबेस पर उपयोगकर्ता-निर्मित स्नैपशॉट को रोकने के लिए चुना क्योंकि उन्हें स्नैपशॉट के लिए इन-मेमोरी संरचनाओं को डुप्लिकेट करने की आवश्यकता होगी ताकि स्नैपशॉट वास्तव में सामान्य, उपयोगकर्ता-केंद्रित, अर्थ से पूर्ण स्नैपशॉट हो। एक स्नैपशॉट के लिए इन-स्मृति टेबल डुप्लिकेट आसानी से सर्वर स्मृति से बाहर चलाने, जो कर सकता है नहीं एक अच्छी बात ™

आप अपने लिए साबित कर सकते हैं कि डेटा फ़ोल्डर को देखकर एक आंतरिक DBCC स्नैपशॉट बनाया जा रहा है, जहां प्राथमिक डेटाबेस डेटाफ़ाइल दौड़ते समय रहता है DBCC CHECKDB। यदि एक आंतरिक स्नैपशॉट बनाया गया है, तो आपको एक फ़ाइल दिखाई देगी जिसका नाम LogFileRead_Test.mdf_MSSQL_DBCC7( 7भिन्न हो सकता है - यह आपके डेटाबेस के लिए डेटाबेस आईडी का प्रतिनिधित्व करता है)।

स्नैपशॉट फ़ाइल बन जाने के बाद, SQL सर्वर के लिए डेटाबेस पर रिकवरी को चलाने के लिए आवश्यक है कि उसे एक सुसंगत स्थिति में लाया जाए जिसे चलाने के लिए DBCC CHECKDB की आवश्यकता हो। कोई भी लॉग-रीडिंग क्रिया जो आप देख रहे हैं, उस पुनर्प्राप्ति प्रक्रिया के परिणामस्वरूप होने की संभावना है। मैंने कई DBCC CHECKDBकार्यों के आउटपुट की जांच के लिए एक त्वरित रिग बनाया , जो यह साबित करता है कि अगर चेकडब्स के बीच कोई लेनदेन नहीं है, तो लॉग-फाइल रीड नहीं हैं।

USE master;
SET IMPLICIT_TRANSACTIONS OFF;
USE [master];
IF (DB_ID(N'LogFileRead_Test') IS NOT NULL) 
BEGIN
    ALTER DATABASE [LogFileRead_Test]
    SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE [LogFileRead_Test];
END

CREATE DATABASE [LogFileRead_Test]
ALTER DATABASE [LogFileRead_Test]
MODIFY FILE
(
    NAME = LogFileRead_Test_log,
    SIZE = 128MB
);

ALTER DATABASE [LogFileRead_Test]
ADD FILEGROUP [LatencyTestInMemoryFileGroup] CONTAINS MEMORY_OPTIMIZED_DATA;
ALTER DATABASE [LogFileRead_Test]
ADD FILE 
(
    NAME = [LatencyTestInMemoryFile], 
    FILENAME = 'C:\temp\LogFileRead_Test_SessionStateInMemoryFile'
) TO FILEGROUP [LatencyTestInMemoryFileGroup];
GO

USE LogFileRead_Test;

CREATE TABLE [dbo].[InMemoryStuff] (
    [InMemoryId]   NVARCHAR (88)    COLLATE Latin1_General_100_BIN2 NOT NULL,
    [Created]     DATETIME2 (7)    NOT NULL,
    CONSTRAINT [PK_InMemoryStuff_InMemoryId] 
    PRIMARY KEY NONCLUSTERED 
    HASH ([InMemoryId]) WITH (BUCKET_COUNT = 240)
)
WITH (MEMORY_OPTIMIZED = ON);

;WITH src AS (
    SELECT n.Num
    FROM (VALUES (0), (1), (2), (3), (4), (5), (6), (7), (8), (9))n(Num)
)
INSERT INTO [dbo].[InMemoryStuff] (InMemoryId, Created) 
SELECT 'Description' + CONVERT(varchar(30)
        , ((s1.Num * 10000) 
         + (s2.Num * 1000) 
         + (s3.Num * 100) 
         + (s4.Num * 10) 
         + (s5.Num)))
    , GETDATE()
FROM src s1
    CROSS JOIN src s2
    CROSS JOIN src s3
    CROSS JOIN src s4
    CROSS JOIN src s5;
USE master;

DECLARE @cmd nvarchar(max);
DECLARE @msg nvarchar(1000);
DECLARE @l int;
DECLARE @m int;
SET @m = 10;
SET @l = 1;
IF OBJECT_ID(N'tempdb..#vfs', N'U') IS NOT NULL DROP TABLE #vfs;
CREATE TABLE #vfs (
    vfs_run int NOT NULL IDENTITY(1,1) PRIMARY KEY CLUSTERED
    , collection_time datetime2(7)
    , num_of_reads bigint
    , num_of_bytes_read bigint
);

WHILE @l <= @m 
BEGIN
SET @msg = N'loop ' + CONVERT(nvarchar(10), @l);
RAISERROR (@msg, 0, 1) WITH NOWAIT;

SET @cmd = 'USE [LogFileRead_Test];
-- grab a baseline of virtual file stats to be diff''d later
select f.num_of_reads, f.num_of_bytes_read
into #dm_io_virtual_file_stats
from sys.dm_io_virtual_file_stats(default, default) f
where database_id = db_id(''LogFileRead_Test'') and file_id = FILE_IDEX(''LogFileRead_Test_log'');

DBCC CHECKDB ([LogFileRead_Test]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;

-- grab the latest virtual file stats, and compare with the previous capture
select f.num_of_reads, f.num_of_bytes_read
into #checkdb_stats
from sys.dm_io_virtual_file_stats(default, default) f
where database_id = db_id(''LogFileRead_Test'') and file_id = FILE_IDEX(''LogFileRead_Test_log'');

select 
        collection_time = GETDATE() 
        , num_of_reads = - f.num_of_reads + t.num_of_reads
        , num_of_bytes_read = - f.num_of_bytes_read + t.num_of_bytes_read
into #dm_io_virtual_file_stats_diff
from #dm_io_virtual_file_stats f, #checkdb_stats t;

--drop table #checkdb_stats;
--drop table #dm_io_virtual_file_stats;

-- CHECKDB ignored my comment
select collection_time, num_of_reads, num_of_bytes_read
from #dm_io_virtual_file_stats_diff d
order by d.collection_time;

--drop table #dm_io_virtual_file_stats_diff;
';
INSERT INTO #vfs (collection_time, num_of_reads, num_of_bytes_read)
EXEC sys.sp_executesql @cmd;

SET @l += 1;
END

USE master;
SET @cmd = 'USE [master];
ALTER DATABASE [LogFileRead_Test]
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [LogFileRead_Test];
';
EXEC sys.sp_executesql @cmd;

SELECT *
FROM #vfs
ORDER BY vfs_run;

परिणाम:

╔═════════╦═════════════════════════════╦═════════ ═════╦═══════════════════╗
║ vfs_run _ collection_time of num_of_reads of num_of_bytes_read r
╠═════════╬═════════════════════════════╬═════════ ═════╬═══════════════════╣
║ 1 ║ 2018-04-06 15: 53: 37.6566667 ║ 1 15 491520 ║
║ 2 ║ 2018-04-06 15: 53: 37.8300000 ║ 0 ║ 0 ║
║ 3 ║ 2018-04-06 15: 53: 38.0166667 ║ 0 ║ 0 ║
║ 4 ║ 2018-04-06 15: 53: 38.1866667 ║ 0 ║ 0 ║
║ 5 ║ 2018-04-06 15: 53: 38.3766667 ║ 0 ║ 0 ║
║ 6 ║ 2018-04-06 15: 53: 38.5633333 ║ 0 ║ 0 ║
║ 7 ║ 2018-04-06 15: 53: 38.7333333 ║ 0 ║ 0 ║
║ 8 ║ 2018-04-06 15: 53: 38.9066667 ║ 0 ║ 0 ║
║ 9 ║ 2018-04-06 15: 53: 39.0933333 ║ 0 ║ 0 ║
║ 10 ║ 2018-04-06 15: 53: 39.2800000 ║ 0 ║ 0 ║
╚═════════╩═════════════════════════════╩═════════ ═════╩═══════════════════╝

इसके अलावा, परीक्षण तालिका में डेटा सम्मिलित करने के लिए RBAR दृष्टिकोण का उपयोग करने के बजाय, आप एक सरल सेट-आधारित दृष्टिकोण का उपयोग करना चाह सकते हैं, जैसे नीचे:

;WITH src AS (
    SELECT n.Num
    FROM (VALUES (0), (1), (2), (3), (4), (5), (6), (7), (8), (9))n(Num)
)
INSERT INTO [dbo].[InMemoryStuff] (InMemoryId, Created) 
SELECT 'Description' + CONVERT(varchar(30)
     , ((s1.Num * 10000) 
      + (s2.Num * 1000) 
      + (s3.Num * 100) 
      + (s4.Num * 10) 
      + (s5.Num)))
    , GETDATE()
FROM src s1
    CROSS JOIN src s2
    CROSS JOIN src s3
    CROSS JOIN src s4
    CROSS JOIN src s5;

मेरे परीक्षण में, यह तालिका को 3 सेकंड से कम समय में भर देता है, जबकि आरबीएआर दृष्टिकोण में लंबा समय लगता है । इसके अलावा, आपके कोड में अच्छी टिप्पणियों ने मुझे योग्य बनाया।

— मैक्स वर्नन
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.