Oracle Apps DBA: Keeping E-Business Suite Alive · Module 8 · Concurrent processing
Reading a request log
Lesson 87 of 184 · 3 min
Log and output, where they live on disk, and WHAT TO DO WHEN THE LOG SAYS ONLY THAT THE PROGRAM FAILED. Every request produces two files and they answer different questions. The LOG is the diagnostic — what the program did and what went wrong. The OUTPUT is the deliverable — the report itself, the file, the thing the user wanted. THEY LIVE ON THE FILE SYSTEM AND THE APPLICATION SERVES THEM THROUGH A SCREEN, WHICH MATTERS FOR TWO REASONS. When the application tier is unwell you can still read them directly — and Module 2 Lesson 10's map should record the paths, so you are not hunting for them during an incident. And Lesson 10's purge removes them, so an old request may have a status and no files at all. THE HARD CASE IS A LOG THAT SAYS ONLY THAT THE PROGRAM FAILED, AND IT IS COMMON. No…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Apps DBA: Keeping E-Business Suite Alive, with a certificate on completion and a fourteen-day refund window.
In this module: Module 8 · Concurrent processing
- 1What a concurrent request is
- 2Managers, queues and workers
- 3Specialisation rules
- 4Work shifts
- 5A request that will never finishFree preview
- 6Reading a request log
- 7Killing a request safely
- 8Managers that will not start
- 9Output, printing and delivery
- 10Purging: the table that ate the database
- 11What breaks: four concurrent processing failures