SAND CDBMS Error Messages Guide
Virtual and Persistent Mode Error Messages

 

This document lists and describes the errors that can be returned when using SQL interactively against a database running in Virtual or Persistent Mode (including Octopus operation), or when invoking nserv with the -apply argument (referred to as an APPLY CHANGE operation in the error messages). Most of the entries describe the conditions that might generate the specified error, as well as possible resolutions to the problem.

 

3000 - 3013 (Temporary File and Packing Errors)

ERROR 3000: cannot open temporary file
A Virtual or Persistent Mode temporary file could not be opened. Typically, this might occur if one of the following conditions is true:

ERROR 3001: SNAPSHOT PACK failed; cannot open snapshot

ERROR 3002: SNAPSHOT PACK failed; cannot open database

ERROR 3003: SNAPSHOT PACK failed; cannot read database

ERROR 3004: SNAPSHOT PACK failed; database not dismounted

ERROR 3005: SNAPSHOT PACK failed; cannot open tree file

ERROR 3006: SNAPSHOT PACK failed; cannot read tree file

ERROR 3007: SNAPSHOT PACK failed; cannot read snapshot from tree file

ERROR 3008: SNAPSHOT PACK failed; cannot mount database

ERROR 3009: SNAPSHOT PACK failed; startup failure

ERROR 3010: SNAPSHOT PACK failed; insufficient memory

ERROR 3011: SNAPSHOT PACK failed; cannot create temporary file

ERROR 3012: DATABASE PACK failed; snapshots exist

ERROR 3013: SNAPSHOT PACK failed; read-write error

 

3210 - 3219 (KEEP CHANGE Errors)

ERROR 3210: KEEP CHANGE cannot be used in Real Mode
Returned when a KEEP CHANGE operation is attempted, but no DeltaPath or PrimaryDB parameter has been specified for the database instance. In this case, the database instance is running in Real Mode. A KEEP CHANGE operation can only be performed in Virtual Mode or Persistent Mode.

ERROR 3211: KEEP CHANGE not executed; incorrect database name
Returned when the SHUTDOWN...KEEP CHANGE command specifies an incorrect database name. If this error message is displayed, it is likely that an internal error has occurred, as the KEEP CHANGE syntax does not allow the specification of a database name. Please contact a SAND support representative for assistance.

ERROR 3212: Cannot execute KEEP CHANGE on a non-master instance
Returned when a KEEP CHANGE operation is attempted while in Virtual or Persistent Mode, but the name of the running instance is different from the real database name (that is, a secondary instance is being used). Ensure that the instance name matches the core database name and restart the database instance.

ERROR 3213: KEEP CHANGE has already been applied to this snapshot
Returned when a KEEP CHANGE operation is attempted in Persistent Mode on a database instance whose current state has already been saved to an Update File. A new Snapshot can be created only after changes are made to the running database instance.

ERROR 3214: KEEP CHANGE not executed, no changes were made
Returned if a KEEP CHANGE operation is started when no changes have been made to the database instance. A KEEP CHANGE operation can only be performed when there are actual changes to retain.

ERROR 3215: KEEP CHANGE failed; unable to lock db.tree file
Returned when a KEEP CHANGE operation is attempted while the database is in use by another client application. Disconnect all other sessions from the database and proceed with the KEEP CHANGE operation.

This error message might also be returned if the user performing the KEEP CHANGE operation does not possess the file access permissions required to write to the Time Travel database-name.tree file. The database-name.tree file, located in the same directory as the core database file, maintains information about the version tree structure for the database with the same name. Ensure that the appropriate permissions on the version tree file have been granted by the system administrator.

ERROR 3216: KEEP CHANGE failed; invalid snapshot
Returned when one user attempts a KEEP CHANGE operation but the checkpoint within the core database has been changed by another user session. Also returned when a KEEP CHANGE operation is performed for the second time within a given user session. Disconnect and restart the server.

ERROR 3217: KEEP CHANGE failed; unable to allocate change file
This error is returned if one of the following conditions is true:

