Tech Tip - nhLoadDb hangs up, NH_TEMP01.DBF fills up

Document created by Tom_Hughes Employee on Aug 18, 2015Last modified by SamCreek on Dec 17, 2016
Version 4Show Document
  • View in full screen mode

If you run nhLoadDb, to load a DBSave, and it hangs up, with the following message in the Oracle Alert log

 

statement in resumable session 'NHUSER.EXPDP.1' was suspended due to

    ORA-01652: unable to extend temp segment by 125 in tablespace NH_TEMP

 

And you notice that the NH_TEMP01.DBF datafile has filled up; 32GB....

 

You should look earlier in the Alert log, and see if the following message appears

 

Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 4194304 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query:

select total_size,awr_flush_emergency_count from v$ash_info;

 

This could indicate another problem, regarding the configuration on the Virtual Machine, which is described in the following KB

 

http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec1610415.aspx

 

Database load fails with error 'Active Session History performed an emergency flush'

Document ID:  TEC1610415
Last Modified Date:  10/30/2014
Show Technical Document Details

 

 

Scenario:
You are migrating an eHealth database to a new VM with a fresh installation of eHealth 6.3.2.x, but the load fails and generates the following error:

Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of ASHSIZE to a sufficiently large value. Currently, ASH size is 2097152 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query:

select total_size,awr_flush_emergency_count from v$ash_info;

At this point the nhLoadDb command may appear to hang.

Diagnosis:
This may mean that ASH is undersized. In fact, our experience has shown that in the case of a database load to a new VM, the root cause of the error is a misconfiguration of CPUs; customers may accidentally allocate only one CPU to the VM, which is well below specifications.

How to Fix:

  1. If necessary, cancel out of the hung load process
  2. Destroy the partially loaded database with nhDestroyDb -s {SID} (and reboot server if Windows)
  3. Reconfigure the VM with the appropriate number of CPUs (we recommend 8 or more)
  4. Create a new database with nhCreateDb
  5. Load the database backup with nhLoadDb

Attachments

    Outcomes