1. Database Upgrade Guide
  2. Resume Siebel Database Update Utilities

Resume Siebel Database Update Utilities

The PostInstallDBSetup and RepositoryUpdate utilities support resumable execution for update recovery. When an execution of either utility is interrupted or fails, the utility can continue processing from the last successfully completed logical operation, instead of repeating work that has already completed.

A resume operation is performed against an unfinished execution. When the utility starts, it searches the update history for the latest compatible unfinished execution for the same utility entry point and target content version. If a compatible execution is found, the utility restores the saved checkpoint state and continues processing the execution.

A completed execution is not selected for resume processing.

Resumable execution does not change the database update operations performed by the utility. Existing validation, import, SQL, Workspace, and version-tracking processing remains unchanged. Resume processing determines which logical operations must be executed again and which previously completed operations can be bypassed.

Automatic Resume of PostInstallDBSetup and RepositoryUpdate

When either PostInstallDBSetup or RepositoryUpdate starts without the -cleanstart option, the utility performs the following processing:

  1. Performs the normal environment, repository, and version validation.
  2. Calculates the resume identity for the current invocation.
  3. Searches the update history for the latest unfinished execution that is eligible for resume processing.
  4. Validates the saved execution against the current invocation.
  5. If a compatible execution is found, loads its saved state and resumes processing.
  6. If no compatible execution is found, starts a new execution.

An execution is eligible for resume processing only when its saved identity and resume-sensitive input values are compatible with the current invocation.

If validation fails, the previous execution is not reused. The utility records the reason in the logs and starts a new normal execution. The previous execution state is retained for diagnostic and audit purposes.

Checkpoint-Based Continuation

During execution, checkpoints and tracked logical substeps are recorded before and after processing.

When an execution is resumed:

  • Operations with a status of SUCCESS are not executed again.
  • Operations with a status of SKIPPED are not executed again.
  • Operations with a status of FAILED are executed again after the failure condition has been corrected.
  • Operations with a status of IN_PROGRESS are treated as incomplete and are executed again.
  • Operations with a status of PENDING are executed when their prerequisites are satisfied.
  • Operations with a status of BLOCKED are executed when the preceding dependent operation has completed successfully.

A checkpoint is recorded only when the corresponding safe logical operation has completed successfully. If processing stops while an operation is incomplete, that operation remains eligible for execution when the utility is resumed.

Logical Restart Boundaries for PostInstallDBSetup and RepositoryUpdate

Resume processing occurs at logical-operation boundaries.

The smallest restart unit is a logical operation. Examples include a build-specific schema import, a seed import for a specific build, a configured SQL operation, or a generated Repository file.

The utility does not resume processing in the middle of any of the following:

  • A SQL statement
  • An external executable or command
  • A Workspace delivery operation
  • A repository bulk-import command
If processing stops while one of these operations is in progress, the operation is treated as incomplete and is executed again when processing resumes.

Start a New Execution

By default, a compatible unfinished execution is resumed when one is available. To start a new logical execution instead of resuming an unfinished execution, specify the following option:

-cleanstart

The -cleanstart option creates a new logical execution. It does not delete the checkpoint or update history associated with a previous execution, and it does not roll back database or repository changes made by the previous execution.

Caution: Use -cleanstart only when you intend to start a new logical execution. Database and repository changes completed by a previous execution are not rolled back.

Resume State

The parent history row in S_APP_VER_HIST represents the logical PostInstallDBSetup or RepositoryUpdate execution used for resume processing.

On supported database platforms, the utility uses the S_APP_VER_HIST.RESUME_STATE_JSON column to store a durable reference to the saved resume state. The complete checkpoint state is maintained in a human-readable state.json file in the run log directory.

The resume state records information required to identify and validate the logical execution and to distinguish the processing performed during separate attempts. This information includes the execution mode, attempt information, execution status, database and repository identity, source and target versions, language settings, update options, Workspace information where applicable, build-plan information, checkpoint and substep state, error information, and applicable log locations.

