Obsidian Tables

Obsidian needs to create and manage the following tables in its target database. When sharing schemas between Obsidian and other applications, ensure there are no naming conflicts by reviewing this list.

Note: Since Obsidian does not run jobs within the same connection or transaction as your jobs, there is no real need to run Obsidian within the same database or schema as your own application(s), though you may wish to do so to facilitate maintenance.

Obsidian can be configured to use a table prefix when creating its tables.

• custom_calendar
• event_log
• event_subscriber
• event_subscription
• global_job_config
• job
• job_chain
• job_chain_mode
• job_chain_mode_condition
• job_configuration
• job_conflict_config
• job_history
• job_history_config
• job_history_chain
• job_history_error
• job_history_interrupt
• job_history_result
• job_running_host
• job_sub_mode_condition
• job_subscription
• job_subscription_job
• job_subscription_mode
• job_state
• notification
• notif_template
• notif_template_entity
• operations_parameter
• role
• semaphore
• sequence_manager
• suite_user
• user_cookie
• user_role

Oracle Privileges

As of version 2.1, if you are not using the schema owner as your Obsidian database user, the following privileges will need to be granted to your database user:

# For each Obsidian table...
GRANT INSERT,SELECT,UPDATE,DELETE ON OBS_JOB TO OBSIDIAN_USER;

# Required for alternate schema usage
GRANT ALTER SESSION TO OBSIDIAN_USER;
GRANT ANALYZE ANY TO OBSIDIAN_USER;
GRANT ANALYZE ANY DICTIONARY TO OBSIDIAN_USER;

MS SQL Server Snapshot Isolation

For maximum compatibility and to avoid deadlocks, MS SQL Server should be configured to use read committed snapshot isolation.

This can be enabled on your database by running the following commands:

ALTER DATABASE MyDatabase SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE MyDatabase SET READ_COMMITTED_SNAPSHOT ON