...
- MITID - Ross used to support this
- Admissions load - Ben
- Test score load - Monica
- Current person load - ???? DBA's
Tests had been co-ordinated with developers and DBA for the above batch jobs and functions. The test results shows that all jobs and functions completed successfully with no
to minimal difference in performance when compared to the metrics of the production run.
The following is some details about the run:
- Test Scores Load - Monica used the largest input file (which is about 100 times larger than regular daily run) in the current year for the test score load in TEST. It takes about 13 minutes to finish, which is normal according to her.
- UA Load - The uaload completed in about 18 minutes with the data file provided by Ross in Dev, with no errors.
- MIT ID - The mit id processed around 1600 records in 24 minutes in Dev environment, it is about the same in performance from what I remembered.
- Current Person Loads - DBA conducted the tests for us. According the information provided by them, all jobs successfully completed in Test except SXP_UPDATE_FROM_DW_KRBPERSON. All jobs finished within minutes and took about the same time when compared to production runs statistics
- SATURN.SXP_UPDATE_FROM_DW_KRBPERSON - the script was later updated with the latest changes to resolve the failure due to changes to the data warehouse tables. The first run of the script in Test SATURN.SXP_UPDATE_FROM_DW_KRBPERSON took 5+ hours, but subsequent runs were in line with the time taken in daily production runs. Semyon and Raia had looked into the 5 hours run and discovered that the script itself does not use SPRIDEN at all. They are looking into whether the long elapse time of the first job was due to the fact there might be occasional big volume of data in a day and that the job had not been run for a while in TEST. But as it did not reference SPRIDEN at all, DBA concluded that the additional new indexes to SPRIDEN do not have any impact on the SXP_UPDATE_FROM_DW_KRBPERSON job.