This SLA is current as of 3/25/2019. See Appendix C for revisions to this document.
Services provided by the ITS Database team are clearly documented in the ITS Service Catalog.
Services are provided on a chargeback basis.
At the discretion of the ITS Database team, services provided outside the scope of this SLA are subject to an additional cost.
The service includes 20 hours annually for database administration support for application upgrades, database design, and database administration consulting. For services outside the scope of this SLA, any hours above the included 20 hours are treated as hourly projects and billed at the ITS Database team hourly rate.
Changes to services will be communicated and documented via the change notification process.
Services will be provided in adherence to any related policies, processes, and procedures.
Scheduling of all service-related requests will be conducted in accordance with the ITS Database team SLA.
In the event of a disaster or if the Data Center is not accessible, applications will be restored in priority order per the Emergency Operations Center direction.
ITS Database rates are based on a cost recovery methodology to recover the operational and capital service costs of providing ITS Database environments for the customer. The customer will select from a list of service offering options and be charged the appropriate fee that has been reviewed and approved by the Office of Accounting's procedure for Costing and Analysis. Fees will be charged and transferred once per fiscal year at the beginning of the university fiscal year. Time is recorded based on 15-minute increments of work effort.
Items not covered in this SLA are subject to additional published hourly Time & Materials (T&M) charges. The ITS Database team manager will review estimated costs for the upcoming year for each Customer no later than 3 months prior to the next fiscal year. Significant changes will be noted and a revised estimate will be issued to the requesting Customer. If, during the fiscal year, there is a significant and/or extreme change to the ITS Database infrastructure, the rates will be reviewed. In rare circumstances, this review may result in a mid-year change to the current recovery rate.
In order to protect the interests and assets of the University of Texas at Austin, ITS may be required to render services beyond those described in this document. Such additional support is provided at the discretion of University senior management with Customer consultation. This work may result in additional charges.
Roles and Responsibilities
|ITS Systems Database Team Manager||Chris Owanfirstname.lastname@example.org||512-232-2463|
|Primary Customer Technical Contact|
|Secondary Customer Technical Contact|
|Customer Billing Contact|
ITS Database Team Responsibilities
ITS Database team responsibilities and/or requirements in support of this SLA include:
- Appropriate notification to Customers for all planned maintenance events via the IT Maintenance Calendar.
- The application owner, technical contacts, and other outage contacts as provided by the customer to the ITS Database Team and maintained in the ITS Database team inventory, will be notified by email for planned maintenance and service outages.
- Production, Quality Assurance (QA), and Development databases are monitored 8:00 am to 5:00 pm, Monday through Friday, excluding University holidays and announced University closures. During these hours, response time to page is 30 minutes for Production and 60 minutes for QA and Development.
- Production databases are monitored for outages 24x7, however, response time outside of the 8:00 am to 5:00 pm window above is not guaranteed except during times when the customer has opted to contract for optional Off-Hours Support.
- Provide database host operating system technical support and problem resolution.
- Provide patch management for installed software on the database host systems. ITS will install, support, and maintain the installation of patches and firmware. ITS will also manage the hardware and operating system of each server under this SLA.
- Maintain server security in accordance with the CIO's Campus IT Policies.
- Respond to Customer inquiries in a professional and timely manner.
- Assist with database server life-cycle management.
- Implement a standard data backup strategy based on industry standard best practices such as the ITS defined Oracle Backup Standards and Best Practices.
- Provide monitoring for system performance, databases, and networking.
- Operational monitoring is provided for all managed systems. The monitoring system is configured to display an alert to the University Data Center Operators between 8:00 am and 5:00 pm daily if a critical error condition is detected on Production systems as well as send email alerts to responsible staff 24x7 for all systems managed by ITS Database staff.
- When it is determined that an application or database user is causing major performance issues for all other resources in a shared database services environment, the ITS Database team reserves the right to temporarily suspend passwords, account(s), access, or usage by any rogue database user and notify departmental technical contacts.
- Maintain a Customer hardware and software inventory that will be updated at least semi-annually.
- Create and maintain site-specific manuals that will include server build documentation.
- Coordinate with other ITS Departments and 3rd party vendors as needed.
- Log changes to any server’s environment using a change management system.
- Perform planned maintenance on a scheduled basis during the maintenance window published in advance by the ITS Database team.
- Provide the Customer with notification of service disruptions and emergency maintenance as soon as feasible.
- Review each service annually, or as agreed by both the ITS Database team and Customers, to evaluate the IT needs of the Customers and provide appropriate recommendations.
Customer responsibilities and/or requirements in support of this SLA include:
- Provide and maintain technical contact information to the ITS Database Team using the ITS Database Owner Report Tool. Customers must assign and maintain an on-site departmental technical contact (liaison) for the ITS Database team. The technical contact will provide application support for the Customer’s application and/or act as a liaison to the Customer’s application support group.
- Provide and maintain owner/executive sponsor contact and billing contact information to the ITS Database Team using the ITS Database Owner Report Tool. Failure to maintain updated contact information and any inability of the ITS Database team to establish communication with the Customer's contacts may result in the suspension or decommissioning of provided database resources and services at the discretion of the ITS Database team.
- Perform application testing for all patches, upgrades, and database changes in a timely manner. This includes the responsibility for creating and maintaining a set of testing use cases that will be used by the customer to perform acceptance testing when the ITS Database team is applying database version upgrades, hardware migrations, etc.
- All customers should review the Database Customer Testing Plan - Public Version, which describes the testing responsibilities of both the ITS Database team and Customer.
- Notify application end users of any service interruptions or outages.
- Be available when resolving a service-related incident or request.
- Communicate specific service availability requirements to the ITS Database team.
- Provide a security contact and respond to ISO alerts with regard to their application.
- Upgrade to the currently-supported version of application software if their databases are in a shared environment.
- Adhere to the UT Austin Information Resources Use and Security Policy and associated standards as they relate to the acquisition, development, testing, implementation, and production usage of servers, software, applications, networking, related systems, or data stored on their respective systems. The Customer also agrees to adhere to the Minimum Security Standards for Application Development and Administration and the Secure Web Application Coding Guidelines when deploying custom-developed applications that utilize ITS-supported databases.
- The ITS Database team may temporarily suspend customer password(s), account(s), access, or usage to ITS database services if the Customer or their users violate University policies or do not maintain the minimum security standards as outlined in this SLA and defined by the Information Security Office. The Information Security Office reserves the right to shut down or isolate any system that is found to be out of date, vulnerable, or compromised.
- The Customer is the steward of their department’s data and must categorize that data according to the UT Austin Data Classification Standard.
- Customers storing Confidential Data (formerly known as Category-I) in their databases must notify the ITS Database team, register their application with the Information Security Office, and ensure that their application follows best practices for security. This includes adhering to the Minimum Security Standards for Application Development and Administration.
- Anyone with database credentials will need to review (on an annual basis) and comply with the UT Austin Information Resources Use and Security Policy.
- Assign a security contact that approves accounts and permissions and is typically the same contact as the Data Owner.
- Submit service requests through an appropriate ticketing system by sending email to email@example.com.
- The application support group will triage all end user and development team issues to identify the root cause of any problems and engage the application vendor, if applicable, prior to contacting the ITS Database team for assistance.
- Use the processes defined in this SLA document for requesting help and services.
- Respond to ITS Database staff inquiries in a professional and timely manner.
- Agree to a predefined maintenance window for scheduled maintenance, either for the site or by system.
- Maintain compliance with all software licensing requirements. The Customer must provide the necessary access to software and training for specialized departmental or proprietary services where required.
- Consult with the ITS Database team before making any application software or hardware purchases related to systems that will be utilizing ITS Database services. Any such software or hardware purchased without consultation with the ITS Database team may not be supported under this SLA.
- For systems supported by the ITS Database team, adhere to a hardware and software lifecycle which meets or exceeds the minimum configuration requirements based upon recommendations provided by the ITS Database team.
- Maintain hardware warranties or provide timely payment for repair charges (T&M) for any Customer-provided equipment covered under this SLA and pay for software costs associated with required upgrades for new features or security concerns.
- Develop, install, configure, maintain, patch, upgrade, troubleshoot, and secure their business software. Any assistance requested from the ITS Database team to meet these obligations may involve a T&M charge.
- Any changes made to a system/service not reviewed by the ITS Database team and results in requiring the assistance of the ITS Database team may be subject to a T&M charge.
- Prompt payment or provisioning of an appropriate chargeback account.
- Promptly inform the ITS Database team when any staff, faculty, or student that has been provided database credentials associated with a provided database service has had a change in their affiliation with the University, so that the ITS Database team can take the appropriate measures to secure any associated database account credentials. Measures taken may include locking accounts, changing passwords, and/or removing accounts.
Database Accounts and Permissions
It is a best practice to develop database roles with the appropriate permissions required for database objects. Individual user accounts are then granted access to the database roles for their function. In general, permissions should be granted on a least-privilege basis to perform the required business functions.
Please work with DBAs to design the appropriate security to support the application's functions.
Changes to database objects are migrated to QA/Qual and Production by Database Administrators or the designated Application DBA(s). The migration to QA allows the Developers and Database Administrators to test that all the necessary objects are included in the migration prior to Production. This separation of duties also meets audit internal control requirements and general best practices.
Development Database Environment Usage
Used by Developers for implementing new applications or changes to the application and database environment.
Developers should not allow customers to use their Development environment.
For teams with multiple Developers, a separate integration schema in the Development instance can be used for unit testing.
Quality Assurance Database Environment (QA/Qual) Usage
Changes to database objects are migrated to QA/Qual once a developer has completed unit testing in development.
Customers test the application enhancements and/or database patches or upgrades promoted from Development in QA/Qual environment.
After functional testing and approval, requests that the changes tested in QA can be migrated to Production by the DBAs.
Production Database Environment Usage
Database that supports the live production application for general users.
Database Environment Account Management
Developers are provided individual database accounts that have permissions to create and drop database objects, insert, update, delete and select data in their Development schema(s)/database(s).
The database permission in QA should be the same as they are in Production.
An application account can be provisioned. The application account typically can insert, update, delete and select data schema(s)/ database(s). Permissions for the application account to create or drop database objects are generally avoided.
The application account database permissions in the integration schema/database should be the same as production.
The database permission in QA should be the same as they are in Production.
The application account has the permissions required for the application.
Database System Permissions
- Database system level permissions are typically not provided to Developers or Application Accounts to protect the security of all applications' data in a shared database environment
Provisioning and Maintaining Accounts
The Primary Technical Contact will be considered the Developer Account Steward.
All provisioning requests for Developer Accounts requests should come from the Primary Technical Contact
The permissions and roles for each developer should be included in the request.
The Primary Technical Contact is responsible for notifying the database team when there is a transfer or termination of one of the developers that has been assigned a developer account.
The Primary Technical Contact should validate the developer accounts on a semi-annual basis to confirm they are still valid and have the appropriate permissions.
There are three methods of contacting the ITS Database team to request services:
- Email Option 1: Submit a ticket to the ITS Database team by sending an email to firstname.lastname@example.org.
- Email Option 2: Submit a ticket to the ITS Service Desk by sending an email to email@example.com.
- Phone: Call the ITS Service Desk at 512-475-9400.
All parties will identify the staff contacts officially recognized in support of this SLA. The contact information should include support role, name, email address, and phone number.
Current emergency contact information for ITS Systems staff can be found at Staff Contact Information (restricted to ITS Systems and ITS Applications staff).
|ITS Database - Account Manager / Oracle Technical Contact||Chris Owanfirstname.lastname@example.org||
|ITS Database - Oracle and MySQL Technical Contact||James Alexanderemail@example.com||512-475-9379 (W)
|ITS Database - MSSQL Technical Contact||Josh Hsufirstname.lastname@example.org||512-232-6507 (W)
|ITS Database - MySQL Technical Contact||Kevin Changemail@example.com||512-232-9315 (W)
|Customer Technical Contact|
|Customer Billing Contact|
|Customer Executive Contact|
Hours of Coverage, Service Availability, Services Requests, and Escalation
Hours of Coverage
The normal hours of operations for the ITS Database team are 8:00 am to 5:00 pm, Monday through Friday, except University holidays and announced University closures. Customers should submit service requests by email to firstname.lastname@example.org to open a ticket.
Regular requests can be submitted 24 hours a day, 7 days a week. If requests are submitted after hours, they will be processed the next business day. Requests for off-hours work must be scheduled one week in advance.
Service availability defines the percentage of time this service is expected to be in production (database services available and accepting connections), with the exception of scheduled maintenance, and within service availability hours.
The ITS Database team has calculated service availability in the table below (percentage excludes 40 hours of scheduled yearly maintenance) for the following service availability hours:
- Production: 24 hours a day, 7 days a week
- Non-production: 8:00 am to 5:00 pm, Monday through Friday, except University holidays and announced University closures
|Database Platform||Service Availability|
A Service Request is any request made by a Customer to the ITS Database team for routine operational support. During normal business hours, Service Requests will be responded to within one business day after notification to the ITS Database team. Service Request changes will be made during normal business hours. Requests made after normal business hours may not be responded to until the following business day.
To make a Service Request, the Customer must create a ticket. The following methods may be used to create a Service Request ticket:
- Preferred/Primary Option:
Option 1: ServiceNow Database Form - submit a ticket directly to the ITS Database team by completing the ITS Database General Request Form (Qualtrics).
- Secondary Options:
Incident Reporting and Support Hours
An Incident is any interruption of the normal function of the database service where it is severely malfunctioning. During normal business hours, Incidents will be responded to within 30 minutes after notification to the ITS Database team. ITS Database team members will make every effort to respond to off-hours incidents after notification in a timely fashion.
To report an Incident, the Customer must create a ticket by emailing email@example.com. This email will generate a ticket that will be assigned to the ITS Database team.
During off-hours, if the Customer deems the incident requires immediate escalation, the Customer may, in addition to emailing firstname.lastname@example.org, contact the ITS Operators at 512-475-9400. When calling the ITS Operators, reference the Incident ticket number.
If an Incident is not responded to within the response times outlined above, the Customer may escalate by directly contacting their ITS Database Secondary Technical Contact, ITS Database Account Manager, or University Data Center. Please refer to the Service Request ticket number when contacting after-hours support.
Optional Critical Off-Hours Support
If a critical business need exists that requires “required to respond” off-hours support and response time, the Customer may request, for periods no longer than 14 days, ITS Database staff to be placed “on-call”.
When on-call, an employee must respond within 15 minutes to any call or text. For calls or texts from the UDC Operators, the on-call employee must contact and inform the Operators they are working on the incident to avoid escalation to other personnel who are not on-call. For automated notifications, the on-call employee must claim the ticket in the request system so other personnel will not. The on-call employee must be able to begin working on the incident or arrive on campus within 60 minutes of the call or page, 24x7, prepared to work on the problem (including holidays).
Further details of the ITS On-Call Policy are documented in Appendix A.
If the Customer wishes to place ITS Database staff on-call, they must request those dates no less than 3 weeks in advance to allow scheduling of ITS Database staff. The ITS Database team prefers that regularly scheduled activities (e.g. registration or beginning of the semester) which require critical off-hours support be scheduled in advance by the Customer.
The Customer will be charged an additional $224 per week that critical off-hours support is requested.
Maintenance and Service Changes
Because the central IT environment is regularly upgraded to allow for growth and change in the use of information technology, the Customer must expect routine maintenance to be scheduled periodically to comply with new standards and upgrades. The ITS Database team will notify the Customer when such work is needed. Growth or change initiated by the Customer may warrant a Service Review of their current environment.
All maintenance events shall follow the ITS Maintenance and Incident Communication Policy. Availability of database services is subject to any published ITS Networking and Data Center maintenance events.
The Change Management process within ITS Systems minimizes unintended service disruptions or other impacts to the Campus as a result of changes in the production environment. The ITS Database team does this by monitoring, managing, and evaluating changes to maximize the service benefits to the customer, while minimizing the risks involved in making those changes. Support Hours for service changes to Production Databases is 24 hours per day, 365 days per year. Support Hours for service changes to Dev/QA Databases is 8:00 am to 5:00 pm, Monday through Friday, except University holidays and announced University closures. Please note that some maintenance work may cause service disruptions.
There are four categories of maintenance events:
- Planned Outage: Approved maintenance that will cause a service disruption and is scheduled at least 5 business days prior to the event. The ITS Database team will post it to the IT Maintenance Calendar and contact the appropriate customer contacts. Every fiscal year, 40 hours of time are reserved for planned maintenance to database hardware, operating systems, network, storage systems, and database software. Whenever possible, planned maintenance on production services is scheduled during off-hours.
- Planned Non-Disruptive: Approved maintenance that will not cause a service disruption and is scheduled at least 5 business days prior to the event. The ITS Database team will post it to the IT Maintenance Calendar and contact the appropriate customer contacts. Every fiscal year, 40 hours of time are reserved for planned maintenance to database hardware, operating systems, network, storage systems and database software. Whenever possible, planned maintenance on production services is scheduled during off-hours.
- Expedited Non-Disruptive: Approved maintenance that will not cause a service disruption and is scheduled less than 5 business days prior to the event. The ITS Database team will post it to the IT Maintenance Calendar and contact the appropriate customer contacts.
- Emergency: Unplanned maintenance that will cause a service disruption and is scheduled less than 5 business days prior to the event. The ITS Database team will announce the maintenance to the ITS Problems list and contact the appropriate customer contacts.
For planned maintenance events, the ITS Database team will email the designated Technical and Data Owner contacts to coordinate scheduling patch application or database maintenance for:
Non-critical patches scheduled on a quarterly basis.
Production database maintenance that is scheduled during non-business hours.
Development and QA (Quality Assurance) database maintenance that is scheduled during business hours.
Database release upgrades. Application teams should anticipate upgrading major database release versions every 2-3 years and minor release versions every 1-2 years.
The ITS Database team will provide a three-month window for application testing.
The ITS Database team will not support versions of database software that are no longer supported by the vendor.
- The ITS Database team will provide major release upgrade notifications 12 months before vendor support ends.
Business Recovery and Continuity
The ITS Database team does not provide disaster recovery or business continuity planning for Customer services. ITS will not be responsible for damage to or loss of equipment or data due to natural disasters or problems that may result from a failure of University infrastructure or events outside the control of ITS or the University (ie. power fluctuation, power outage, network outage, etc.).
The Information Security Office has developed a comprehensive risk management program that focuses on proactive risk reduction in compliance with UT Austin rules and policies as well as all relevant state and federal laws. This program helps units identify and monitor risk to information resources on campus and develop strategies to manage that risk over time to include business recovery and continuation.
Each Customer is the owner of all data and is expected to use their professional judgment in managing risks to the information and systems they use and/or support. As the custodian and systems administrator of the system, the ITS Database team will make recommendations in response to a Customer's assessment of their site’s data classification and risk. ITS will implement Customer-approved solutions to protect the data. All security controls should be proportional to the confidentiality, integrity, and availability requirements of the data processed by the system. The ITS Database team will not be held liable for loss or compromise of data due to improper data security controls. Please see the CIO's Campus IT Policies for more information on minimum security standards.
ITS Database Service Levels
- Operational support with no reasonable risk of causing disruption to services will take place during normal business hours, 8:00 am to 5:00 pm, Monday through Friday, excluding University holidays and announced University closures.
- E-mailing email@example.com will automatically generate a ticket in the ITS Help and Service Desk ticketing system. Customers will receive an automated response with a case number for follow-up reference. Contacting the ITS Database team through other means may affect our ability to respond in a timely manner.
- Occasionally, it is necessary for ITS Database staff to escalate a problem to another entity. In these instances, the ITS Database team cannot guarantee the response time of the other entities. ITS Database staff will continue to act as the contact point for cases that require support from an outside entity.
- ITS Database staff will prioritize and process incoming Service or Incident requests. The response to priority requests may delay our response to other requests. Priority will based on the following criteria:
- Number of people affected
- Percentage of total tasks that can no longer be performed by individuals
- Academic and Administrative Calendar deadlines
- Impact on course delivery
- Risk to safety, law, rule, or policy compliance
- Should there be a dispute about service rendered, escalations can be requested by the Customer to the direct management of ITS Database team.
- SLA availability calculations are defined as the availability of the production environment on a 24x7x365 basis, excluding pre-approved maintenance windows.
- ITS Database staff will retain a minimum of 7 days worth of backups for the development and QA environments.
- ITS Database staff will retain 28 days worth of backups for the production environments.
- ITS Database staff will utilize failover and/or high availability architectures for the production databases whenever possible. Should anything happen to the primary production database, ITS Database staff may switch over to the secondary database. If Customer application connections are properly configured, the application will either automatically connect to the secondary database or require a manual restart to restore application services following the switchover.
- Customers are responsible for ensuring their application connection is correctly configured.
- Any planned maintenance, either disruptive or non-disruptive, for the development and QA database environments will be scheduled at least 5 business days in advance and completed during normal business hours, 8:00 am to 5:00 pm, Monday through Friday.
- Any planned maintenance, either disruptive or non-disruptive, for the production database environments will be scheduled at least two weeks in advance and done during non-business hours, weeknights or weekends. Typically, no disruptive maintenances will be scheduled during weekday evenings and outages will be scheduled during the weekend.
Length of the Agreement
The initial SLA period is for a minimum of one year and will continue until ITS terminates the agreement. The SLA will be reviewed and modified, where appropriate, on an annual basis. The SLA limits service to those specifically described in this document or as amended to this SLA. The customer may cancel service by creating a Service Request with 30 days’ notice. The customer must pay the full balance of the account within 14 days of receiving the final invoice, which may include charges incurred or billed after the date of the cancellation notice. The agreement begins when it has been signed by both parties and will automatically renew each year. New services provisioned, resource changes, and cancellations are prorated on a monthly basis for the remainder of the fiscal year.
Appendix A: ITS On-Call Policy
The original policy can be found at Information Technology Services on-Call Policy.
The purpose of this policy is to:
- Ensure ITS provisions an appropriate amount of after-hours support for systems and services that balance business needs, costs, and work-life balance.
- Establish guidelines and processes to ensure employees are fairly compensated for their time on-call.
It is the policy of ITS that any benefits-eligible employee may be required to serve on-call in order to fulfill the department’s mission and goals. Managers and supervisors are expected to establish appropriate levels of after-hours support that may include on-call duty. Employees who serve on-call will be remunerated in accordance with the guidelines of this policy.
General Policy Guidelines
- Scope: This policy applies to all benefits-eligible classified and A&P ITS employees.
- Definition of on-call duty: An employee is considered to be on-call if he/she
- is required to maintain a communications link between his/herself and campus, typically by carrying a communications device,
- is required to respond to communications within specific time frames, and
- is expected to maintain a “ready state” to respond to such calls within specific time frames.
- Length of on-call: On-call pay is administered in increments of a work week. Supervisors have the discretion to designate partial weeks as complete work weeks.
- Rate of pay: Employees will receive $224 per work week on-call. This amount will not be prorated for partial work weeks.
Managers and supervisors are responsible for judicious use of university funds and should consider carefully if and when on-call pay is warranted. The following criteria should be considered before requesting on-call pay:
Whether the on-call is required to support critical 24x7 services.
Whether the on-call is required as part of a contract or service level agreement (SLA).
Whether the expected frequency of calls to the employee on-call would justify on-call duty.
Whether the skill set of employees on-call are sufficient to address the nature of the calls, i.e. having the on-call person function as a team “dispatcher” may not be sufficient justification.
Alternatives to on-call must be considered and may include one or a combination of the following:
No support or service provided outside normal university business hours.
An escalation call list where team members are called in a sequence until an employee is reached who is both willing and able to respond. The responding team member will record their time worked and receive compensation for that time as permitted by applicable university policies.
Utilize the UDC for after-hours support, triage, and/or escalation.
Partner with other ITS departments to consolidate on-call duties and leverage economies of scale.
- Other creative solutions that balance business needs, costs, and work-life balance.
On-call duty must be approved in advance by the department's Director with final approval by the respective Associate Vice President or Vice President as applicable. Approvals will be forwarded to ITS-HR who will maintain a list of employees authorized to receive on-call pay. Thereafter, immediate supervisors will be responsible for scheduling and authorizing on-call duty.
Employees will designate on their electronic time sheet work weeks that they served on-call. Supervisors will review and approve time sheets. ITS-HR will review time sheets monthly to determine who will be paid on-call. Employees are to record all time worked while on-call as appropriate within existing policies. Employees may be required to acknowledge in writing their on-call responsibilities annually.
On-call pay will be paid out monthly. Time sheets must be final approved to ITS-HR one business day prior to the Documents Due date as published by Payroll Services in the Semi-Monthly payroll deadline schedule. The schedule can be viewed here:
Time sheets submitted late will be processed in the next month's payroll cycle. Payroll services will not process emergency checks for these types of payments.
On Semi-Monthly payroll processing days, ITS-HR will verify eligibility for on-call pay and process payment using an OV2 payroll voucher.
Approved by ITS - Senior Staff on March 10, 2009. Effective date March 1, 2009.
Appendix B: Oracle Exadata Patching Dates
Oracle Platinum Patching Events and Future Scheduled Patching Events
|Exa1/Exa2||Environment||Scheduled Date||Patching Notes||Status|
|Exa2||Dev/QA||March 4, 2016||JAN 16 PSU/OS/Bundle||Complete|
|Exa1||Production||March 19, 2016||JAN 16 PSU/OS/Bundle||Complete|
|Exa2||Dev/QA||May 2, 2016||APR 16 PSU/OS/Bundle||Complete|
|Exa1||Production||May 23, 2016||APR 16 PSU/OS/Bundle||Complete|
|Exa2||Dev/QA||October 2, 2016||JUL 16 PSU/OS/Bundle||Complete|
|Exa1||Production||October 23, 2016||JUL 16 PSU/OS/Bundle||Complete|
|Exa2||Dev/QA||December 19, 2016||OCT 16 PSU/OS/Bundle||Complete|
|Exa1||Production||January 7, 2017||OCT 16 PSU/OS/Bundle||Complete|
|Exa2||Dev/QA||March 21, 2017||JAN 17 PSU/OS/Bundle||Complete|
|Exa1||Production||April 9, 2017||JAN 17 PSU/OS/Bundle||Complete|
|Exa2||Dev/QA||June 5, 2017||APR 17 PSU/OS/Bundle||Complete|
|Exa1||Production||June 25, 2017||APR 17 PSU/OS/Bundle||Complete|
|Exa2||Dev/QA||September 28th, 2017||JUL 17 PSU/OS/Bundle||Complete|
|Exa1||Production||October 21st, 2017||JUL 17 PSU/OS/Bundle||Complete|
|Exa2||Dev/QA||December 12th, 2017||OCT 17 PSU/OS/Bundle||Compete|
|Exa1||Production||January 6th, 2018||OCT 17 PSU/OS/Bundle||Complete|
|Exa2||Dev/QA||March 20th, 2018||JAN 18 PSU/OS/Bundle||Complete|
|Exa1||Production||April 8th, 2018||JAN 18 PSU/OS/Bundle||Complete|
|Exa2||Dev/QA||June 4th, 2018||APR 18 PSU/OS/Bundle||Complete|
|Exa1||Production||June 24th, 2018||APR 18 PSU/OS/Bundle||Skipped|
|Exa2||Dev/QA||September 25th, 2018||JUL 18 PSU/OS/Bundle||Complete|
|Exa1||Production||October 20th, 2018||JUL 18 PSU/OS/Bundle||Complete|
|Exa2||Dev/QA||December 12th, 2018||OCT 18 PSU/OS/Bundle||Complete|
|Exa1||Production||January 12th, 2019||OCT 18 PSU/OS/Bundle||Scheduled|
|Exa2||Dev/QA||February 7th, 2019||JAN 19 PSU/OS/Bundle||Scheduled|
|Exa1||Production||March 3rd, 2019||JAN 19 PSU/OS/Bundle||Scheduled|
|Exa2||Dev/QA||May 7th, 2019||APR 19 PSU/OS/Bundle||Tentative|
|Exa1||Production||June 1st, 2019||APR 19 PSU/OS/Bundle||Scheduled|
|Exa2||Dev/QA||August 6th, 2019||JUL 19 PSU/OS/Bundle||Tentative|
|Exa1||Production||August 24th, 2019||JUL 19 PSU/OS/Bundle||Scheduled|
|Exa2||Dev/QA||October 29th, 2019||OCT 19 PSU/OS/Bundle||Tentative|
|Exa1||Production||November 16th, 2019||OCT 19 PSU/OS/Bundle||Scheduled|
Appendix C: Revisions
|2015-09-23||Minor Edits to backup SLA statements and Planned Maintenance Section.|
|2015-11-30||Added Database and Account Permissions section.|
|2016-01-14||Updated the SLA Uptime Metric Numbers|
|2016-03-28||Updated URL Links to ISO related Pages|
Moved Appendix B to Appendix C and added Oracle Exadata patching quarterly patching schedule under Appendix B.
Added additional future quarterly patching dates to the schedule for 2017.
Updated the Service Requests and Incident reporting sections to reflect the use of our Qualtrics request form and Service Now.
Added upcoming patching dates for the July 2017 and October 2017 Quarterly Patch Set Updates to Appendix B
Removed Thomas Orf from Contacts List.
Updated Oracle Exadata Patching Dates Appendix B with first two quarters of 2018 patching dates. Minor edits to remove the TODO from the customer responsibilities section.
Updated Oracle Exadata Future Patching Dates Appendix B with the next two quarters patching dates.
Updated Oracle Exadata Patching status and added new dates in Appendix B for future events
Updated Oracle Exadata Patching status and added new dates for 2019 in Appendix B.
Updated URLs. Added link to the ITS Database Owner Report Tool.