H3–Database Access Problems

H3–Database Access Problems
Prev	Finding and Fixing Database Errors	Next

Use the following diagnostic steps and references to determine an appropriate course of action for database access problems.

Determine if the disk volume is inaccessible.

Use the UNIX ls utility to display information retrieved from the volume. If the volume is not accessible to UNIX, the problem is not a database problem. Refer to section H7.
Determine whether UNIX can write to the disk.

Use a shell command such as mv or cp. If UNIX cannot write to the volume, the problem is not a database problem. Refer to section H7.
Determine whether any database file used by the application has "Cache Freeze" set.

Use DSE FIND -REGION=region and DUMP -FILEHEADER to verify that CACHE FREEZE is zero (00000000) for any hung region(s).

If CACHE FREEZE shows a PID, that process used MUPIP or DSE to FREEZE the database. In this case, investigate whether the process is currently producing the desired results. If the FREEZE is legitimate, do whatever is appropriate to speed up the process using FREEZE. For example, use the NICE command. If the process still exists, but should not be running at this time, stop it. If CACHE FREEZE is non-zero but not in use to protect the database, use DSE FIND -REGION=region and CHANGE -FILEHEAD -FREEZE=FALSE to clear the FREEZE state.

Use the DSE commands FIND -REGION and DUMP -FILEHEADER. If any region is frozen, determine who initiated the freeze, and whether the process should be terminated or allowed to complete. The following actions freeze databases:
- DSE CHANGE -FILEHEADER -FREEZE=TRUE
- DSE ALL -FREEZE
- MUPIP BACKUP -NOONLINE
- MUPIP FREEZE
- MUPIP INTEG -REGION
- MUPIP EXTRACT -FREEZE
DSE CHANGE -FILEHEADER -FREEZE=FALSE and MUPIP FREEZE -OFF clear a freeze. However, when used with -OVERRIDE, these commands may cause damage to the results of the process that initiated the freeze. After the freeze is cleared, re-examine the entire situation.
Determine whether the database files used by the application are accessible for reading.

Use an M function such as $DATA() or $ORDER().
Determine whether the database files used by the application are accessible for writing.

SET a node in each database equal to itself.

IF THE DATA CAN BE BOTH READ AND WRITTEN, the problem is not a database problem. Refer to section H8.

IF DATA CANNOT BE READ OR WRITTEN, some process is unable to release full ownership of the database critical section. Determine the process identification number (PID) of the process using the DSE command CRITICAL. If the process exists, refer to section H4. If the process is non-existent, use DSE CRITICAL -REMOVE to emulate a release and re-examine the entire situation.

Example:

  S reg=$V("GVNEXT",""),com="dbcheck.com" o     m-*  com:newv u com
  W "$ DEFINE/USER SYS$OUTPUT dbcheck.lis",!,"$ DSE",!
  F  Q:reg=""  D
  . W "FIND /REGION=",reg,!,"DUMP /FILEHEADER",! 
  . S reg(reg)="",reg=$V("GVNEXT",reg)
  W "$ SEARCH dbcheck.lis ""Cache freeze""",!
  ; CAUTION: in the above line, "Cache freeze" 
  ; MUST be mixed-case as shown
  W "$ DELETE dbcheck.lis.",!,"$ EXIT",!
  C com ZSY "@dbcheck" 
  O com C com:delete
  W !,"Attempting first access"
  S g="^%" D:$D(^%)  F  S g=$O(@g) Q:g=""  D
  . S reg=$V("REGION",g) Q:$l(reg(reg))
  . I $D(@g)'[0 S reg(reg)=g
  . E  S reg(reg)=$Q(@g) 
  . W !,"Successful Read in region: ",reg," of ",g
  S reg="" F  S reg=$O(reg(reg)) Q:reg=""  D
  W !,"Write to region: ",reg 
  S @(reg(reg)_"="_reg(reg)) W "–OK"
  Q
   S reg=$V("GVFIRST"),com="dbcheck" o com:newv u com
   W "dse <<yz > dbcheck.lis",!
   F  Q:reg=""  D
   . W "find -region=",reg,!,"dump -fileheader",! 
   . S reg(reg)="",reg=$V("GVNEXT",reg)
   W "yz",!,"cat dbcheck.lis | grep 'Cache freeze'"
   ; CAUTION: in the above line, "Cache freeze" 
   ; MUST be mixed-case as shown
   W "|awk '{print $1, $2, $3}'"
   C com ZSY "/bin/csh -c ""source dbcheck""" 
   O com,dbcheck.lis C com:delete,dbcheck.lis:delete
   W !,"Attempting first access"
   S g="^%" D:$D(^%)  F  S g=$O(@g) Q:g=""  D
   . S reg=$V("REGION",g) Q:$l(reg(reg))
   . I $D(@g)'[0 S reg(reg)=g
   . E  S reg(reg)=$Q(@g) 
   . W !,"Successful Read in region: ",reg," of ",g
   S reg="" F  S reg=$O(reg(reg)) Q:reg=""  D
   . W !,"Write to region: ",reg 
   . S @(reg(reg)_"="_reg(reg)) W "–OK"
   Q

This routine provides a generalized approach to automating some of the tasks described in this section. It contains argumentless DO commands primarily for typesetting reasons. The routine issues a report if any region is frozen, but does not report which regions are in that state. It may hang reading or writing a database. However, unless the region(s) holding ^% and the next global after ^% has a problem, it displays the name of the region that it is about to try. If this routine runs to completion, the databases in the current Global Directory are completely accessible. The limitations of this routine can be overcome by writing custom shell scripts and/or M programs that include embedded information about one or more Global Directories.


	If you have a Global Directory mapping globals to multiple files, you may create an alternative Global Directory using different mappings to those same files. Such mapping prevents the test program(s) from touching the "real" data.

Example:

Mapping      Production region   Test region
-----------------------------------------------
A   to   M   
$DEFAULT            SCRATCH
N   to   Z   SCRATCH            
$DEFAULT

Prev	Up	Next
H1 - Process Hangs	Home	H4–Database Cache Problems