Поправки за проблем с възстановяването на онлайн индекса на SQL Server 2012 и 2014

Има грешка при регресия в SQL Server 2012 и SQL Server 2014, при която, ако възстановите индекс онлайн паралелно и също така изпитате фатална грешка като изчакване на заключване, може да изпитате загуба или повреда на данни . Това би трябвало да е сравнително рядък сценарий (Фил Брамър има просто повторение в Connect #795134), но загубата на данни е загуба на данни и аз не съм готов да залагам. Поправката е описана в KB #2969896 :КОРЕКЦИЯ:Загуба на данни в клъстериран индекс възниква, когато стартирате онлайн индекс за изграждане в SQL Server 2012.

Не всеки трябва да се тревожи за този проблем. Ако не използвате Enterprise (или еквивалентно) издание, не можете да извършвате паралелно или онлайн преизграждане на първо място (и вероятно има някои хора в Enterprise, които не възстановяват или не възстановяват онлайн). Ако имате MAXDOP за целия екземпляр зададен на 1, те не могат да вървят паралелно, освен ако не го замените на ниво оператор. Но ако сте на 2012 или 2014, работите с подходящо издание и вашите онлайн преизграждания могат да вървят паралелно, вие сте уязвими към този проблем.

Както споменах по-горе, този проблем може да се прояви в SQL Server 2012 RTM, Service Pack 1 и дори Service Pack 2, който беше пуснат на 10 юни. не включва тази корекция или която и да е от корекциите от SP1 CU #10 или #11. Блогвах за това тук. Клонът на RTM официално е извън поддръжка, така че няма да видите решение там. Проблемът може да възникне и в SQL Server 2014.

Вече има налични кумулативни актуализации за SQL Server 2012 Service Pack 1 и 2, както и SQL Server 2014. Кратко обобщение на опциите, които препоръчвам:

Решения за актуалната корекция/отклонение на CU

Тъй като всички засегнати клонове (е, с изключение на 2012 RTM) имат актуална корекция при поискване и/или кумулативна актуализация, която решава проблема, лесният отговор е просто да инсталирате съответната актуализация. Въпреки това, може да сте в сценарий, при който политиката на вашата компания или циклите на тестване ви пречат да внедрите тези актуализации бързо или може би някога. И така, какви други опции имате?

• Можете да спрете да извършвате повторно изграждане, докато не е наличен нов сервизен пакет за вашия клон (може би можете просто да се придържате към REORGANIZE за сега). За съжаление, ако сте в компания "само сервизен пакет", вашите възможности са много ограничени:можете да се борите по-усилено за промяна на тази политика или можете да изчакате SQL Server 2012 Service Pack 3 (което може да отнеме дълго време или може просто никога не идвайте – вижте ЧЗВ #21 тук) или SQL Server 2014 Service Pack 1 (който вероятно няма да видим преди 2015 г.).
• Можете да зададете max degree of parallelism за целия екземпляр до 1, но това може да има отрицателен ефект върху останалата част от вашето работно натоварване – помислете за неща като многонишков DBCC, паралелни заявки срещу или между разделени таблици и други операции, при които може да искате да намалите паралелизма, но не и да го премахнете напълно. Също така, тази настройка няма да повлияе на онлайн възстановяване с, да речем, изрично MAXDOP = 8 твърдо кодиран в командата, тъй като това ще отмени sp_configure настройка.
  
• Можете да добавите WITH (MAXDOP = 1) опция ръчно за всички ваши команди за възстановяване. (Забележка:не е нужно да правите това за XML индекси, тъй като те по своята същност се изпълняват еднонишкови, но аз просто бих го приложил към всички преизграждания за последователност и за избягване на всяка ненужна условна логика.)
  
• Можете да настроите задачите си за поддръжка на индекса да се изпълняват като конкретно влизане и след това да използвате Resource Governor, за да създадете група за работно натоварване, която ограничава MAX_DOP на това влизане до 1, независимо какво правят. Имам пример за това в бялата книга от 2008 г., която написах с Борис Баришников, Използване на управителя на ресурсите, в раздела, озаглавен „Ограничаване на паралелизма за интензивни фонови работни места“.
  
• Ако използвате решението за поддръжка на индекси на Ola Hallengren, можете да добавите @MaxDop параметър за вашите извиквания към dbo.IndexOptimize :
  

  EXEC dbo.IndexOptimize
      /* other parameters */
      @MaxDop = 1;

• Ако използвате SQL Sentry Fragmentation Manager, можете да диктувате нивото на MAXDOP да използвате под Настройки – и можете да направите това за цялото предприятие, за екземпляр, за база данни или дори за отделен индекс (в този случай вероятно бихте искали да зададете това за екземпляр, за всички екземпляри без налична корекция):
  

  
  Настройки на Fragmentation Manager за екземпляра (вляво) и индивидуален индекс (вдясно).

• Ако използвате планове за поддръжка за възстановяването на вашия индекс, ще трябва да ги промените, за да използвате задачи за изпълнение на T-SQL оператори и да напишете своя ALTER INDEX ... WITH (ONLINE = ON, MAXDOP = 1); команди ръчно (така че може и да преминете към автоматизирано решение). Вижте, задачата за възстановяване на индекса няма изложено свойство за MAXDOP , въпреки че е искано многократно (последно през 2012 г., от Алберто Морило и още през 2006 г. от Линчи Ший). И просто погледнете всички тези други полезни свойства, които те излагат, като AdvSortInTempdb , ObjectTypeSelection и TaskAllowesDatbaseSelection [sic!]:
  

  
  Всички тези опции, но все още няма лек за MAXDOP.