Oracle Service request escalating procedure

For Critical Needs of any kind, please follow the escalation process to help expedite resolution.

Dial 800-223-1711, use your CSI number, tell the dispatcher that you already have a SR and provide it to them. They will notify the appropriate Duty Manager immediately for callback.

Escalating Issues - The Oracle Support Services Escalation Process
Frequently Asked Questions (FAQ)
1. When should you escalate a Service Request?
2. How do you request a Service Request Escalation?
3. What can you expect after you request a Service Request Escalation?
4. What are the benefits of using the Service Request escalation process?
5. De-escalating a Service Request
1. When should you escalate a Service Request?
Use the Oracle Support Services Escalation Process when your business critical issue requires a higher level of attention from Oracle Support Services Management.
This process should be utilized when you:
• encounter a critical roadblock or showstopper to implementation or upgrade plans
• urgently need to communicate important business issues to managers in Oracle Support Services
• are dissatisfied with the resolution or response to a Service Request
If a critical problem is encountered, consider the timing of when to escalate an issue. Waiting to escalate may leave little time to research the root cause of the problem and develop the most effective solution. Large, complex problems take time to resolve. Advise Support of the target dates and deadlines you have for critical issues. Document the deadlines in the Service Request, along with a statement of its impact on your business or the risk it poses to your implementation plans.
Requesting escalation will ensure attention on your issue but may not change resolution time depending on the complexity of the issue at hand – support management will be engaged.
This process should not be utilized when
• the business impact of the issue has increased
• the business impact of the issue was incorrectly stated initially
If the business impact has changed – or was incorrectly set – you should consider requesting a change of severity rather than escalation of the Service Request. While an escalated Service Request will require both your own management and managers at Oracle to become engaged, resetting the severity can be negotiated directly with the owning Support Analyst.
Raising the severity will ensure increased global focus and co-operation within support, to solve the issue in an appropriate timeframe – Additional technical resources may be engaged.
Please see the section Severity Definitions in Technical Support Policies.
2. How do I request a Service Request Escalation?
Before calling Oracle Support, review your Service Request and update it if necessary.
• Is the problem statement correct?
• Does the Service Request describe the impact to your business or the risk to your implementation plans?
• Is the Service Request severity level appropriate?
• If there is a workaround, is the workaround impractical or inappropriate?
• If there is a business milestone date or an implementation milestone date, is the actual calendar date identified in the Service Request?
Once you have completed the review, should you still need to escalate your Service Request, simply telephone Oracle Support as if you were going to log a new technical issue. When you reach a Dispatcher, provide the Service Request number and ask for the Service Request to be escalated.
You will be asked for a business justification for the Service Request escalation and for yours and your manager’s contact information.
The Support Analyst will then engage the Service Request Escalation Owner who will be responsible for managing your escalation.
Requesting a Service Request escalation via Metalink is also an option; however, the same escalation information must be provided in the Service Request. Please be aware that Service Request updates may not be reviewed immediately and may contribute to delays in acknowledging and handling your escalation request. To avoid delays in handling and acknowledging your escalation request, telephone Support and ask to escalate your critical Service Request.
If you do choose to request escalation via MetaLink please complete and insert the template below – including all ”*-lines”. This will ensure correct visibility and content.
******************* Escalation Request *******************
Reason for escalation, including business impact of the problem that requires escalation
Business or implementation milestone, critical date(s) (milestone date or resolve by date), along with the type of business or implementation milestone
Name of the person requesting the escalation, contact information: phone number, pager, email address
Customer manager escalation contact and contact information: phone number, pager, email address
******************* Escalation Request *******************
3. What can you expect after you request a Service Request Escalation?
If you have telephoned to request a Service Request escalation, the Service Request Escalation Owner will make every effort to call you back within 30 minutes. While it is our intention to call back in approximately 30 minutes, there may be occasions when the call back may be delayed. This guideline is provided to help you plan your availability for a call back rather than to guarantee the actual call back time.
The Service Request Escalation Owner is a manager who will work with the Support Analyst owning the Service Request, to review your escalation request. The Escalation Owner will then develop an action plan with you and allocate the appropriate Oracle resources. The action plan will be recorded in the Service Request. The Service Request Escalation Owner will also ensure that the appropriate resources are assigned and all actions are completed. The Action Plan may include tasks for both you and Oracle. Before leaving the call, make sure you know who owns the next action and that you have identified a communication plan. Most escalations are successfully resolved at this level. If the action plan fails to deliver expected results, please contact the Service Request Escalation Owner to review or to escalate the Service Request to the next level if required.
As work on the issue progresses, continue to make sure that your Service Request is a complete record of your actions and concerns. Save time by keeping it up-to-date and ensuring it reflects changes in frequency or urgency. If changes or additions to the Action Plan are made, document these in the Service Request. Documenting each escalation within the Service Request ensures a clear history of the issue and what actions have failed to address it. This documented history assists in evaluating the resources required to resolve this problem.
4. What are the benefits of using the Service Request escalation process?
Use the Service Request Escalation process to ensure Oracle Management attention to your issue, and to facilitate the creation of an Action Plan to resolve the issue with your deadline clearly stated. It also allows Oracle management to effectively and promptly assign the required resources to resolve your problem.
Consider that routinely escalating non-critical issues or consistently overstating the criticality of escalated Service Requests may result in a misunderstanding of the importance or critical impact of a future escalation. Prudent use of the Service Request Escalation process enables Oracle to accurately prioritize your critical issue.
5. De-escalating a Service Request
When a Service Request meets the de-escalation criteria or is no longer critical, it should be de-escalated by contacting the Escalation Owner.
Before de-escalating a Service Request, the Escalation Owner will:
• confirm with you that the action plan has been completed or the request cannot be fulfilled (i.e., specific functionality is not and will not be available in the Oracle product).
• document your agreement to de-escalate the Service Request.

