Oracle Apps DBA: Keeping E-Business Suite Alive · Module 8 · Concurrent processing
Purging: the table that ate the database
Lesson 91 of 184 · 2 min
Request history grows FOREVER unless something removes it. What to purge, how far back, and THE ESTATE WHERE THIS WAS THE WHOLE PERFORMANCE PROBLEM. Every request leaves a row and two files, and nothing removes them by default. An estate running thousands of requests a day accumulates millions of rows and hundreds of thousands of files, indefinitely. THE CONSEQUENCES ARRIVE IN THREE PLACES AND ONLY THE THIRD IS OBVIOUS. The database grows, so backups take longer and restores take longer — Module 5 Lesson 10's number quietly increasing. Queries against the request tables slow down, which means the request screens get slower for every user and the managers themselves are working against larger tables. And the file system fills, which is Module 3 Lesson 10's failure arriving from an unexpected direction. THE ESTATE WHERE THIS WAS THE WHOLE PERFORMANCE PROBLEM IS NOT A RARE CASE. Years of history, request screens…
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