The following table lists some of the additional users and databases created during the installation process at System Initialization (Sysinit) or database initialization time.
|
System Database/User |
Description |
|
CRASHDUMPS |
Note: CRASHDUMPS is defined in the Data Dictionary when the DIPCRASH script is run during the DIP phase of installation, migration, or upgrade. This user is created for use by the system for logging internal errors. Adjust the space allocation accordingly and monitor its usage. For more discussion, see “Configuring the Crashdumps Database” on page 558. CRASHDUMPS provides temporary storage of dumps generated by the Parallel Database Extensions (PDE) software. You may need to allocate more PERM space, based on the size of your configuration, to accommodate at least three dumps. |
|
Sys_Calendar |
Note: Sys_Calendar is defined in the Data Dictionary when the DIPCAL script is run during the DIP phase of installation, migration, or upgrade. This database contains tables and views related to the system calendar, including the Calendar view, which is a user-accessible tool for date arithmetic. For more information, see “CALENDAR System View” in Data Dictionary. |
|
TD_SYSFNLIB |
Note: The TD_SYSFNLIB system database is created when the DIPDB or DIPALL scripts are run during the DIP phase of installation, migration, or upgrade. This database contains the non-type-specific embedded services functions offered as part of the database release. For details on embedded services functions, see SQL Functions, Operators, Expressions, and Predicates. Note: Do not create any database objects in the TD_SYSFNLIB database. The TD_SYSFNLIB database is for internal use only. |
Note: ALL, DEFAULT, and PUBLIC may appear as databases or user names but actually have no content, no tables, no views, and users cannot log onto them. They are defined with no PERM space and are used by the database system software. For more information, see “Special Keywords” in Data Dictionary.
User DBC not only owns all these system databases/users but has access to everything in the system because it has privileges on everything as well. Therefore, rather than use DBC to manage the system and risk accidentally changing the system users, create an administrative user to manage the system.