Kbase P55254: Investigating why the database takes so long to shut down
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
04/01/2011 |
|
Status: Verified
GOAL:
Investigating why the database takes so long to shut down
GOAL:
Understanding proshut command hangs database shutdown
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
OpenEdge Category: Database
FIX:
During the shutdown process, a complete flush of the dirty buffers takes place and all connected processes are given time to end. If the database needs to be more aggressively shut down, issue:
proshut [dbname] -F -by
Any active connections will be terminated and proshut will not have to wait for these to exit themselves. If needing to shut the database down in order to back it up, insert a command to truncate the .bi file before starting the backup. Please refer to P3222: Using proshut -by or proshut -F for more information on this command.
If this scenario is happening often, it is worth considering the following the next time this issue occurs:
1.) Before killing the process or the broker, execute the following:
a) Run a promon session before proshut to gather all information on user activity. Essentially users should first be asked to log off before issuing a shutdown.
b) Check the system for any rogue processes that haven't shut down and produce a stacktrace against them. There could be a process locking the shutdown.
c) If After-imaging is in use; run "rfutil dbname -C aimage list" to get the current status of all ai extents
d) Produce a stacktrace against the _mprshut process with kill -16 <process-id> to generate a protrace file
e) Send Progress Technical Support the stacktraces that result from the above action and we will be able to find exactly which processes were locking the shutdown.
2. Once proshut has successfully completed, does a "truncate bi" perform a crash recovery without any error messages? Errors would indicate file corruption which would need to be investigated at a system level.
3. Is this action being performed from the same_user_account / environment every time? It could b