Do not manually modify the RESUME_STATE_JSON value or the state.json file.

Resume Status Values

The following logical statuses are used for resume processing:

Status Description
SUCCESS The logical operation completed successfully and is not executed again.
SKIPPED The logical operation was not applicable or was intentionally omitted and is not executed again.
FAILED The logical operation failed and is eligible for execution after the failure condition is corrected.
IN_PROGRESS Processing started but completion was not recorded. The operation is treated as incomplete and is eligible for execution.
PENDING The logical operation has not yet been executed.
BLOCKED The logical operation was not executed because a preceding dependent operation failed. It is eligible for execution after the failure point is successfully processed.

The parent execution remains in progress while processing is active and is recorded with a terminal state when the execution completes, fails, or is interrupted. A successful parent execution is not eligible for automatic resume.

Compatibility Validation

Resume processing is permitted only when the saved execution is compatible with the current invocation.

The utility validates the execution entry point and target version, installation location, and applicable repository and Workspace information. The utility also compares the resume-sensitive execution context with the saved execution identity.

Resume-sensitive information can include the following:

  • Repository identity and repository type
  • Database connection identity, excluding credentials
  • Table owner
  • Source and target versions
  • Primary and additional languages
  • Schema, seed, or import-only options
  • Applicable storage settings
  • Workspace values
  • Selected builds and other execution-affecting configuration.

PostInstallDBSetup Resume Processing

PostInstallDBSetup uses the following top-level checkpoints:

Sequence Checkpoint Resume behavior
1 WSRANKING Bypassed when the saved checkpoint is successful or skipped. In an RR environment, the checkpoint is recorded as not applicable and is not executed.
2 SEED_SCHEMA_MANIFEST Re-enters the internal update flow. Completed schema, seed, and manifest logical operations are bypassed; incomplete operations are resumed.
3 WORKFLOW_MIGRATION Executed only after the preceding checkpoint completes successfully. A completed checkpoint is bypassed.
4 TASK_MIGRATION Executed only after the preceding checkpoint completes successfully. A completed checkpoint is bypassed.

Within the SEED_SCHEMA_MANIFEST checkpoint, PostInstallDBSetup maintains logical state for Schema, Seed, and Manifest processing.

For Schema processing, the logical sequence is:

  1. PRE_LOGICAL_SQL
  2. SCHEMA.<build>
  3. PRE_SCHEMA_SQL
  4. DDLDICT_DDLIMP
  5. POST_SCHEMA_SQL
  6. TABLE_PUBLISH

For Seed processing, the logical sequence is:

  1. SEED.<build>
  2. SEED.<build>_UPDATE_FIELD_TYPE, when configured and applicable
  3. SEED.<build>_POST_SEED_SQL, when configured
  4. SEED.<build>_SEED_SQL, when configured
  5. SEED.SEEDCOPY_LOV, when applicable

For Manifest processing, the logical sequence is:

  1. MANIFEST.<build>

For build-specific processing, successful builds are bypassed independently of later failed builds. For a non-build-specific operation, the checkpoint is recorded around the named logical operation. If processing is interrupted during that operation, the operation is executed again when processing resumes.

RepositoryUpdate Resume Processing

RepositoryUpdate uses the following top-level checkpoints:

Sequence Checkpoint Resume behavior
1 SCHEMA Resumes applicable build-level schema processing. Completed builds and completed shared logical operations are bypassed.
2 REPOSITORY Reuses the saved target Development Workspace when valid, bypasses completed preparation operations and files, and retries incomplete repository import processing.
3 SEED Bypasses completed seed builds and configured SQL operations and retries incomplete processing.
4 MANIFEST Bypasses completed manifest imports and retries incomplete builds.

