В тази статия се обсъжда проблем, който възниква по време на заявка за индекс на columnstore с клъстери в Microsoft SQL Server 2014. Тази статия предоставя решение за този проблем.
Обобщена информация
Когато използвате заявка, която сканира индекс на columnstore с клъстери в Microsoft SQL Server 2014, в редки условия може да получите частични резултати от заявката. Този проблем възниква, когато се изпълнява следната операция.
Стъпка 1
SQL инструкцията за преговаряне [вмъкване или ГРУПОВо вмъкване] Вмъква данни в таблица, която има индекс за columnstore с клъстери. По време на тази операция се прилагат следните условия:
-
Когато командата do-SQL достигне прага на rowgroup, той се затваря rowgroup R1, който има сегмент S1.
-
Отсечка S1 сочи към локален речник D1.
-
Командата продължава да вмъква редове в New rowgroup R2.
-
Когато rowgroup R1 се затвори, локалният речник D1 не трябва да бъде затварян. Ако Речникът D1 все още е наличен, можете да го оставите отворен и да го използвате повторно за новия rowgroup R2.
Стъпка 2
Ако командата do-SQL завърши ненормално или е отменена, преди да затвори новия rowgroup R2, важат следните условия:
-
Промените в Columnstore метаданни възникват в подсделки, които се извършват независимо от външната транзакция.
-
В този момент rowgroup R1 се запазва в таблицата System в "под конструкция" или НЕВИДИМ щат, а препратките към сегмент S1
-
Няма ред, създаден в таблицата System за речник D1. Това е така, защото командата do-SQL никога няма възможност да затвори съществуващия ред. Следователно съществуващият ред продължава.
Стъпка 3
В типично положение, ако задачата за фон на кортеж се стартира след приключването на изпълнение на SQL инструкцията, фонът ще премахне невидимия rowgroup R1 и отсечката S1. Ако в момента се стартира нова SQL инструкция и създаде rowgroup R3, който има нов сегмент S3, който изисква нов локален речник, не можете да използвате повторно вътрешния ИД на речник D1. Това е така, защото състоянието в паметта на columnstore проследява ИД на речника, които се използват. Следователно segment S3 ще препраща към нов речник D2.Забележка Условието в тази стъпка е често срещано условие. Следователно не възниква корупция.
Стъпка 4
Ако SQL Server изгуби състоянието на в паметта на речник D1, преди да се приложи задачата на кортеж инициатор (и да се изпълнява, както е описано в стъпка 3), възниква проблемът, описан в тази статия.Забележки
-
Това събитие възниква поради някоя от следните причини:
-
SQL Server преживява претоварване с памет и съдържанието в паметта на речник D1 се изважда от паметта.
-
Стартира се екземплярът на SQL Server.
-
Базата данни, която съдържа индекса с клъстери columnstore, отива офлайн и след това се връща онлайн.
-
-
След като някое от тези събития се случи и SQL Server презареди структурите в паметта, няма запис, който е съществувал речник D1 и вътрешен ИД. Това е така, защото Речникът D1 не е запазен в системните таблици, когато командата за транзакция за SQL е завършила или conceled.
-
Ако задачата за заден план на кортеж се стартира в този момент, не се появяват грешки, тъй като важат условията, описани в стъпка 3.
-
Ако се създаде нов rowgroup R3, преди да започне задачата за заден фон на кортеж (на предишния елемент от водещите символи), SQL Server присвоява един и същ вътрешен ИД към нов речник D1 и препраща към речник D1 за сегмент S3 в rowgroup R3.
-
Когато задачата за фон на кортеж се стартира след предходното действие, тя пада невидим rowgroup R1 и отсечките му S1 заедно с новия речник D1. Това се случва, защото инициаторът на кортеж счита, че нов речник D1 и първоначалният речник D1, че препратките S1 са еднакви.Забележка Когато възникне това условие, не можете да задавате заявка за съдържанието на rowgroup R3.
Решение
Проблемът е коригиран първо в следните сборни актуализации за SQL Server:
Кумулативна актуализация 1 за SQL server 2014 SP1 кумулативна актуализация 8 за SQL Server 2014Корекцията за този проблем също е включена в следните общи актуализации за изданието за разпространение (GDR):
Актуализация на защитата за SQL Server 2014 QFE Тази актуализация включва кумулативна актуализация 8, тази важна корекция и необходимите MS15-058 актуализации на защитата.Актуализация на защитата за SQL Server 2014 GDR Тази актуализация включва тази важна корекция и сборни корекции на защитата чрез MS15-058.Актуализация за незащитеност за SQL Server 2014 Service Pack 1 GDR Тази актуализация включва само тази важна корекция.
Всяка нова сборна актуализация за SQL Server съдържа всички поправки и всички корекции на защитата, които са били включени в предишната сборна актуализация. Вижте последните сборни актуализации за SQL Server:
Повече информация
Съобщения за грешкаВ текущо засегната база данни, ако изпълнявате DBCC CHECKDB, след като приложите тази корекция, получавате следното съобщение за грешка:
MSG 5289, Level 16, State 1, Line 1 с клъстери columnstore index ' CCI ' в таблица t ' има една или повече стойности на данни, които не съответстват на стойностите на данните в речник. Възстановяване на данни от архивно копие.
В текущо засегната база данни, когато изпълните заявка, която сканира засегнатите таблици, след като приложите тази корекция, получавате следното съобщение за грешка:
MSG 5288, Level 16, State 1, Line 1 Columnstore INDEX има една или повече стойности на данни, които не съответстват на стойностите на данните в речник. Изпълнете DBCC CHECKDB за повече информация.
Ако получите тези грешки, можете да запишете неповредените данни, като групово експортирате данните на незасегнати колони/rowgroups и след това да презаредите данните, след като сте изпуснали или създадете индекса на columnstore. Трябва да разрешите проследяването на флага 10207, за да потиснете грешката 5288 и да се върнете към предишното поведение за прескачане на повредени rowgroups. Забележка Съобщения за грешка 5288 и 5289 са генерирани за този rowgroup R3, който има сегмент S3. Флаг за проследяване 10207 се използва за извличане на сегменти от rowgroup R3, които не са засегнати от липсващия речник D1.
Заявка за засегнатите бази данниЗа да определите дали базата данни, която съдържа индексите на columnstore, вече е повлияна от този проблем, изпълнете следната заявка:
select object_name(i.object_id) as table_name, i.name as index_name, p.partition_number, count(distinct s.segment_id) as damaged_rowgroups from sys.indexes i join sys.partitions p on p.object_id = i.object_id and p.index_id = i.index_id join sys.column_store_row_groups g on g.object_id = i.object_id and g.index_id = i.index_id and g.partition_number = p.partition_number join sys.column_store_segments s on s.partition_id = p.partition_id and s.segment_id = g.row_group_id where i.type in (5, 6) and s.secondary_dictionary_id <> -1 and g.state_description = 'COMPRESSED' and s.secondary_dictionary_id not in ( select dictionary_id from sys.column_store_dictionaries d where d.hobt_id = p.hobt_id and d.column_id = s.column_id ) group by object_name(i.object_id), i.name, p.partition_number
Забележки
-
Трябва да изпълните тази заявка за всяка база данни, която съдържа columnstore индекси на сървъра, на който се изпълнява SQL Server. Празен набор от резултати показва, че базата данни не е засегната.
-
Извършете тази заявка през период, в който няма дейност, която ще създаде нов rowgroups или промяна на състоянието на съществуващите rowgroups. Например следните дейности могат да променят състоянието на rowgroups: index компилация, реорганизация на индекси, групово Вмъкване, кортеж на Movers за компресиране на Делта Stores. Преди да изпълните заявката, можете да забраните задачата за кортеж на заден фон, като използвате флаг за проследяване на 634. Използвайте тази команда, за да забраните задачата за заден фон: DBCC TRACEON (634;-1). След изпълнението на заявката, не забравяйте да активирате повторно фоновата задача с помощта на командата: DBCC TRACEOFF (634;-1). Също така се уверете, че няма ГРУПОВо вмъкване/БКП/за ИЗБИРАНЕ в командите за вмъкване на данни в таблиците, използващи индекс на columnstore, докато се изпълнява тази заявка. Препоръчително е да използвате тези стъпки, за да попречите на заявката да върне FALSE-позитиви.
Състоянието
Microsoft потвърди, че това е проблем в продуктите на Microsoft, които са посочени в секцията "важи за".
