AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.02.2014, 04:47   #1  
Blog bot is offline
Blog bot
Участник
 
25,574 / 848 (80) +++++++
Регистрация: 28.10.2006
axinthefield: TempDB Errors in AOS event log after SQL Server Cluster Failover or AlwaysOn Availability Groups Failover
Источник: http://feedproxy.google.com/~r/AxInT...-failover.aspx
==============

TempDB Errors in AOS event log after SQL Server Cluster Failover or AlwaysOn Availability Groups Failover

...(read more)

Источник: http://feedproxy.google.com/~r/AxInT...-failover.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 02.08.2024, 20:23   #2  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,926 / 3206 (114) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Ссылки не работают.
Оставлю из архива
https://web.archive.org/web/20190117...pdate-8272014/
Старый 02.08.2024, 20:25   #3  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,926 / 3206 (114) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
TempDB Errors in AOS event log after SQL Server Cluster Failover or AlwaysOn Availability Groups Failover (Update 8/27/2014)
Michael DeVoeFebruary 27, 2014

If you have ever seen errors in your AOS Event Viewer Logs after a SQL Server Cluster or AlwaysOn Availability Groups Failover and wondered why it is happening here is a brief explanation.



Object Server 01:

[Microsoft][SQL Server Native Client 10.0][SQL Server]Cannot drop the table

'tempdb.DBO.t855_489F061A83074B41907007FFAE3B5D41', because it does not exist or you do not have permission.

DROP TABLE tempdb."DBO".t855_489F061A83074B41907007FFAE3B5D41




Dynamics AX 2012 R2 makes use of "persisted" tables in TempDB in SQL Server. This essentially means that they build Tales in TempDB that "hang around" for a long time. This is a little different than how most processes use TempDB as they usually will create a temporary object, use it, and then drop it within a single transaction. When a SQL Server has a Failover TempDB does not "come with it" to the new server node. The AOS has no idea that the SQL Server has had a failover and still assumes these temporary tables still exist and will try to query them generating these types of errors. The only way to get rid of them is to stop and start the AOS services. It means that those TempDB transactions are not safe through the failover

This was actually corrected in is a pre CU3 hotfix which worked KB 2729496. They added code to check for the TempDB table before querying it and if it is not they rebuild it on the fly (There are other actions but I want to keep this brief). This fix was then rolled into CU6 but due to a regression error it was broken.

For now the best practice on SQL Server Failover would be too manually or use a PowerShell script to automate the recycling all the AOS services after a failover. Agreed this is not a perfect workaround and removes some of the benefits of automatic failover but until a fix is released it will prevent many headaches with your users and AOS event logs filling with errors



UPATE 5/9/2014

Due to the complexity and pervasive nature of this issue we are still in the process of investigating all the potential causes. I will update this BLOG as more information on this issue becomes available.


Update 8/27/2014

This issue has now been corrected. The user will still see an error but AX will clean up the pool so that the user will not see any more errors after the initial error even if there are many tempdb tables in the pool. This does not ensure that the user will never see an error or that a batch job will not fail but guarantee that the AOS does not have to be restarted.

AX 2012 RTM

You will need to contact support and ask for KB 2920058

AX 2012 R2

You will need to contact support and ask for KB 2956617
Старый 02.08.2024, 20:26   #4  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,926 / 3206 (114) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Comments :

karabela
March 4, 2014 at 1:51 pm
get-service -name AOS60$01 -ComputerName AOSSERVER1, AOSSERVER2, AOSSERVER3 | Restart-Service -whatif

start powershell with elevated rights. remove -whatif if you want to actually restart the aos services


Michael DeVoe
February 28, 2014 at 12:21 pm
@jaestevan, I will admit I am not a PowerShell guru, but if I find the time and find some commandlets I can "borrow" from I will write one and add it to the article.


Michael DeVoe
February 28, 2014 at 11:52 am
@Phil A, I completely understand your frustration as I helped a customer build an AlwaysOn Availability Group for Failover, ETL data loads for Data Warehouse, and doing back-up from only to find out that when it failed over, the AOS servers starting throwing errors left and right. The only consolation I can offer you is that it will be fixed in a later CU for AX.


jaestevan
February 28, 2014 at 1:53 am
Can you give us an example of this powershell script to refresh all services?


