For DBAs, chances are the responsibilities look like the list shown below. System DBA is focused on the system itself and APPS DBA is responsible for the business applications. In fact, there are many different types of DBAs. In addition to System DBAs and Application DBAs, there are DBAs who say they are database architects or data modelers. Some are generalists while others are specialist DBAs such as a performance tuning expert or data warehouse administrator.
Regardless of the classification, DBAs are responsible for many repetitive time-consuming tasks. Although these tasks may only provide incremental value to the business, nonetheless, these tasks can’t be ignored. And that’s why the Autonomous Database is a gamechanger for DBAs.
|System DBA||Application DBA|
|Manage Database Storage||Responsible for apps including database|
|Takes care of Backup & Recovery||Takes care of User Experience & Developer needs|
|Apply patches & Manage database Upgrades||Manage application rollout & upgrades|
|Accountable to IT Leaders||Accountable to Business Leaders|
How DBA Duties Have Changed
Many of DBAs recognize the value of automating tasks, and painstakingly set up and managed their routine. Oracle also recognized this pain point, going back to the releases of Oracle Database 9i and 10g, Oracle introduced the self-managing database with its ingenious performance data warehouse (AWR) and the Automatic Database Diagnostics Monitor (ADDM).
Subsequently, Oracle Enterprise Manager introduced the diagnostics and tuning packs to deliver full automation for diagnostics and performance tuning. The solution was ground-breaking for its day. However, there were challenges like the restricted amount of data stored for diagnostics purposes and the labor-intensive effort to set up or update environments to be monitored. At least apps didn’t change frequently, so it was manageable.
Today brings new opportunities, and new challenges. The pace of change has accelerated with mobile and web applications released and updated weekly or even daily. The manual efforts for threshold setting and the volume of telemetry & metrics and logs data has skyrocketed. The good news is that the Autonomous Database from Oracle revolutionizes how databases are being managed; essentially automating up to 95% of the system DBA responsibilities.
How Oracle’s Autonomous Database Makes the DBA Job Easier
The Autonomous Database runs in the Oracle Cloud. The Oracle Cloud Infrastructure is based on the Oracle Exadata platform which can deliver unmatched performance and high availability to ensure 99.995 uptime access for your workloads.
- The Oracle Cloudalso delivers higher flexibility than commodity clouds with instant elasticity where compute and storage resources can be scaled independently while the application is running, with no downtime. There is no manual sizing of database workloads.
- With Oracle Cloud, there is no limit on how much diagnostics and audit data can be stored for your database workloads. You can collect and analyze as much diagnostics data as you want to solve a problem and get answers without any impact to your database performance.
The autonomous database uses AI and adaptive machine learning to automatically self-patch, self-tune, detect and resolve anomalies, and optimizes indexes much more quickly and efficiently than manual hands-on processing.
Focus Areas for Successful DBAs
This technology can have a major impact on DBAs’ productivity and career. For example, by adopting the Autonomous Database, system DBAs can now expand their responsibilities to cover more high value areas or specialize in areas with higher business value like below:
- Spend more time on data model enhancements
- Focus more on the database architecture
- Spend more time with developers and line of business
- Focus on any other task that can benefit from a proactive approach e.g. plan capacity, eliminate systemic issues
When applications run on the Autonomous Database, they automatically benefit from better performance, higher availability and resilience as well as better security. This enables DBAs to effectively direct resources when unknown issues arise which requires rapid troubleshooting. This typically involves the assembly of large war rooms where architects, administrators and developers from across the IT landscape show up with their data to troubleshoot the issue. In practice, people are there to disprove that the problem is in their respective areas. Oracle now provides Oracle Management Cloud to provide DBAs with complete visibility into their application environments to help avoid war room finger pointing and other challenges associated with multi-tier troubleshooting.
If you are interested in the Oracle Cloud Infrastructure or Oracle Management Cloud to your database feel free let us know.
Use the following checklist to help you evaluate and plan for the migration of your databases to Oracle Cloud Infrastructure, based on the unique requirements of your source and target databases.
Work with your database admins, network admins, and system admins as necessary to determine the required information for your migration.
- Downtime: Determine from your business what the downtime service level agreements (SLAs) are and how much downtime, if any, the business can accommodate. You can also review Recovery Time Objective (RTO) and Recovery Point Objective (RPO) SLAs to see how much downtime is acceptable according to your disaster recovery (DR) and business continuity (BC) guidelines.
- Database Size: Determine the data volume. Typically, the size of the database is based on two factors: whether the physical or logical migration method is considered, and whether all or part of the data will be migrated to the target database.
- Network Bandwidth: Determine the available network bandwidth between the source and target databases. In addition to available bandwidth, network reliability is also important. Based on the data transfer method, network interruption might require you to restart the data transfer job.
- Cross-Platform Migration: Determine the endianness of the source and target platforms. Oracle Cloud Infrastructure databases are little-endian. If your source database is big-endian, you can either select the logical migration method, which is typically slower, or use Oracle Data Guard or RMAN cross-platform features for the cross-platform migrations.
- Database Character Set: Determine the database character set for the source and target databases. For most migration methods, the target database character set must be a superset of the source database character set. Some methods might need the exact same character set to avoid data loss.
- Data Encryption: Determine whether the source database uses Transparent Data Encryption (TDE). TDE is mandatory for all Oracle Cloud Infrastructure databases. If TDE not used at the source, enable it either at the source or at the target. Be sure to back up and restore the required TDE wallets from the source to the target.
- Database Version, Edition, and Options: Determine the database version, edition, and options for the source and target databases. Based on the migration method, the target and source database version and edition must be compatible. For the Oracle Cloud Infrastructure 12c database target, the multitenant architecture is mandatory, so ensure that the selected migration method can accomplish the migration into the CDB/PDB, as needed.
- Databases Patches: Determine the patch level for the source and target databases. Ensure that the source and target are at the same or compatible Patch Set and Release Upgrade level. Apply any required patches at the source to minimize any discrepancies during or after the migration. Also, as necessary, apply any one-off patches at the target.
- DB Name: Determine the database name used at the source database. For full database restore methods, it is mandatory to create the target database by using the same database name as used at the source database. However, use the DB Unique Name of the target as created by the Oracle Cloud Infrastructure tooling.
- DB Block Size: Determine the database block size used at the source database. For partial restore methods like transportable tablespaces, it might be necessary to adjust the cache size parameters based on the target database.
- DB Time Zone: Determine the database time zone used at the source database. It might be necessary to adjust the database time zone at the target database.
- DB Users, Privileges, and Objects: Determine the database users, privileges, and objects, like DB Links, from the source database that might also need to be created at the target database.
- Sizing:Determine the source database sizing and consider future growth to size the target database. In addition to CPU and Memory, ensure the sizing meets your IOPS and Network Bandwidth requirements.
- Target Database:To ensure the target database will have all the required metadata for OCI tooling to work, create the target database using one of the supported methods like OCI Console, OCI CLI or Terraform OCI provider. This target database will be cleaned to be used as a shell for the migration, as needed.