Subscribe

stuck process on a Windows DFM upgrade

Hello all, we noticed an interesting event on upgrading 3.7.1 to 3.8.1 on a windows platform...

the installed stopped for a moment and told us that DFM is not managing the rotatelogs.exe processes and it identified two of them.  When we looked at task manager, there was six of them running and we had to terminate them by hand ( all known DFM services had already stopped ).

We are curious as to why there was six of these running.

Re: stuck process on a Windows DFM upgrade

another mystery is that the install proceedure is stuck - we see dbeng10.exe running but barley ticking a 1 to 3% of the cpu and using 1.7 GB of RAM on a 4 GB RAM system.  Would this be a concern?

Re: stuck process on a Windows DFM upgrade

Hi Emanuel,

From what I remember when planning a 3.8.1 upgrade the bug BURT 307966 – “DataFabric Manager's rotatelogs.exe process crashes on Windows” is fixed when upgraded to OM 3.8.1 .

With regards to your second post, how big is the database? Do you have Performance Advisor running and enabled? These are factors in the time it takes to perform an OM upgrade.

Richard

Re: stuck process on a Windows DFM upgrade

It finally finshed after 90 plus minutes; there was very little activity going on during the upgrade including a process called dbeng10.exe which was working at 2% of cpu on a dual xeon system with 4 GB of RAM ( yea RAM is a little low for my DFM standards ) and hogging about 1.7 GB of system RAM.  DB is about 5 GB in size from what i remember.

it is really tough to sit with a customer updating software when you have no idea what is happening; i wished DFM did a better job during the "waiting" period.

Re: stuck process on a Windows DFM upgrade

Known problems of this kind are either documented in the Install/Upgrade guide or in the Release notes. Unfortunately, I could not find the documentation for this upgrade scenario issue, in either of those documents. I suggest you file a burt seeking clarity on this issue. But to answer you question, the upgrade is likely to have taken longer because we moved from Sybase 9 to Sybase 10 in 3.8. Sybase 10 db file format is different which is the cause of the delay in the upgrade.

Upgrading from DataFabric Manager 3.5 or earlier  Top

If you are upgrading from DataFabric Manager 3.5 or earlier to DataFabric Manager 3.6 or later, it takes a long time to upgrade the performance data files (data of 20 GB or more). The length of time depends on the platform used. The space used by the performance data files increases by about 65% during the upgrade.

Upgrading from DataFabric Manager 3.2 or earlier  Top

Because of database schema changes, you might experience a delay of several minutes to a few hours when upgrading from DataFabric Manager 3.2 or earlier. The time required to perform the upgrade depends on the size of the database, the amount of history in the database, the CPU speed, and the I/O throughput of the system. The following processes might require a lot of time:

  • Merging rotating history tables
  • Populating history tables
  • Populating volume history tables
  • Populating aggregate history tables
  • Reloading the database into the latest file format (at the end of upgrade)

ref:

1. http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel381/html/software/upgrade/intro3.htm

2. http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel381/pdfs/rnote.pdf

Re: stuck process on a Windows DFM upgrade

As a customer my preferred approached (especially now provisioning new hosting systems is easier with virtualization ) is to build a new instance of OM and then restore the old database into the new instance. This way you can have a timely cutover and have a robust rollback plan. Plus restoring the database into a later version of OM gives you lots of output on the console to see what it’s doing.

Admittedly not everyone has the capacity or facilities to take this approach but I thought I’d share it anyway as this procedure has worked well for me for over 5 years.

Richard