Database Administration (MOSC)
Discussions
Launch of Descriptive Severity for Service Requests
We are excited to announce that we have improved the Technical Service Request (SR) flow to enable you to provide additional information about your issue.
When creating a Technical SR, you will see three new attributes: Issue Type, Business Impact, and System Lifecycle. The Issue Type attribute allows you to categorize the issue you are experiencing as a Critical Outage, Significant Impairment, Technical Issue, or General Guidance. The Issue Type you select and other information you provide determine the numeric severity assigned to the SR.
We have included tool tips and targeted explanations in the SR flow to provide 'just-in-time' guidance.
For additional help, check My Oracle Support FAQ, Doc ID 2329773.2
To speak to a support representative, contact Oracle Support
Check out a replay of the Webinar event
We are excited to announce that we have improved the Technical Service Request (SR) flow to enable you to provide additional information about your issue.
When creating a Technical SR, you will see three new attributes: Issue Type, Business Impact, and System Lifecycle. The Issue Type attribute allows you to categorize the issue you are experiencing as a Critical Outage, Significant Impairment, Technical Issue, or General Guidance. The Issue Type you select and other information you provide determine the numeric severity assigned to the SR.
We have included tool tips and targeted explanations in the SR flow to provide 'just-in-time' guidance.
For additional help, check My Oracle Support FAQ, Doc ID 2329773.2
To speak to a support representative, contact Oracle Support
Check out a replay of the Webinar event
Global temporary tables create a lot of log switches
On our database we had a log switch every 15-20 minutes.
Recently there was a new feature where on a heavily used screen, we added logic where a stored procedure is filling global temporary tables to calculate a status that the screen needs to show.
Since this was implemented the log switches are happening every 1 minute.
The main global temporary table is "on commit preserve rows" Inserting data and then truncates on next run.
Is it the global temporary tables that create the excessive entries in archive logs? These data will not be needed in case of recovery. Is there a way to see what statement creates most of the REDO information?
3