Download and Installation steps for Setup loader Utility

Download and install the Setup Loader Utility: Before the official kick-off of the Implementer Workshop, your Oracle Accelerators trained DBA needs to complete the installation of the Setup Loader utility. This is a 3 step process:

Step 1: Enter a Service Request (SR) for Setup Loader utility
• Log a Service Request in My Oracle Support requesting the Setup Loader Utility (SLU) download.
• This service request triggers the generation of a Request Identification Number (RIN).
• Plan a lead time of three business days for this request to be fulfilled.

Step 2: Download & install Setup Loader Utility
• Go to E-Delivery area on Accelerators Online and paste the RIN.
• You will be presented with links to download the Setup Loader Utility.
• Download all the disks (using a Download Manager) and install on your hardware.

Step 3: Download and run the Oracle Business Accelerator Diagnostic Utility (OBADU)
• An Accelerator trained DBA must read My Oracle Support Note 549683.1 and download the OBADU.
• The OBADU gathers and reports E-Business Suite environment information to help the implementer DBA assess whether the install is successful.
• DBA must run the OBADU to verify the installation. The OBADU output will inform the DBA of appropriate actions to take if any steps have errored out.
• If unable to resolve issues, the DBA may raise a My Oracle Support Service Request and attach the output of this utility.

Step 4: Full Backup of OBA Installation
• After validating the installation execute a full instance backup.
• This back up will be used to refresh the installed E-Business Suite quickly as required.
Further reading:
• My Oracle Support Note 456200.1: Leading Practice: Setup Loader Utility install
• My Oracle Support Note 471411.1: Accelerator Project Tasks and Times
• My Oracle Support Note 430777.1: Release 12 Installation FAQ
• My Oracle Support Note 554318.1: Using Download Manager for OBA Setup Loader Utility
• My Oracle Support Note 549683.1: MANDATORY DOWNLOAD: OBA Diagnostic Utility for e-Business Suite Available
• 'Install Related' section in the Accelerator Knowledge Browse Area on My Oracle Support


Applies to:
Oracle Accelerators
Linux x86
Linux x86-64
What is being announced?
Oracle Business Accelerator Diagnostic Utility (OBA DU) for eBusiness Suite is available for download.
The Diagnostic Utility is a set of command line diagnostic scripts used to gather and report information about an Oracle Business Accelerator for E-Business Suite environment. The utility generates formatted output displaying useful system information for the implementer DBA to assess whether the install is successful. The output also informs the DBA on the appropriate actions to be taken, if necessary, on various steps that have errored out.
Who should download the Diagnostic Utility?
An approved DBA MUST download and run the Diagnostic utility to verify that the install is successful. This is mandatory before running the Configuration Tool. In case the DBA is unable to fix the issues as per the suggestion(s) noted in the Diagnostic Utility report, then the DBA must raise a Service Request on My Oracle Support against Oracle Accelerator product (Product ID: 1690) with the Diagnostics report output to expedite the resolution of install issues.

