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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 19.01.2011, 01:13   #1  
Blog bot is offline
Blog bot
Участник
 
24,031 / 809 (75) +++++++
Регистрация: 28.10.2006
axinthefield: Database Mirroring with Dynamics AX
Источник: http://blogs.msdn.com/b/axinthefield...namics-ax.aspx
==============

Is the AOS a "mirror aware" service? If so, what's the user experience when a failover happens? These are two of the questions I recently received from a customer as they were planning their database high availability solution.

When it comes to database high availability for Dynamics AX, a SQL cluster is by far the most commonly used technology. Most of the time when I see database mirroring it's typically used as a disaster recovery solution to ensure a recent copy of the database exists at an offsite location where an entire DR environment (SQL Server, AOS, etc.) is sitting idle ready to be used if the primary data center goes offline. Database mirroring with automatic failover isn't something that fits with this type of a situation. You'll generally want a real person making the decision when it comes to failing over to a completely different environment in a different location. But, the question from this customer was about using database mirroring in place of a SQL cluster for database high availability where the AOS services would remain the same and just the database would be moving from one server to another via mirroring. In this case automatic failover would definitely be useful.

Will the AOS stay connected to the database during a database mirroring failover just as it does with a SQL cluster failover or will it be necessary to make a change to the Dynamics AX server configuration utility and restart the AOS to get it connected after a failover? After some quick searching I found there wasn't much explicitly documented on how this works, so I decided it would be a good scenario to setup and test. Here's what I did.

Test Environment Configuration:
  1. My starting point for the test was a fully operational all-in-one Dynamics AX environment on a virtual machine. Here's the version information for the key components tested.
    • Windows Server 2008 R2
    • SQL Server 2008 SP2
    • Dynamics AX 2009 SP1 RU6
  2. Next I installed a second SQL instance on the same server to host the mirror database. I named this instance MIR. It's important to make sure both instances are running the exact same version.
  3. Before setting up database mirroring between the two instances you'll need to set the recovery model for the AX database to full.
  4. Perform a full backup of the AX database and restore the backup to the newly installed MIR instance of SQL Server. The full backup needs to be restored so additional transaction logs can still be applied, so you'll need to use the RESTORE WITH NO RECOVERY option.
  5. Once the database has been restored to the MIR SQL instance you'll need to create a SQL Server login for the AOS account. This login needs to be the same on both instances of SQL Server so the AOS service can connect to whichever one is configured as the principle. In most cases it will likely be a domain service account. In my case I just used NT AUTHORITY\NETWORK SERVICE. Logins exist at the SQL Server instance level, so they don't come over to the new instance via the database restore or via the mirroring process. That's why you have to do this manually.
  6. Configure mirroring between the two databases. In this case I used the following option (High safety without automatic failover).
  7. Wait until the databases are fully synchronized.
  8. Start or restart the AOS instance so it initiates a database connection to the principle database after the mirroring configuration is complete.
  9. Start an AX client session and verify the AX client is operational while connected to the principal database.
  10. Manually initiate a failover of the database mirror so the mirror becomes the principle and the principle becomes the mirror.
Test Results / Conclusions:
  • The database mirror failover from the principle to the mirror took about 40 seconds. I considered the failover complete when the Database Mirroring Monitor showed the principle and mirror in a "synchronized" state again.
  • The AX client session I left running during the failover became unresponsive and produced an infolog message stating that the database was not accessible. The client was in this state for about 50 seconds before it recovered and I was able to continue working again. No intervention was necessary, just some patience. I failed it back and forth 3 times and the failover times were pretty consistent.
  • It's important to note that this was all done on a single virtual machine with limited resources and that no transactions were running in the background during the test. The goal of this test was to validate functionality not necessarily to measure how long a failover is likely to take in a real world scenario.
  • Automatic failover with a witness wasn't explicitly tested here, but it's reasonable to assume that there wouldn't be any difference in the results from a Dynamics AX perspective. The AOS isn't aware of and therefore doesn't care how the failover is actually initiated (manually or automatic).
Based on the results of this test, database mirroring is certainly a viable option for Dynamics AX database high availability.

References:


Источник: http://blogs.msdn.com/b/axinthefield...namics-ax.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 20.01.2011, 10:54   #2  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,607 / 5330 (185) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 2
Кстати, да, очень интересная особенность клиента AX 2009 - переживать обрывы соединений с СУБД (или это особенность AOS'а - не отстреливать клиентскую сессию?). Прежде, если что-то случалось с соединением с СУБД, клиентская сессия отстреливалась на раз, а теперь только ошибку в инфолог пишет.
Теги
ax2009, cluster, database

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
dynamics-ax: Official Details about Dynamics AX '6' released, including comments from Microsofts Kees Hertogh Blog bot DAX Blogs 0 11.01.2011 05:22
semanticax: Dynamics AX 2009 Installation - Application Blog bot DAX Blogs 0 22.12.2010 08:11
emeadaxsupport: Checking Database entries after restoring a Microsoft Dynamics 2009 SQL Database to another Domain or Environment Blog bot DAX Blogs 0 18.02.2010 23:05
gatesasbait: Dynamics AX 2009 SSRS and SSAS Integration Tips Blog bot DAX Blogs 3 09.07.2009 13:07
axStart: Microsoft Dynamics AX 2009 Hot Topics Web Seminar Series Blog bot DAX Blogs 0 06.08.2008 12:05
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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