Errors involving an Update File can occur when the file is created with a checkpoint number that already exists (typically due to the failure of a previous KEEP CHANGE operation). The error might also be returned when an invalid path is specified for the Update File used by the KEEP CHANGE operation in Virtual Mode. In these cases, delete the Update File and attempt the KEEP CHANGE operation again. If a path is specified for the Update File, ensure that it is valid.

The other situations where this error might be returned can often be traced to lack of available disk space, or the user not possessing required permissions.

ERROR 3218: KEEP CHANGE failed; unable to rename change file
The master instance Delta File could not be renamed during the KEEP CHANGE operation. When the SHUTDOWN...KEEP CHANGE command is executed in Virtual Mode with no Update File name included, the Delta File is simply renamed to transform it into an Update File having the same name as the real database. This error might occur if one of the following conditions is true:

Ensure that the Delta File is in the expected directory location and is not being used by another process; and verify that you have been granted the necessary access permissions on the file by the system administrator.

ERROR 3219: KEEP CHANGE failed; unable to pack snapshot
Returned when a Persistent Mode KEEP CHANGE operation executed successfully, but the resulting Update File could not be compacted. This might occur if one of the following conditions is true:

Ensure that the Update File and .TREE file are located in the proper directories before attempting the KEEP CHANGE operation again. As well, ensure that the Update File is neither corrupted nor locked by another process. If the root database has been deleted, replace it with a backup copy.

Note that an Update File can be compacted manually by specifying ndbchk -s snapshot-number  database-name.

 

3220 - 3231 (APPLY CHANGE Errors)

ERROR 3220: APPLY CHANGE cannot be used in Real or Persistent Mode
Returned when a -apply argument is included with the nserv invocation of a database set to run in Real Mode or Persistent Mode. An Update File can only be applied to a database set to run in Virtual Mode.

ERROR 3221: APPLY CHANGE failed; no change file specified
This error message is returned when no Update File name is specified for the APPLY CHANGE operation.

ERROR 3222: APPLY CHANGE failed; incorrect database name
Returned when the nserv -apply flag specifies an Update File that was created for a database other than the one nserv is attempting to start. Ensure that the Update File is being applied to the correct database before attempting the APPLY CHANGE operation again.

ERROR 3223: Cannot execute APPLY CHANGE on a non-master instance
Returned when an APPLY CHANGE operation is attempted while in Virtual Mode, but the virtual instance name is different from the real database name (that is, a secondary instance is being used). Ensure that the PrimaryDB setting is the same as the core database name and restart the database instance.

ERROR 3224: APPLY CHANGE failed; unable to access primary db file
Returned when an APPLY CHANGE operation is attempted while another user is connected to the database instance. Exclusive access to the database is required to perform this operation.

ERROR 3225: APPLY CHANGE failed; unable to open change file
Returned when the Update File specified for an APPLY CHANGE operation is not found in the current directory or in the included path. Verify that the Update File exists and is in the indicated location. Also note that the change file name must be specified with the proper extension (*.Cxx, where xx is the appropriate checkpoint number).

ERROR 3226: APPLY CHANGE failed; change file read error
Returned when the Update File for an APPLY CHANGE operation could not be opened for reading. This might occur if either of the following conditions is true:

Ensure that the Update File is not being used by another application. If necessary, have the system administrator grant the appropriate access permissions on the Update File.

ERROR 3227: APPLY CHANGE failed; error allocating memory
Returned when the system's virtual memory is exhausted while attempting an APPLY CHANGE operation. Terminate other concurrently running processes, and attempt the APPLY CHANGE operation again. If the error occurred on a UNIX platform, consult the SAND CDBMS Administration Guide for information about increasing user limits for the execution environment.

ERROR 3228: APPLY CHANGE failed; config record read error
Returned when attempting to apply a corrupted Update File to the database. Recreate the Update File and attempt the APPLY CHANGE operation again.

ERROR 3229: APPLY CHANGE failed; invalid database checkpoint
Returned when a user attempts an APPLY CHANGE operation, but the checkpoint within the core database has been changed by another user session.