Phil A
February 28, 2014 at 1:09 am
I find it appauling that Microsoft's recommended high availability configuration for Dynamics AX doesn't actually serve any purpose at all because of this bug in the product. Our customer purchased an Enterprise license for SQL just to use AlwaysOn with Dynamics AX, and yet they still have to reboot their AOS's everytime a failover occurs, otherwise half the application stops working. What a joke.
Старый 02.08.2024, 21:15   #5  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,926 / 3206 (114) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Axapta 2012 R3 CU13
Проблема воспроизводится.

Неужели так и нет решения с 2014-го года?
Старый 06.08.2024, 11:59   #6  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,926 / 3206 (114) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
up
Старый 06.08.2024, 12:06   #7  
Maximin is offline
Maximin
NavAx
NavAx Club
 
412 / 346 (12) ++++++
Регистрация: 09.10.2002
Адрес: Москва
На R3 CU8 даже без failover периодически сталкиваюсь с тем же.
__________________
Жизнь прекрасна! Если, конечно, правильно подобрать антидепрессанты...
Старый 06.08.2024, 13:11   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,926 / 3206 (114) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Maximin Посмотреть сообщение
На R3 CU8 даже без failover периодически сталкиваюсь с тем же.
Я так понимаю, что таблетки нет ?
Только рестарт аосов ?

А почему в вашем случае возникает проблема ? В случае failover все понятно - меняется инстанс базы данных и там другая TempDb. Но если экземпляр базы данных не менялся то откуда проблема возьмется ? Может прав на обращения с табличками в TempDb не хватает?

Кстати, почему CU8 ? Кернел можно обновить независимо. Легко проходит. Много разных багов исправлено.
Старый 06.08.2024, 14:06   #9  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
367 / 561 (19) +++++++
Регистрация: 08.08.2007
Записей в блоге: 1
На одном из проектов я сталкивался с ошибками при работе с tempDB при смене нод, там помог флажок в реестре synctempdbpoolfrequency, насколько я помню он чистит пул не существующих таблиц из памяти АОСа. Более подробно тут https://www.microsoft.com/en-us/dyna...-sql-clusters/

Я не уверен, что именно эта проблема у нас была, но аосы при переезде нод мы не рестартовали, хотя пакетных заданий использующих tempDB таблицы было много. обычно после переезда, несколько вызовов ПО могли падать в ошибку, но дальше работали исправно.
__________________
Sergey Nefedov
За это сообщение автора поблагодарили: Logger (15).
Старый 06.08.2024, 15:10   #10  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,926 / 3206 (114) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от SRF Посмотреть сообщение
Я не уверен, что именно эта проблема у нас была, но аосы при переезде нод мы не рестартовали, хотя пакетных заданий использующих tempDB таблицы было много. обычно после переезда, несколько вызовов ПО могли падать в ошибку, но дальше работали исправно.
Спасибо.
Похоже, это то, что надо.
Старый 24.09.2024, 08:05   #11  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,926 / 3206 (114) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от SRF Посмотреть сообщение
На одном из проектов я сталкивался с ошибками при работе с tempDB при смене нод, там помог флажок в реестре synctempdbpoolfrequency, насколько я помню он чистит пул не существующих таблиц из памяти АОСа. Более подробно тут https://www.microsoft.com/en-us/dyna...-sql-clusters/
Интересно, что после применения описанной настройки, перестали "утекать" временные таблички в TempDb, хотя, судя по описанию, это никак несвязанные вещи. Возможно, данный флаг меняет еще что-то в поведении ядра, устраняющее потерю ссылок на времянки, либо исправляющий сборку мусора среди времянок.
Теги
alwayson, failover, synctempdbpoolfrequency

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
CRM DE LA CREME! CRM 4.0 Disaster Recovery Blog bot Dynamics CRM: Blogs 2 26.02.2016 08:23
crminthefield: Configuring SQL Server 2012 AlwaysOn Availability Groups with Dynamics CRM Blog bot Dynamics CRM: Blogs 0 28.11.2013 06:16
axinthefield: Dynamics AX 2012 and SQL Server 2012 AlwaysOn Availability Groups Blog bot DAX Blogs 0 11.02.2013 20:11
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 03:45.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.