análise de arquivo de despejo aparece sqlserver
fundo
informações de log do banco verificação de rotina para um item, descobriu que despejo mais frequente ocorre, o risco de que precisamos de uma intervenção urgente, a causa do problema a ser analisado, como sério, e reparação;
ambiente de servidor são as seguintes:
Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 out 2016 18:17:30 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) no Windows Server 2012 R2 Datacenter 6.3 <X64> (criação 9600:) (do hipervisor)
passos
Primeiro DUMP informações primeira vez, para verificar o número de vezes que aparecem;
select *from sys.dm_server_memory_dumps
Não foram encontrados 160 vezes, mais recentemente em 08 de outubro de 2019, a seleção das informações mais recente despejo é a seguinte:
Ver SQLDump0160.txt encontrar as seguintes informações, que pode determinar a presença de despejo razão é devido ao índice de corrupção, mas também saber o que desencadeou a questão roteiro;
Use
windbg
SQLDump1060.mdump análise da seguinte forma:
STACK_TEXT: 0000003f`8511a180 00007ff7`ba549c9c: 00000000 ` 00011000 00007ffe`21973c10 0000003f`8511a2c4 0000003f` 00000004 : KERNELBASE RaiseException + 0x68 0000003f`8511a260 00007ffe`22e802c6: 00007ff7`ba58bd80 00007ffe`2d101118 00000000 ` 00000000 0000003f`8511a458: sqlservr CDmpDump: : Dump + 0x4C 0000003f`8511a2a0 00007ffe`2397c411: 00007ff7`ba58bd80 00000000 ` 00000460 00000000 ` 00000000 00007ffe`2d101616: sqllang SQLDumperLibraryInvoke +! 0x1f6 0000003f`8511a2e0 00007ffe`2397ce94: 00000000 `00,021164 millions 00000000 `58f1f705 00000000 ` 00000000 00007ffe`24cdfe30: sqllang SQLLangDumperLibraryInvoke + 0x161 0000003f`8511a390 00007ffe`2394cd0b: 0000004b`00f94a70 00000000 `58f1f705 0000004b`00f94a70 0000004b`00f95910: sqllang CImageHelper :: DoMiniDump +! 0x475 0000003f`8511a5a0 00007ffe`2586da80: 0000005b `23a228a0 0000005b`23a228a0 0000003f`8511c330 00000000 ` 000000bf: sqllang stackTrace + 0x9db 0000003f`8511bfc0 00007ffe`2586dc42: 00007ffe`272f30a0 00000043 `f2488fc0 00000000 ` 00000000 00007ffe`24f7ac2d: sqlmin IndexFailure_ErrorAbort + 0x1d1 0000003f`8511c2d0 00007ffe` 25109860 : 00000046 ` 00000005 00000043 ` f2488fc0 00000000 ` 00000003 0000003f`58f1f705: sqlmin CPerIndexMetaQS :: ErrorAbort + 0xC3 0000003f`8511c330 00007ffe`22091de7: 00000043 ` f2488fc0 00000046 ` 00000001 0000003f`8511c420 00000043 ` 08f72bc8: sqlmin CValRowMult :: SetDataX + 0x386 0000003f`8511c400 00007ffe`24f41c29: 00000000 ` 00000001 00000043 ` 08f72bc0 00000000 ` 00000000 00000043`08f72150: sqltses CEsExec :: GeneralEval4 +! 0xe7 0000003f`8511c4d0 00007ffe`24f05caf: 0000003f`8511c7a9 00000043 ` 08f72bc0 00000000 ` 00000000 00000041 ` 65c78870: sqlmin CQScanUpdateNew :: getRow + 0x314 0000003f`8511c580 00007ffe`229365d7: 00000000 ` 00000000 00000000 ` 00000000 7fffffff`ffffffff 00007ffe`229378a2: sqlmin CQueryScan :: getRow + 0x81 0000003f`8511c5b0 00007ffe`22c79a79: 00000043 `08f72150 0000004b`00f94a70 00000000 ` 00000000 00000000 ` 00000000: Sqllang CXStmtQuery :: ErsqExecuteQuery + 0x4dc 0000003f`8511c730 00007ffe`22c7983c: 0000003f`eb082101 0000004e`34f25a00 00000000 ` 00000000 0000004b`00f94a01: sqllang CXStmtDML :: XretDMLExecute + 0x3a3 0000003f`8511c810 00007ffe`235a0de2: 0000004b`00f94a70 0000004b` 46002560 0000003f` 8511c950 00000041 `83cbe8f0: sqllang CXStmtDML :: XretExecute + 0xb0 0000003f`8511c840 00007ffe`22d172af: 0000004b` 46002000 00000000 ` 00000000 00000000 ` 00000000 0000004b`00f94a00: sqllang CMsqlExecContext :: ExecuteStmts < 1 , 0 > +0x1603 0000003f`8511cf20 00007ffe` 22932041 : 00000041 `83cbe7c8 00000000 ` 00000000 00000041 `83cbe700 00000000 ` 00000000 : sqllang CMsqlExecContext :: fExecute + 0xaa5 0000003f`8511d250 00007ffe`2363d83d: 00000000 ` 00000000 00000000 ` 00000007 00000041 `83cbec20 00000000 ` 00000000 : sqllang! CSQLSource :: Execute + 0x983 0000003f`8511d3f0 00007ffe`2363d241: 00000041 `83cbec20 00000041 ` 83cbe7c8 00000041`0439ab80 00000000 ` 00000000 : sqllang CStmtExecProc :: XretLocalExec + 0x26e 0000003f`8511d470 00007ffe`23639f98: 00000000 ` 00000000 00007ffe`22a99773 00000041 ` 83cbe710 00000000 ` 00000000 : sqllang CStmtExecProc :: XretExecExecute + 0x481 0000003f`8511dc20 00007ffe`235a0de2: 00000041 ` 83cbe560 0000004b`00f94a70 00000000 ` 00000002 0000004b`00f94b08: sqllang CXStmtExecProc :: XretExecute + 0x38 0000003f`8511dc60 00007ffe`22d172af: 00000000 ` 00002000 0000004b`00fac99000000000 ` 00000000 00007ffe` 00000011 : sqllang CMsqlExecContext :: ExecuteStmts < 1 , 0 > + 0x1603 0000003f`8511e340 00007ffe` 22932041 : 0000004b`00fac890 00000000 ` 00000000 0000004b`00fac800 00000000 ` 00000000 : sqllang CMsqlExecContext :: fExecute + 0xaa5 0000003f`8511e670 00007ffe`2293a82b: 00000000 ` 00000000 00007ffe` 00000007 00000000 ` 00000000 0000004b` 00000000 : sqllang CSQLSource :: Execute + 0x983 0000003f`8511e810 00007ffe` 22941542 : 0000004b`00fea700 0000004b`00fea430 00000000 ` 00000000 0000004b`00fea400: sqllang process_request + 0xe61 0000003f`8511ede0 00007ffe`229410a3: 00000000 ` 00000000 0000003f`eb082148 0000003f`eb082148 00000000 ` 00000000 : sqllang process_commands_internal + 0x2df 0000003f` 8511ee60 00007ffe`21bc5bfd: 0000004b`00febb20 00007ffe`21bc3add 0000003f`ffffffff 00000000 `000027ae: process_messages sqllang +! 0x253 0000003f`8511f070 00007ffe`21bc58f5: 0000003f`eb082148 0000003f`eb082108 0000003f`eb082190 ffffffff` 00000000: Sqldk SOS_Task :: Param :: Execute +! 0x231 0000003f`8511f670 00007ffe`21bc554d: 0000004e` 91220040 0000003f`8511f759 0000004e` 91220040 0000003f`eb088160: sqldk SOS_Scheduler :: runTask + 0xaa 0000003f`8511f6e0 00007ffe`21bed7c8: 00000000 ` 00000000 0000003f` eb088160 0000003f`eb088160 00007ffe`21bedf00: sqldk SOS_Scheduler :: ProcessTasks + 0x3cd 0000003f`8511f7c0 00007ffe`21bedb10: 0000003f`eb088160 00000000 ` 00000000 0000003f`eb088160 000105a0`65812f97: sqldk SchedulerManager :: WorkerEntryPoint + 0x2a1 0000003f`8511f890 00007ffe`21bedcd7: 0000003f `eb088160 0000003f`8511f930 0000004e`91080280 0000003f`e7cd0590: sqldk SystemThread :: RunWorker + 0x8F 0000003f`8511f8c0 00007ffe`21bed9f8: 0000004e` 91080230 00000000 ` 00000000 00000000 ` 00000000 0000004e` 91080170 : sqldk SystemThreadDispatcher :: ProcessWorker + 0x2de 0000003f`8511f970 00007ffe`2f9f13d2: 00000000 ` 00000000 00000000 ` 00000000 0000003f`e7cd0590 0000003f`e7cd0590: sqldk SchedulerManager :: ThreadEntryPoint + 0x1d8 0000003f`8511fa20 00007ffe`2fd454f4: 00007ffe`2f9f13b0 00000000 ` 00000000 00000000 ` 00000000 00000000 ` 00000000 : kernel32 BaseThreadInitThunk + 0x22 0000003f`8511fa50 00000000 ` 00000000 : 00000000 00000000 00000000 ` ` 00000000 00000000 00000000 00000000 ` ` 00000000 : ntdll RtlUserThreadStart +! 0x34
Seguro para pesquisar se há uma correção oficial documentação de referência e similares.
Ver a última versão do servidor SQL do documento correspondente ao de 2014, 2016 e estamos usando o padrão dos documentos acima questão deveria ter sido fixada; follow-up nos 2016 do
SP2
problemas descrevendo reparação relacionados com este caso também não é encontrado na lista;
Uma vez que foi determinado que o índice está danificado, então a próxima pergunta é determinar qual tabela, o que índices danificados.
Através do acima
SQLDump0160.txt sabemos que a implementação do procedimento armazenado despejo [sfa_p_updatestorestatus] causada pela visualização do código do procedimento armazenado da seguinte forma:
-- =============================================
-- Author: <Author,,Name>
-- Create date: <Create Date,,>
-- Description: <Description,,>
-- =============================================
CREATE PROCEDURE [dbo].[sfa_p_updatestorestatus]
-- Add the parameters for the stored procedure here
@guid varchar(50) ,
@status int,
@xwUserNumber int
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
UPDATE sfa_t_store set status=@status,updateop=@xwUserNumber,updatetime=getdate() where guid=@guid
END
Descobriram que o procedimento armazenado é simples update] [sfa_t_store a mesa, em seguida, levou o problema é ainda exame direto mais simples da tabela pode ser. Você pode precisar checkdb queria o trabalho;
dbcc checktable('dbo.sfa_t_store') 消息 8951，级别 16，状态 1，第 7 行
表错误: 表 'sfa_t_store' (ID 1492252421)。数据行在索引 'IX_sfa_t_store_saleareaidGuid' (ID 3)中没有匹配的索引行。与以下数据行匹配的索引行的键可能丢失或无效:
消息 8955，级别 16，状态 1，第 7 行
数据行(1:1132194:0)由(storeid = 419448)标识，索引值为“saleareaid = 'D7B30A46-25F9-41C6-AECB-5838915B0EF8' and guid = 'B777C7B2-1079-4483-8CE1-427379BD9D9C' and status = 1 and storeid = 419448”。
消息 8951，级别 16，状态 1，第 7 行
表错误: 表 'sfa_t_store' (ID 1492252421)。数据行在索引 'IX_sfa_t_store_saleareaidGuid' (ID 3)中没有匹配的索引行。与以下数据行匹配的索引行的键可能丢失或无效:
消息 8955，级别 16，状态 1，第 7 行
数据行(1:1132193:11)由(storeid = 419446)标识，索引值为“saleareaid = 'D7B30A46-25F9-41C6-AECB-5838915B0EF8' and guid = '7FCC1380-EE39-46D4-A4F7-A48466E674D1' and status = 1 and storeid = 419446”。
消息 8951，级别 16，状态 1，第 7 行
表错误: 表 'sfa_t_store' (ID 1492252421)。数据行在索引 'IX_sfa_t_store_saleareaidGuid' (ID 3)中没有匹配的索引行。与以下数据行匹配的索引行的键可能丢失或无效:
消息 8955，级别 16，状态 1，第 7 行
数据行(1:1132193:12)由(storeid = 419447)标识，索引值为“saleareaid = 'F1CCE355-387A-4CB3-A878-F33166E913E4' and guid = '45805C83-EC07-40CB-A810-4D6E2EBFF299' and status = 1 and storeid = 419447”。
sfa_t_store的 DBCC 结果。
对象 'sfa_t_store' 的 105452 页中有 1351236 行。
CHECKTABLE 在表 'sfa_t_store' (对象 ID 1492252421)中发现 0 个分配错误和 3 个一致性错误。
对于由 DBCC CHECKTABLE (*******.dbo.sfa_t_store)发现的错误，repair_rebuild 是最低的修复级别。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
A partir dos resultados dos exames, [são] danos IX_sfa_t_store_saleareaidGuid, a boa notícia é que o índice não é um índice de cluster, em seguida, a próxima ação é excluir o novo índice pode ser re-fix índice de foco semelhante pode referir-se a
questionar o reparo página prática
drop index IX_sfa_t_store_saleareaidGuid on dbo.sfa_t_storeCREATE NONCLUSTERED INDEX [IX_sfa_t_store_saleareaidGuid] ON [dbo].[sfa_t_store]
(
[saleareaid] ASC,
[guid] ASC,
[status] ASC
)
INCLUDE ( [storecode],
[storename],
[storetype],
[contactname],
[contactphone],
[authorityKeywords]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
Verificar novamente a tabela é normal;
