FPSADMIN.ADM_MONITORING_INSTRUCTIONS

>

> FPSADMIN.WIP_WAFER_HIST_LOOP

View FPSADMIN.ADM_MONITORING_INSTRUCTIONS

Currently it is only necessary to monitor the emails. If we get no emails then I'm pretty confident that everything is going well. There are four types of emails all with different subjects starting with FPSLOAD so it is easy to add an Outlook rule to separate these from regular emails. Here they are in descending order of severity: 1) FPSLOAD ALERT: Every 20-30 minutes we run a separate check on the health of the DWH. This checks the views CHK_INVALID and CHK_DISABLED and the procedure ADM_CHK_TABLE_UPDATES. CHK_INVALID shows invalid objects and tables which had issues with their last load. CHK_DISABLED shows constraints, triggers, and loads which are disabled. ADM_CHK_TABLE_UPDATES queries to see if any key tables like WIP_EVENT_HIST or EQP_EVENT_HIST have no recent data. The ADM_CHK_TABLE_UPDATES email is often sent to key employees of the client including the help desk because this is our most severe alert. All other messages typically just go to FPS or perhaps one or two of our close technical colleagues. 2) FPSLOAD ERROR: Sent for any load error in the Update_by_RTD scripts. The most common error is "SQL errors" which means that the query had errors like PK violated or excess length or whatever. The body of the email includes the query attempted and the error received. 3) FPSLOAD WARNING: Also sent by the Update_by_RTD scripts for things like "Input file garbled" or "No rows updated." These should be addressed but are less serious that the errors. 4) FPSLOAD MESSAGE: These are messages sent from within the XXX_QUERY report. An example is when the report has duplicate records for the PK. In this case, we only insert one of the two rows but we send a message that the report had duplicates. The syntax within the report is to write a query to DELETE FROM FPSLOAD_ERROR WHERE MESSAGE = 'Write message here' and then the script translates this to email the message. When we get an email, we use ADM_LOAD_STATUS and ADM_LOAD_HIST to research the details. Update_by_RTD.log is the log file on the UNIX/Linux server which is basically a copy of ADM_LOAD_HIST but there is no need to use this since ADM_LOAD_HIST has more information and is easier to query. In fact, I can't think of a reason why most of us other than me would need to login to the Linux server at all. Finally our programming team has plans to develop the Factory Forum into a site we can use for monitoring the health of the DWH so we could have some significant improvements once we move to using that site. But this is the situation for now.