Data Dictionary
>
FPSADMIN Tables
> FPSADMIN.CFG_SCHED
Table FPSADMIN.CFG_SCHED"
Provided with the FPS DWH is a robust loading system that can either be driven via scheduler jobs within the Oracle database itself via cron on a UNIX/Linux system. <C2><A0>Standard load types are done via APF/RTD and PL/SQL. <C2><A0>C# loaders can also be provided/written if necessary or we could potentially use any other ETL tool that is available. This particular table is where the schedule is maintained so all other ADM_LOAD tables support the schedule specified here.
-
Schema: FPSADMIN
-
Tablespace: FPSDATA
|
Column |
Type |
Nullable |
Comment |
|---|---|---|---|
|
LOAD_JOB |
VARCHAR2(10) |
Name of load job (* from FPSADMIN.CFG_JOBS) |
|
|
OBJECT_NAME |
VARCHAR2(30) |
This could be an object name (we will disable loading of that object in the scheduled jobs), a load job (we will disable loading of all objects in that scheduled job), an FPSAPP prefix (we will disable loading of all objects with that prefix), a constraint (we can explain why it is permanently disabled), or a trigger (technically an object so we can get away with omitting this from the column name and also to explain why it is permanently disabled). (* from FPSADMIN.CFG_DISABLED) |
|
|
DO_NOT_COMMIT |
CHAR(1) |
If this is set to Y then we will not commit after this object. This allows an entire job consisting of multiple objects to run and then commit at the end. Our 3min job must have this flag set to Y. |
|
|
LOAD_ORDER |
NUMBER(3) |
Order of objects to load within the load job |
|
|
WARN_SEC_IF_OVER_ONE_MIN |
NUMBER(4) |
Our default warning limit for CHK_SLOW is over one minute but many jobs, particularly those which are shiftly or daily or weekly, normally take longer. Once an acceptable time is established for a long running job enter about 25% higher here then the object will only appear in CHK_SLOW if it gets slower. |