The RepositoryUpdate logical sequence is:

  • Schema
  1. PRE_LOGICAL_SQL
  2. SCHEMA.<build>
  3. PRE_SCHEMA_SQL
  4. DDLDICT_DDLIMP
  5. POST_SCHEMA_SQL
  6. TABLE_PUBLISH
  • Repository
  1. REPOSITORY.<build>_WORKSPACE_PREP, when required
  2. REPOSITORY.<build>_PROJECT_LOCK, when PROJECTS_REPOSITORY is configured
  3. REPOSITORY.<build>_COLLATE_FILES
  4. REPOSITORY.BULK_IMPORT
  • Seed
  1. SEED.<build>
  2. SEED.<build>_POST_SEED_SQL, when configured
  3. SEED.<build>_SEED_SQL, when configured
  4. SEED.SEEDCOPY_LOV, when applicable
  • Manifest
  1. MANIFEST.<build>

Repository Bulk-Import Recovery

Repository files are prepared for the applicable build using generated names based on the following base file types:

  • Repository
  • Repository_A
  • Repository_B

The files can use the SIF or TDF extension.

Each generated Repository file is tracked as a logical substep. The repository bulk import is tracked separately as the BULK_IMPORT checkpoint.

Because the repository import is performed by one bulk command, an interruption or failure does not establish an individual database commit boundary for each generated file. When the bulk import fails, RepositoryUpdate examines the repository import log to reconcile the generated file status.

Files confirmed as successfully processed before the first failed generated file are recorded as SUCCESS.

The first failed generated file is recorded as FAILED and retains the applicable import-log reference and error information.

Generated files after the first failed file are recorded as BLOCKED because their completion cannot be safely assumed.

When RepositoryUpdate resumes, generated files already confirmed as successfully completed are not collated or imported again. The failed file and subsequent blocked files remain eligible for processing.

Before a resumed repository bulk-import invocation, the repository import log and applicable progress information are archived so that diagnostic evidence from the previous attempt is retained.

Note: Repository.log.progress provides supporting progress information. It is not the final basis for determining successful completion of an individual generated Repository file. Final file status is reconciled from the completed repository bulk-import log.

Workspace Behavior

When RepositoryUpdate requires a Development Workspace, the target Workspace associated with the unfinished execution is retained in the resume state.

If the saved Workspace is valid, RepositoryUpdate reuses the saved target Workspace when processing resumes. The utility validates the saved Workspace name before use.

If the saved Workspace value is invalid, normal Workspace naming and selection processing is used.

This behavior ensures that a resumed RepositoryUpdate execution continues to use the Workspace associated with the original execution rather than creating a different target Workspace.

Configuration Requirements

No separate Resume Capability configuration is required.

The feature is enabled during normal utility startup on supported database platforms. No separate feature switch, migration script, or administrator-maintained checkpoint file is required.

Administrators must retain the update history and the associated utility log directory when investigating or resuming a failed update.

Note: Do not manually modify RESUME_STATE_JSON or state.json. Use a normal utility rerun to invoke automatic resume processing, or specify -cleanstart when a new execution is required.

DB2390 Support

Note: Automatic resume processing is not supported on DB2390. On DB2390, PostInstallDBSetup and RepositoryUpdate follow the standard non-resumable execution path.

This limitation is explicitly defined by the feature specification and should appear wherever the common Resume topic might otherwise lead a DB2390 customer to expect resumable execution.

Limitations of Resumable Execution

Resume processing provides recovery from an interrupted or failed update execution. It does not provide transaction-level restart or rollback.

Resume processing does not:

  • Roll back database or repository changes completed before an interruption or failure.
  • Resume processing from the middle of an individual SQL statement.
  • Resume processing from the middle of an external command.
  • Resume processing from the middle of a Workspace delivery operation.
  • Resume processing from the middle of a repository bulk-import command.
  • Use a successfully completed parent execution as the source for a new execution.
  • Override normal concurrent-execution protection.
  • Reuse a saved execution when the current execution context is incompatible.