Microsoft разпространява корекциите за Microsoft SQL Server 2005, 2008 и 2008 R2 като един файл, който може да се изтегли. Тъй като корекциите са кумулативни, всяка нова версия съдържа всички горещи поправки и всички корекции на защитата, които са били включени в предишните SQL Server 2005, 2008 и 2008 R2 корекция издание.
Симптоми
Обмислете следния сценарий:
-
Инсталирате Microsoft SQL Server 2005, Microsoft SQL Server 2008 или Microsoft SQL Server 2008 R2 на компютър.
-
Една или повече от базите данни са в пълния или групово регистриран модел за възстановяване.
-
Първоначалният размер на регистрационния файл на транзакциите за базата данни е малък. Обаче файлът на транзакцията нараства.
-
Нарастването на нарастването на автоматичното нарастване на регистрационния файл на транзакциите е конфигурирано с малък размер. Например нарастването на нарастването на автоматичното нарастване е конфигурирано на един мегабайт или на един процент. Или можете да увеличите регистрационния файл на транзакциите с помощта на малък ръчен растеж.
-
Регистрационният файл на транзакциите нараства с малка стъпка на нарастване. След известно време регистрационният файл на транзакциите е голям.
Например регистрационният файл на транзакциите нараства от сто мегабайта до десет гигабайта. Регистрационният файл на транзакциите нараства с един мегабайт във всяко нарастване.
В този случай може да изпитате следните проблеми:
-
Възстановяването на базата данни е бавно, когато базата данни се стартира, ако има голям обем работа за възстановяване.
Например транзакцията чака за дълго време отворена. Или много транзакции, които са с малък размер, не се извършват, когато SQL Server е изключен или рестартиран. В този случай може да получите грешка за дълго очаквано време за възстановяване във фазата на анализ, във фазата на отмяна или във фазата на връщане. Грешката прилича на следното и се регистрира в регистрационния файл за грешки на SQL Server 2005:Анализът на базата данни "mydatabase" (7) е 0% завършен (остават приблизително 1234 секунди). Това е само информационно съобщение. Не се изисква действие от потребителя.
-
Възстановяването на базата данни е бавно, когато се възстановяват пълен архивен файл на базата данни и допълнителна последователност от регистрационни файлове на транзакциите, ако базата данни бъде подадена онлайн.
Забележка За да пренесете базата данни онлайн по време на операцията за възстановяване, използвайте синтаксиса WITH RECOVERY или WITH STANDBY = <опции> синтаксис. -
Възстановяването на дублиране на база данни е бавно на сървър на партньор в дублиращата двойка.
-
Ходът на агента на четеца на регистрационни файлове за репликация на транзакции е бавен за следните операции:
-
Регистрационният файл на транзакциите на база данни на Publisher се анализира.
-
В база данни за разпространение се добавя команда.
-
Транзакциите са реплицирани.
-
-
Ниска производителност възниква, когато се създава снимка на база данни, ако се регистрират много транзакции или ако регистрационните файлове на транзакциите остават активни за дълго време. Този проблем възниква, защото снимката трябва да изпълни възстановяване и регистрационните файлове на транзакциите трябва да бъдат анулирани.
-
Ниската производителност възниква, когато използвате синтаксиса на DBCC CHECKDB, за да създадете скрита снимка на базата данни, която трябва да възстанови напълно снимката на базата данни, за да изпълните проверките за съгласуваност.
Причина
Тези проблеми възникват, защото виртуални регистрационни файлове (VLFs) в регистрационен файл на транзакциите може да доведе до бавна работа, когато SQL Server сканира през тези VIF файлове по време на следните операции:
-
Възстановяване на база данни
-
Дублиране на база данни
-
Снимка на базата данни
-
Дейности на четеца на регистрационни файлове за репликация на транзакции на база данни
Когато регистрационен файл на транзакциите за база данни се увеличава на малки стъпки по време на екстремни условия на растеж, хиляди до стотици хиляди VLFs присъстват в един набор от регистрационни файлове за транзакциите (.ldf). Обаче голямото нарастване на регистрационните файлове с големи стъпки създава само няколко VLFs за сравнение. Например няколко може да са по-малки от 100 VLFs.
Забележка: VLFs са раздели или сегменти, които се използват вътрешно от SQL Server в регистрационния файл на транзакциите.
Решение
Информация за кумулативна актуализация
SQL Server 2008 R2
Корекцията за този проблем първо е издадена в кумулативна актуализация 6. За повече информация как да получите този сборен пакет за SQL Server 2008 R2 щракнете върху следния номер на статия в базата знания на Microsoft:
2489376 Кумулативен пакет за актуализация 6 за SQL Server 2008 R2 Забележка Тъй като компилациите са кумулативни, всяка нова корекция издание съдържа всички горещи поправки и всички корекции на защитата, които са включени в предишната SQL Server 2008 R2 корекция издание. Препоръчваме да помислите за прилагането на най-новата корекция версия, която съдържа тази актуална корекция. За допълнителна информация щракнете върху следния номер на статия, за да прегледате статията в базата знания на Microsoft:
981356 Компилациите SQL Server 2008 R2, които са издадени след издаването на SQL Server 2008 R2
SQL Server 2008 Service Pack 1
Корекцията за този проблем е издадена първо в сборна актуализация 12 за SQL Server 2008 Service Pack 1.
Забележка Тъй като компилациите са кумулативни, всяка нова корекция версия съдържа всички горещи поправки и всички корекции на защитата, които са включени в предишната SQL Server 2008 корекция издание. Microsoft препоръчва да помислите за прилагането на най-новата корекция издание, което съдържа тази актуална корекция. За допълнителна информация щракнете върху следния номер на статия, за да прегледате статията в базата знания на Microsoft:
970365 Компилации на SQL Server 2008, които са издадени след издаването на SQL Server 2008 Service Pack 1 Microsoft SQL Server 2008 горещи поправки за конкретни SQL Server сервизни пакети. Трябва да приложите актуална корекция за SQL Server 2008 Service Pack 1 за инсталиране на SQL Server 2008 Service Pack 1. По подразбиране всяка актуална корекция, предоставена в SQL Server сервизен пакет е включен в следващия SQL Server сервизен пакет.
SQL Server 2008 Service Pack 2
Корекцията за този проблем е издадена първо в сборна актуализация 2 за SQL Server 2008 Service Pack 2.
Забележка Тъй като компилациите са кумулативни, всяка нова корекция версия съдържа всички горещи поправки и всички корекции на защитата, които са включени в предишната SQL Server 2008 корекция издание. Microsoft препоръчва да помислите за прилагането на най-новата корекция издание, което съдържа тази актуална корекция. За допълнителна информация щракнете върху следния номер на статия, за да прегледате статията в базата знания на Microsoft:
2402659 Компилации на SQL Server 2008, които са издадени след издаването на SQL Server 2008 Service Pack 2 Microsoft SQL Server 2008 горещи поправки за конкретни SQL Server сервизни пакети. Трябва да приложите актуална корекция за SQL Server 2008 Service Pack 2 инсталиране на SQL Server 2008 Service Pack 2. По подразбиране всяка актуална корекция, предоставена в SQL Server сервизен пакет е включен в следващия SQL Server сервизен пакет.
SQL Server 2005 Service Pack 3
Корекцията за този проблем е издадена за първи път в сборна актуализация 13 за SQL Server 2005 Service Pack 3.
Забележка Тъй като компилациите са кумулативни, всяка нова корекция версия съдържа всички горещи поправки и всички корекции на защитата, които са били включени в предишната SQL Server 2005 корекция издание. Microsoft препоръчва да помислите за прилагането на най-новата корекция издание, което съдържа тази актуална корекция. За допълнителна информация щракнете върху следния номер на статия, за да прегледате статията в базата знания на Microsoft:
960598 Компилации на SQL Server 2005, които са издадени след SQL Server 2005 Service Pack 3 е издаден Microsoft SQL Server 2005 горещи поправки са създадени за конкретни SQL Server сервизни пакети. Трябва да приложите актуална корекция за SQL Server 2005 Service Pack 3 за инсталиране на SQL Server 2005 Service Pack 3. По подразбиране всяка актуална корекция, предоставена в SQL Server сервизен пакет е включен в следващия SQL Server сервизен пакет.
SQL Server 2005 Service Pack 4
Корекцията за този проблем е издадена за първи път в кумулативна актуализация 1 за SQL Server 2005 Service Pack 4.
Забележка Тъй като компилациите са кумулативни, всяка нова корекция версия съдържа всички горещи поправки и всички корекции на защитата, които са били включени в предишната SQL Server 2005 корекция издание. Microsoft препоръчва да помислите за прилагането на най-новата корекция издание, което съдържа тази актуална корекция.
Трябва да приложите актуална корекция за SQL Server 2005 Service Pack 4 за инсталиране на SQL Server 2005 Service Pack 4. По подразбиране всяка актуална корекция, предоставена в SQL Server сервизен пакет е включен в следващия SQL Server сервизен пакет.
Статут
Microsoft потвърди, че това е проблем в продуктите на Microsoft, които са изброени в раздела "Отнася се за".
Заобиколно решение
Инсталирайте тази актуална корекция и рестартирайте SQL Server може да подобри производителността при възстановяване. Например производителността може да се подобри за следните операции, след като инсталирате тази актуална корекция и рестартирайте SQL Server:
-
Възстановяване на база данни
-
Дублиране на база данни
-
Снимка на базата данни
-
Дейности на четеца на регистрационни файлове за репликация на транзакции на база данни
Ако не можете да инсталирате тази актуална корекция, можете да изпълните следните заобиколни решения, за да смекчите съществуващ проблем и да предотвратите бъдещо повторение.
Смекчаване на съществуващ проблем
-
Изчакайте завършването на операцията
за възстановяване или възстановяване Ако имате не възстановена база данни, която изпитва бавна работа, когато възстановявате или възстановявате базата данни, може да се наложи да изчакате операцията за възстановяване или възстановяване да завърши. Например може да видите състоянието офлайн или състоянието на възстановяване в SQL Server Management Studio (SSMS) за невъзстановена база данни. Спирането на SQL Server обикновено не предлага облекчение за бавно възстановяване и може да отнеме повече време, за да се повтори същата фаза на анализа на възстановяването, фазата на връщане или фазата на отмяна. -
Избягвайте възстановяването на последователността от регистрационни файлове на транзакциите, която съдържа хиляди VLFs
Ако имате бавна работа, докато възстановявате и възстановявате база данни с помощта на архивен файл, можете да избегнете възстановяването на последователности от регистрационни файлове на транзакциите, които съдържат хиляди VLFs. За да идентифицирате архивния файл, който има най-много записани виртуални регистрационни файлове, използвайте следната команда, за да видите колоните FirstLSN и LastLSN в регистрационните архивни файлове:
ВЪЗСТАНОВЯВАНЕ НА HEADERONLY FROM DISK='C:\folder\file.trn"
Можете да решите да избегнете възстановяването на архивните файлове в регистрационните файлове. Или можете да използвате командата STOP AT в командите за възстановяване, за да избегнете силно фрагментирани части от регистрационните файлове на транзакциите. Ако не възстановите напълно последователностите от регистрационни файлове до най-новата точка във времето по време на сценарий за възстановяване на неуспех, загуба на данни възниква във вашата база данни SQL Server. Тази загуба на данни възниква, защото не всички транзакции се съхраняват. Ето защо има решение за търговско търгуване. Можете напълно да възстановите силно фрагментиран регистрационен файл на транзакциите. Въпреки това тази операция може да отнеме много часове. Или можете да използвате командата STOP AT в възстановяването, за да спрете възстановяването преди силно фрагментираната част от регистрационния файл. Въпреки това всички липсващи транзакции, които пропускате, се губят.
Забележка: Без да инсталирате тази актуална корекция, обикновено няма безопасно прибягване за ускорено възстановяване, след като рестартирате SQL Server. SQL Server трябва да намери списъка с VLFs, за да анализира регистрационните файлове, да върне изпълнените транзакции и след това да отмени непълните транзакции, за да завърши възстановяването, за да онлайн базата данни безопасно. Не можете безопасно да пропускате транзакции по време на възстановяването.
Предотвратяване на бъдещо повторение
-
Задаване на подходящ размер
на нарастването на автоматичното нарастване на базата данни Ако размерът на стъпката на автоматичното регистриране е твърде малък, ще има много виртуални регистрационни файлове (VLFs) и може да забележите бавна работа в SQL Server. Ако размерът на нарастването на авторегулирането е твърде голям, заявките, които правят регистрационните файлове на транзакциите, нарастват автоматично, може да се наложи да изчакат дълго време, за да се завърши нарастването. Следователно може да възникне грешка за прекъсване в SQL Server. За да заобиколите тези проблеми, можете да зададете подходящия размер на нарастването на автоматичното разполагане за вашата база данни. -
Премахване на големия брой VLFs и използване на ръчно нарастване
Ако много VLFs са в регистрационния файл на транзакциите, намалете размера на регистрационния файл на транзакциите и го направете да се увеличи преди пиковия бизнес, за да отговори на търсенето с помощта на ръчно нарастване. Например регистрационният файл на транзакциите се увеличава обратно до приемлив среден размер с голяма стъпка или с един-единствен ръчен растеж. Следователно размерът на регистрационния файл на транзакциите достига върхов капацитет и архивните файлове на регистрационните файлове се планират често и периодично. Освен това регистрационният файл на транзакциите може да бъде орязан и VLFs за регистрационния файл на транзакциите могат да бъдат повторно използване в цикъл. -
Как да свиете и увеличите регистрационния файл на транзакциите ръчно
За да коригирате регистрационен файл, който има твърде много VLFs, следвайте тези стъпки, за да свиете регистрационния файл и да го увеличите ръчно:-
Ако базата данни е в пълен или групово регистриран модел на възстановяване, трябва да архивирате регистрационния файл на транзакциите, за да позволите активните VLFs да бъдат отрязани и да бъдат повторно използваните. BACKUP LOG databasename TO DISK='C:\folder\log_backupfile.trn"
За повече информация как да архивирате регистрационния файл на транзакциите с помощта на SSMS посетете следния уеб сайт на Microsoft Developer Network (MSDN):Как да архивирате регистрационния файл на транзакциите с помощта на SSMSЗа повече информация как да архивирате регистрационния файл на транзакциите с помощта на Transact-SQL команди посетете следния уеб сайт на MSDN:
Как да архивирате регистрационния файл на транзакциите с помощта на Transact-SQL команди
-
За да определите логическото име на регистрационния файл на транзакциите, изпълнете една от следните команди:
Декларация 1
exec sp_helpfile Statement 2
select * from sys.sysfiles To reduce the size of the transaction log file to the desired size, use the following code:DBCC SHRINKFILE(transactionloglogicalfilename, TRUNCATEONLY) -
Можете да увеличите размера на регистрационния файл на транзакциите до подходящ размер. Препоръчваме ви да оставите размера на регистрационния файл на транзакциите да нарасне до най-високия редовен размер. Следователно се избягва нарастването на автоматичното растяне. За да зададете размера на регистрационния файл на транзакциите, използвайте страницата Свойства на базата данни в SSMS или използвайте следния синтаксис на ALTER DATABASE:MODIFY FILE ( NAME = transactionloglogicalfilenae, SIZE=newtotalsize МБ)
За повече информация как да увеличите размера на база данни в SSMS посетете следния уеб сайт на MSDN:Как да увеличите размера на база данни в SSMSЗа повече информация относно синтаксиса на ALTER DATABASE MODIFY FILE посетете следния уеб сайт на MSDN:
-
Повече информация
Можете да проверите броя на VLF сегментите, като прегледате регистрационния файл на SQL грешката и след това намерите поредния номер на регистрационния файл (LSN) във всеки архивен файл на регистрационния файл на транзакциите. Първите цифри преди двоеточието в LSN съответстват на номера на LSN.
Например първото число в първото информационно съобщение за LSN е 1. Обаче първото число във второто информационно съобщение за LSN е 100001. В този случай има 100 000 VLF, които се използват между момента на първото информационно съобщение и второто информационно съобщение. Затова регистрационния файл фрагментирани транзакции, който има много виртуални регистрационни файлове (VLFs) прилича на следното:
{Log беше архивиран. База данни: mydbname, creation date(time): 2010/07/08(12:36:46), first LSN: 1:5068:70, last LSN: 1:5108:1, брой устройства за вторично копие: 1, информация за устройството: (FILE=1, TYPE=DISK: {'C:\folder\logbackup1.trn'}). Това е само информационно съобщение. Не се изисква действие от потребителя.
Регистрационният файл е архивиран. База данни: mydbname, creation date(time): 2010/07/08(15:36:46), first LSN: 100001:5108:1, last LSN: 100002:5108:1, брой устройства за вторично копие: 1, информация за устройството: (FILE=2, TYPE=DISK: {'C:\folder\logbackup2.trn'}). Това е само информационно съобщение. Не се изисква действие от потребител.}
Следващата таблица предоставя повече информация за продуктите или инструментите, които автоматично проверяват за състоянието, което е описано в раздела "Симптоми" във вашия екземпляр на SQL Server и във версиите на SQL Server, на които се изчислява правилото.
|
Софтуер за правила |
Заглавие на правило |
Описание на правилото |
Версии на продукти, спрямо които се изчислява правилото |
|---|---|---|---|
|
System Center Advisor |
SQL Server с репликация на транзакциите, производителността на агента на четеца на регистрационни файлове може да бъде засегната поради размера на регистрационния файл на транзакциите или броя на VLF |
В този SQL Server съветникът за екземпляри откри репликация на транзакцията за наличност с брой VLFs или размер TLOG значително по-голям. Производителността на агента на log Reader се влияе отрицателно от размера на регистрационния файл на транзакциите или броя на VLF. Намалете размера на регистрационния файл на транзакциите и броя на VLF, за да подобрите производителността на агента на регистрационен четец. |
SQL Server 2008 |
Препратки
За повече информация относно физическата архитектура на регистрационния файл на транзакциите посетете следния уеб сайт на MSDN:
Обща информация за физическата архитектура на регистрационния файл
на транзакциите
За повече информация относно регистрационни поредни номера (LSN) посетете следния уеб сайт на MSDN:
Обща информация за регистрационни поредни номера
За повече информация относно грешка 1413 при стартиране на дублиране на база данни посетете следния уеб сайт на MSDN:
Обща информация за грешка 1413 при стартиране
на дублиране на база данни
За повече информация как структурата на регистрационните файлове може да повлияе на времето за възстановяване на базата данни посетете следния уеб сайт на MSDN:
Как структурата на регистрационните файлове може да повлияе на времето
за възстановяване на базата данни
За повече информация относно VLFs на регистрационния файл на транзакциите посетете следния уеб сайт на MSDN:
Обща информация за регистрационния файл
на транзакциите
За повече информация как да създадете снимка на базата данни посетете следния уеб сайт на MSDN:
Как се създава снимка на база данниЗа повече информация относно модела на постъпково обслужване за SQL Server щракнете върху следния номер на статия в базата знания на Microsoft:
935897 Модел на постъпково обслужване е наличен от екипа на SQL Server да предостави горещи поправки за съобщени проблемиЗа повече информация относно схемата за именуване за SQL Server актуализации щракнете върху следния номер на статия в базата знания на Microsoft:
822499Нова схема за именуване на пакети за актуализация на софтуер на Microsoft SQL Server За повече информация относно терминологията на софтуерната актуализация щракнете върху следния номер на статия в базата знания на Microsoft:
824684 Описание на стандартната терминология, която се използва за описване на актуализациите на софтуера на Microsoft
