The key considerations for the technical approach are as below
- Ensure Oracle DBA Best Practices
- Ensure Critical to quality performance metrics of the application are better or at same level after technical upgrade & migration.
- Reduction and Maximization of the time, available resources.
- Reduced APPS DBA Activities risk through phased approach
- Initiating the Functional and Technical customization on the upgraded 11i sun server with migration on going on another server
- Prepare at least two instances of Databases, for APPS DBA and Business functions activities to go in parallel.
- Using the TAR / SR get production instance for testing purpose to iron out any technical as well stress and volume testing issues.
- Go-Live at fastest pace without compromising Quality, Risk and Resource constraints.
- Delivery of all the value added services – postproduction to avoid large outage period and complexities
- Setting up a scalable architecture for future; while increase in users / load / Demand.
- Ensure Oracle Security Best Practices are implemented
- Think Tank (Expert Support) in Critical Activities.
- Holistic Approach for AppsDBA, Sysadmin ,Workflow Admin activities
|Issue Priority||Description||Initial Response Time||Resolution time|
|P1||P1 indicates downtime of a production system, component, or process. This priority requires immediate attention until resolved. This also takes precedence over all other outstanding or underway development work.||15 minutes||Within 2 hours|
|P2||P2 is an indecisive state, which, if possible, should be promoted to either P1 (if the issue requires immediate attention because of unacceptable impact on production) or P3 with a negotiated commit date. Till the time the issue is resolved, it is P2. The team will work every workday until issue is resolved, and send a status update to concerned personnel.||30 minutes||Next business day|
|P3||Issues that are not P1 are P3 or P4. P3 tickets have a negotiated commit date with the requestor to fixing a defect. It is the default priority for most tickets.||1 hour||Within the agreed date|
|P4,P5||P4 tickets are not fixes but these are enhancement requests. Such tickets should always be scheduled against a future release.||1 Day||Within the agreed date|
Technical Scope Specification
Oracle APPSDBA Support For maximum ——Instances.
|1||Prepare inventory of Oracle Application Software Installed Products, Instances Inventory Documentation including Custom and Bolton, other software used for reading and interfacing with Oracle.||iWare Logic|
|2||CLIENT-Oracle User Requests|
|2.1||Response to User Requests for Services thru CLIENT internal mail system||iWare Logic||CLIENT-users||Evaluate and take action to close high priority immediately and balance in queue for closure depending on the load.|
|2.2||Prepare Issue log on Requests not as per process or beyond Support areas||iWare Logic|
|3||Oracle Application Maintenance Prepare Documentation for Daily, weekly, Monthly Activities and procedures.||iWare Logic||Daily|
|4||Clonning : On request or planned schedule||iWare Logic||As per Requirement|
|5||Applying Patches (Std Apps/Localization)||iWare Logic||As per Requirement|
|5.1||Problem Definition||CLIENT/iWare Logic||iWare Logic||As per Requirement|
|5.2||Identifying the patch and related Patches||iWare Logic||As per Requirement|
|5.3||Authorization to Apply patch on Dev or specified env||CLIENT||As per Requirement|
|5.4||Downloading the patch||iWare Logic||As per Requirement|
|5.5||Advise on impact of patch to requester||iWare Logic|
|5.6||Applying Patches on DEV/other Instance||iWare Logic||As per Requirement|
|5.7||Post Patch Applications Testing||CLIENT||As per Requirement|
|5.8||If Patch fails – raising a TAR / SR / SR||iWare Logic/CLIENT||As per Requirement|
|5.9||TAR / SR / SR Follow-up||iWare Logic/CLIENT||Daily|
|5.10||If Patch is successful on Test then Authorization to Apply patch on Production||CLIENT||iWare Logic||As per Requirement|
|5.11||Applying Patches on Production||iWare Logic||CLIENT||As per Requirementt|
|5.12||Post Patch Application Testing on Prod||CLIENT||As per Requirement|
|5.13||Updating Patch Documentation on various Specified Instances||iWare Logic||As per Requirement|
|5.14||Archiving Patch at Secured Place provided by CLIENT||iWare Logic||As per Requirement|
|6||Oracle Application, Oracle database and other server related Errors||iWare Logic||As per requirement|
|6.1||List of Errors & Solution||iWare Logic||As per Requirement|
|6.2||Testing of fixes & acceptance||CLIENT||iWare Logic|
|6.3||Maintain Troubleshooting Log with details on fixes||iWare Logic|
|6.4||Call Oracle for Support||iWare Logic||As per requirement|
|7||Oracle Error – Problem Solving||iWare Logic||As per requirement|
|7.1||List of Errors – Solution on it||iWare Logic||As per requirement|
|7.2||Notify for known bugs by Oracle for fixes in Future||iWare Logic||As per requirement|
|8||TAR / SR / SR Management||iWare Logic||Daily|
|8.1||Maintaining Previous TAR / SR / SR Records||iWare Logic||Daily|
|8.2||Raising iTAR / SR / SR||iWare Logic/CLIENT||As per requirement|
|8.3||Maintaining Logs related to TAR / SR / SR||iWare Logic||Daily|
|9||Oracle Security||iWare Logic||Daily|
|9.1||Password Changes in all D’base and Applications in CLIENT||iWare Logic||As per requirement|
|9.2||Oracle ID Creation||iWare Logic||One time activity|
|10||Using Oracle based Alerts||As per requirement|
|11||Space Management Space Management on Disk Log maintenance, Alert Log Maintenance. Purging old requests and logs||iWare Logic||Daily|
|12||Database Audit||iWare Logic|
|12.1||Check space used on disks||iWare Logic||Daily|
|12.2||Check free tablespace||iWare Logic||Daily|
|12.3||Decide on how many days requests and logs are to be retained||iWare Logic/CLIENT||Once|
|12.4||Archiving & deleting old .req, .log files||iWare Logic||Schedule|
|12.5||Purge Data from various tables based on plan and schedule or size limits||iWare Logic||Requires Planning and growth check limits|
|12.6||Data Archive Planning & implementation for Transaction data Archiving||iWare Logic/CLIENT|
|13||Backup Strategy||iWare Logic||Once|
|13.1||Backup Logs Monitoring||iWare Logic||Daily|
|13.2||Recovery Mechanism||iWare Logic||Test Procedure|
|13.4||Processes for Backup, service requests, etc to be made, documented, maintained and implemented.||iWare Logic|
|14.1||Performance Tuning Database tuning||iWare Logic||As and when required|
|14.2||Performance Monitoring||iWare Logic||Parameters based Checks|
|14.3||Response Time Improvement||iWare Logic|
|14.4||Call Hardware Vendor and vendors to improve Network, Systems related Performance or Advisory||iWare Logic||Hardware Vendor for advice|
|15||Setup and implement various Maintenance Processes for CLIENT|
|15.1||Request Services||iWare Logic|
|15.2||Issue Escalation||iWare Logic|
|15.3||Security Changes||iWare Logic|
|15.4||Backup, restore||iWare Logic|
|15.5||Disaster Recovery||iWare Logic|
|16.1||User / Responsibility Management||iWare Logic|
|16.2||Concurrent Manager Management||iWare Logic|
|16.3||Workflow Admin||iWare Logic|
System Up Time:
- iWare Logic assures System Up Time will be 99 %.
- The up time will be calculated for assigned service time only.
- Some exceptions & assumptions for system shutdown like shut down request from CLIENT team on account of functional issues, which will not be part of up time calculations.
- Connectivity failure/speed issue will not be part of up time calculations.