ERROR 3230: APPLY CHANGE failed; database write error
Issued when an APPLY CHANGE operation fails due to insufficient disk space. In this event, do not attempt to restart the database instance. The APPLY CHANGE must be successfully completed in order to return the database to a stable state. If sufficient disk space is made available, the operation can be attempted again, and the database instance restarted after successful completion of the operation.

ERROR 3231: APPLY CHANGE failed; unable to open database
Returned when the database could not be opened for a Virtual Mode APPLY CHANGE operation or a Persistent Mode merge to the root node. This may be caused by any of the following conditions:

Ensure that the database is not locked by another process before attempting the operation again. If the database files have been moved, make sure that the primary database file is in the path indicated by the nucleus.ini DatabasePath parameter for the database, and that the secondary files are in the data drives specified for the database. If access permissions for the database files have been altered, change the permissions so that read and write are allowed. If the database files are corrupted, the database should be restored from a backup copy.

 

3240 - 3248 (Miscellaneous Errors)

ERROR 3240: cannot load tree file
Returned when the Time Travel version tree file (database-name.tree) is not located in the database directory. Ensure that the version tree file is in the same directory as the core database file.

This error message may also be returned if the user attempting to start a database instance in Persistent Mode does not possess the access permissions required to read the version tree file. In this case, have the system administrator grant the appropriate permissions, and attempt to start the database instance again.

ERROR 3241: invalid snapshot number
Returned when nserv is invoked in Persistent Mode using a Snapshot number that does not exist in the Time Travel version tree. Use the nmerge utility with the -v flag to view a list of the valid Snapshot numbers, as well as other diagnostic Snapshot information:

nmerge -v instance-name

Consult the Persistent Mode Operations (Time Travel) section of the SAND CDBMS Administration Guide for further information about using the nmerge utility.

ERROR 3242: cannot open update file
Returned when the Update File representing the specified Snapshot could not be read. This might occur if one of the following conditions is true:

Ensure that the Update File exists, is in one of the data drives specified for the database using nconfig, and is not being used by another process. If necessary, have the system administrator grant the appropriate access permissions on the Update File.

ERROR 3243: incompatible update file
Returned when the Update File representing the specified Snapshot cannot be used with the database instance being started by nserv. Ensure that the Update File represents a valid Snapshot for the database instance, and that the Update File is not corrupted.

ERROR 3244: cannot access master file
Returned when a second master server is started while Octopus is operating in Persistent Mode. Only one master server can be running at a time; any attempt to start a concurrent master server will produce this error.

ERROR 3245: cannot open master temp file
Returned when a non-master Octopus instance (in Persistent Mode) cannot open the master temporary file. The master temporary file may have been moved or deleted erroneously, or it could be locked by another process. Ensure that the master temporary file is not in use by another process. If the file was somehow removed, Octopus may have to be restarted.

ERROR 3246: cannot read master temp file
Returned when a non-master Octopus instance (in Persistent Mode) cannot read the master temporary file. The master temporary file could be locked by another process, or the permissions for the file have been changed to deny read access. Ensure that the master temporary file is not in use by another process. If necessary, change the access permissions for the master temporary file so that it can be read by non-master instances.

ERROR 3247: KEEP CHANGE failed; cannot write update file
Returned when an Octopus KEEP CHANGE operation fails while attempting to construct an Update File. Usually, this error is generated if one of the following conditions is true:

Errors involving an Update File can occur when the file is created with a checkpoint number that already exists (typically due to the failure of a previous KEEP CHANGE operation). In this case, delete the Update File and attempt the KEEP CHANGE operation again.

The other situations where this error might be returned can often be traced to lack of available disk space, or the user not possessing required permissions.

ERROR 3248: invalid RunMode
Returned when attempting to start a database Snapshot in Real or Virtual Mode. A Snapshot can be started only in Persistent Mode. Ensure that the [DATABASE instance-name] section in the server side nucleus.ini file (where instance-name corresponds to the database instance name specified for the nserv invocation) contains a RunMode parameter set to Persistent.