What do you need to do?
Steps to download the Diagnostic Utility are as follows:
1. Log in to Accelerators Online with your SSO Login ID.
2. Click on the Oracle logo under section E-Delivery. Click on Continue button.
3. Check two check-boxes for Customer License Agreement and Click Proceed button
4. Enter the Request Identification Number provided below and click proceed (while you copy-paste the Request Identification Number make sure you DO NOT have any spaces, it should be one continuous number from the start to he end)
Request Identification Number for Linux:
DC24713F486F631F0B6A989DAAB1035640B20DF8E2B6882774E6211724A8A9335B27719DCB8FE88B44DB5F0F8001D2D7D1402064CA1FDFBE7C4D5833DCE7BB027E2695BDB799EFAA1F5F43C4B4FB8EA1637C20A128F99F7CE69C2B5B648345B5A1D87FB738D82629294D3B4A2C4CCEF93A804EBCF8F3399021ED2C8B1328288F628912AB3D982445BD601EEC73BF424A674F264335750DAE6B7104F3D2DC0F12BB097128B2593683
Request Identification Number for Sun Solaris:
DC24713F486F631F0B6A989DAAB1035640B20DF8E2B6882774E6211724A8A9335B27719DCB8FE88B44DB5F0F8001D2D7D1402064CA1FDFBE98C7140AA52CA756554A6CD4B92355B15FC93B60539D524609916829440987C687607C56B323F025C3E775EE5C60D9DA70B04CFC854F178850B24CB3123749B26E577F9397A3DDF091283CBBB660A7798FE53C4E95468A1DE9B50A06A2E62608AB6AB54D70066775E181503DBEC90E4F8C904236CA4ECED9
Notes:
1. The Accelerator Diagnostic Utility is NOT part of Oracle Support Diagnostics (see E-Business Support Diagnostics Overview)
2. The Utility has been designed for use by Oracle Application DBAs on Oracle Business Accelerator environments only
3. The utility does not alter any data or configuration in your system
4. For accurate diagnostic information, the utility needs to be executed on both Application and Database tiers.
5. OBA DU must be run every time a new instance is created, or when an instance is refreshed with a previous backup that was taken after installing the Setup Loader Utility. This is a MANDATORY step prior to requesting a Pre-Project Review and should constitute as the sign-off step for the DBA before handing over the instance to the Project Manager.
6. OBA DU output must be verified by the DBA and checked for any errors (navigate to the Instance Information link in the file index.html.) Any error must be corrected as per the instructions.
IMPORTANT: You MUST upload the OBA DU output to a pre-project review for every OBA project.
---------------------------------------------------------------------------------------------------------
Common Errors: Following are the common errors seen in OBADU output
1. Display Variable set incorrectly - ensure that the DISPLAY (“s_display”) value in $CONTEXT_FILE is updated to a valid working VNC or to an Xserver console value and run AUTOCONFIG. (Example: :10.0). VNC should not be started on port 0:0
2. SWAP memory is less than the size of the Physical memory on the server - Although this is shown as an alert, please note that this will impact your performance, so ensure that minimum SWAP is twice the size of the Physical memory.
3. UTF8 characterset is not used - by default OBA installer selects UTF8 characterset, and if this is overriden then install errors will occur.
Who to contact for more information?
If you are unable to resolve any errors, then log an SR on My Oracle Support against Oracle Accelerator product (id: 1690) and upload the output for verification.

Big patch failure because of prerequisite patch

When you are applying a Big patch which will take around 10 hrs. Now 5 hrs of the patch has been completed and now errored out due to some pre req patch. So now we can follow the steps given below and the resume the remaining part of the patch.

Solution:

1. Using the adctrl utility, shutdown the workers.

a. adctrl

b. Select option "Tell worker to shutdown/quit"


2. Backup the FND_INSTALL_PROCESSES table which is owned by the APPLSYS schema


a. sqlplus applsys/

b. create table fnd_Install_processes_back as select * from fnd_Install_processes;

c. The 2 tables should have the same number of records. select count(*) from fnd_Install_processes_back; select count(*) from fnd_Install_processes;


3. Backup the AD_DEFERRED_JOBS table.


a. sqlplus applsys/

b. create table AD_DEFERRED_JOBS_back as select * from AD_DEFERRED_JOBS;

c. The 2 tables should have the same number of records. select count(*) from AD_DEFERRED_JOBS_back; select count(*) from AD_DEFERRED_JOBS;


4. Backup the .rf9 files located in $APPL_TOP/admin/restart directory.

At this point, the adpatch session should have ended and the cursor should be back at the Unix prompt.


a. cd $APPL_TOP/admin/

b. mv restart restart_back

c. mkdir restart


5. Drop the FND_INSTALL_PROCESSES table and the AD_DEFERRED_JOBS table.


a. sqlplus applsys/

b. drop table FND_INSTALL_PROCESSES;

c. drop table AD_DEFERRED_JOBS;


6. Apply the new patch.


7. Restore the .rf9 files located in $APPL_TOP/admin//restart_back directory.


a. cd $APPL_TOP/admin/

b. mv restart restart_

c. mv restart_back restart


8. Restore the FND_INSTALL_PROCESSES table which is owned by the APPLSYS schema.


a. sqlplus applsys/

b. create table fnd_Install_processes as select * from fnd_Install_processes_back;

c. The 2 tables should have the same number of records. select count(*) from fnd_Install_processes; select count(*) from fnd_Install_processes_back;


9. Restore the AD_DEFERRED_JOBS table.


a. sqlplus applsys/passwd

b. create table AD_DEFERRED_JOBS as select * from AD_DEFERRED_JOBS_back;

c. The 2 tables should have the same number of records. select count(*) from AD_DEFERRED_JOBS_back; select count(*) from AD_DEFERRED_JOBS;


10. Re-create synonyms


a. sqlplus apps/apps

b. create synonym AD_DEFERRED_JOBS for APPLSYS.AD_DEFERRED_JOBS;

c. create synonym FND_INSTALL_PROCESSES FOR APPLSYS.FND_INSTALL_PROCESSES;


11. Start adpatch, it will resume where it stopped previously.