Below is a quick summary (OnePager) of the most valuable tips and best practices in order to speed up an Oracle Support (MOS) Service Request (SR) resolution:
- Speed up SR creation using:
– Use OCM and System/Target list -> Right Click on a target -> Create SR button (best method for initial SR)
– “Create SR Like Selected SR” (best method in case a similar SR for the same target exists already)
– Using SR Profiles (as alternative in case both above methods are not available/appropriate)
- Provide proper SR description and problem type including all relevant logs, traces, screenshots, etc. right at the beginning
- Open SR with Severity 2 as minimum (in case you want the SR resolution will move during the day)
- Ensure the Oracle Support engineer is in similar time zone (unless it’s 24×7 SR), otherwise request SR reassignment
- Ask for the proper root cause analysis, path forward and detail action plan
- Respond to your action codes fast in SR (Customer Working, Solution Offered) to ensure the SR is moving
- Track Timelines in the SR body yourself (since MOS does not do it properly)
- Speed up communication with Support Engineer using alternative ways:
- Ask Support Engineer to open a chat
- Ask Support Engineer to open a web conference (get instructions from the engineer how to start it)
- Call Support Engineer (call Oracle Support and ask them to connect you to the Engineer)
- Raise SR Severity to 1 (24×7 or during business hours; it works also for test systems!)
- Escalate SR / Request Management Attention
If you have more valuable tips on how to speed up Oracle Support (MOS) Service Request (SR) resolution, share your ideas in comments and/or else like/share it with others.
In this article I’ll share an Oracle RMAN script to do restore and recovery an Oracle database from tape library using EMC NetWorker. Apply this RMAN template to different recovery situations you might have. Before looking into the RMAN script see my notes below:
– Read about Oracle Recovery Manager (RMAN) concepts
– Look at the corresponding RMAN backup script for NetWorker
– The recovery script should work for Oracle database 11g, 12c (maybe 10g)
– Oracle database name = ORCL
– I use 2 RMAN channels to speed up the recovery of database
– Recovery of spfile and/or control file is optional and depends on your recovery situation
– PARMS section includes instructions for EMC NetWorker server (depends on Networker server configuration)
– Choose appropriate database recovery scenario (by default -> compete DB recovery; I commented 3 options for incomplete DB recovery scenario)
– This script is independent from RMAN configuration parameters
Recovery Manager (RMAN) is an Oracle utility that you use to manage the backup, restore, and recovery operations on Oracle database. RMAN has a powerful command language that is independent of the operating system.
Recovery Manager has a command-line interface. Oracle Enterprise Manager (OEM) also provides a graphical user interface for the Recovery Manager. Recovery Manager can be used on databases of Oracle8 or later releases.
RMAN provides several features not available when you make user-managed backups with operating system commands:
- You can store frequently executed operations as scripts in the database.
- Using the incremental block-level backup feature you can limit the backup to only those blocks that have changed since the previous backup. This may also reduce the time it takes to perform recovery operations in ARCHIVELOG mode.
- You can use RMAN to manage the size of backup pieces and save time by parallelizing the backup operation.
- RMAN operations can be integrated with the scheduling of the operating system to automate backup operations.
- You can detect block corruption. The information relating to the block corruption that is detected during backup can be obtained by using the V$BACKUP_CORRUPTION and V$COPY_CORRUPTION dynamic views.
- RMAN provides performance enhancements such as:
-Automatic parallelization of backup, restore, and recovery operations
-No generation of extra redo during online database backups
-Backups that are restricted to limit reads per file, per second to avoid interfering with OLTP work
-Prevention of flooding of any one file with reads and writes while still keeping a tape drive streaming, using multiplexing
- RMAN has a media management API to work seamlessly with third-party media management tools interfacing with storage devices providing increased speed and reliability.
- Under the user-managed method you need to keep track of all database files and backups. In a recovery situations you must locate backups for each datafile, copy them to the correct place using operating system commands, and choose which logs to apply. RMAN manages these tasks automatically.
Recovery Manager Components
If you are not satisfied with the resolution or response to a critical Service Request (SR) at My Oracle Support (MOS), you can escalate it. SR escalation process (formerly known as the Duty Manager Process) is officially known as Requesting Manager Attention to a Service Request. This procedure will facilitate the assignment of a Support Manager [and potentially another support Engineer] to the SR, creation of an Action Plan and as the result it will usually speed up the resolution of the issue.
See below a Workbook of how to properly escalate MOS SR which is based on the Oracle official procedure, best practices and my own experience (this is a draft document -> it will be adjusted based on your valuable comments and experiences that you can post right below this post).
Before Escalating MOS SR
- Raise SR Severity (do not escalate if you have an ability to raise the severity)
- Work properly yourself with SR to avoid delays using the SR Tips and Best practices
- In case you decide to escalate SR ensure the following:
- You have a valid reason and business case at your hands.
- Decide who will be the main contact from your side for the escalation process and that contact information is properly documeted in the SR (either as Primary or Alternate SR contact or if other: place it in SR body).
1. Insert the below template into the SR
This step is optional but makes sense to ensure proper communication Read more »
To minimize downtime during patching of NON-RAC databases Out of Place Patching can be used. You can apply this approach to any Oracle patch starting from Oracle database 11g (22.214.171.124.0+) using OPatch utility. In this case time spent installing the software can be saved from the total database downtime required. However, some downtime is required for switching database services to the new Oracle database home and applying a post-upgrade script. A basic overview of the steps is below:
– Clone the existing database home online
– Apply required patch to the cloned database home using OPatch
– Switch the database services to the cloned database home
– Complete the post installation tasks for the patch applied
– Oracle database 11g and 12c documentation describe DB_HOME cloning only in OFFLINE mode (when DB is down)
– However, there should be no requirement to shutdown any databases, listeners, agents etc. that are running from the source home while cloning the Oracle Home directory because any processes that load the static binaries or libraries into memory should not hold a write lock.
– Oracle Out of Place patching is supported by SAP
– Out of Place patching is a recommended patching method that is used in out of the box deployment procedure of Oracle Enterprise Manager (OEM) Cloud Control 12c+ version
Below we will use a combination of Oracle documentation, a few MOS Notes and a little bit of experience to manually conduct Out of Place patching of Oracle database 12c
Read more »