I recently blogged about the perils of security gaps on older databases and systems. If an organization does not stay current on software releases, problems may arise from exploited weaknesses. On the other hand, there are inevitable problems if you rush to deploy a brand new software. The Oracle 12c database was initially released in 2012. Now in its third major build (188.8.131.52), it’s a good time to begin looking at the product’s new features and fixed problems. Whatever your role, there are probably changes that you’ll find very attractive. The following are a few of the features that have particularly caught my eye as a DBA.
Data Archiving in Place
The management of archival data, and the elimination of obsolete data, rarely captures the attention of the system architects. Traditionally, old but required data could be moved to offline media such as hardcopy, magnetic tape, or floppy drives. However, after a hardware upgrade or two, those solutions become untenable. Data warehousing helped the larger sites reorganize online data, but the archiving overhead can impair user performance. With Oracle 12c, individual rows within tables can be changed to an archive state. Unless the user is authorized to see such archived data, those rows are transparent to the users’ queries and data manipulation. No CPU load, no I/O, no data spillage. This means that more production data can be stored for longer periods of time, without compromising application performance. Aggressive compression of such archived data can improve query and backup performance.
With the 12c architecture, Oracle has turned to a tiered package of services and practices that, at the high end, suggest continuous availability and zero-loss data protection. We’ve come a long way from requiring an overnight outage to run a tape back-up. Much of the package is not new. At a high level, Oracle’s Real Application Clusters (RAC) provides for two or more instances of a database to simultaneously exist in separate, discrete locations. Transactions against the primary node are archived. The archived transactions are periodically slaved to the remote host, then written to the second node. In the event of a primary failure, the users can be immediately and transparently rerouted to the secondary data server. Oracle geeks would recognize their old favorite tools such as RMAN backups, Active Data Guard, and GoldenGate.
It’s also pretty obvious that 12”c” means that cloud services are involved. Some database instances may remain on a local hard drive, but also interact with instances elsewhere in the World Wide Web.
Full Transportability between Systems with Oracle Data Pump
Tablespaces have been transportable since Oracle 10g. This means that a tablespace, as a logical container of physical data files, could be cloned between databases if the character set and platform type were compatible. Oracle 12c can quickly make entire database copies on network attached storage (NAS). This new feature moves the metadata and the user data seamlessly in one process. Previously, database cloning would have required multiple operations. In short, an entire database can be simply and quickly moved between different computer systems.
Table-Level Recovery from Backups
Recovery Manager (RMAN) can restore and recover a table or set of tables from existing backups on disk or tape with the new RECOVER TABLE option. The usual recovery process has been to manually restore and recover the required tablespaces into separate disk locations, export the desired tables, then import them back to the original database. But this new faster, cheaper, and easier is much preferred.
Proactive, Real-time Detection of Performance Problems
Oracle has had many automatic performance diagnostics advisors such as Automatic Database Monitor (ADDM). ADDM reports potentially serious problems found in the last hour (by default). When a critical problem occurs, DBAs need to be notified right away. Spot ADDM is a new advisor that automatically triages for a root cause when performance issues are detected. High CPU load or I/O bound scenarios are examples of the events that will trigger the alert. Results from these spot ADDM events may be reviewed as reports. This feature allows DBAs to respond rapidly, and may eliminate the cascade of catastrophic failures.
Data Redaction by Policy and Subsetting
There are various, labor-intensive techniques intended to replicate production data for non-production use, such as testing or development. This is not a popular procedure for DBAs. Data has to be transferred across the network with minimal impact to users. And unless you have an exceptional budget, non-production systems are rarely as robust as the production ones. Application designers and testers will demand a full set of raw, unencrypted data for their testing. PII or HIPAA privacy requirements may have to contend with relaxed security rules. With data redaction in Oracle 12c, one may mask data at the source as well as significantly reduce the data set required. Both steps may be combined into one workflow as desired. This particular feature needs to mature a good bit, but it’s off to a much appreciated start.
Are you feeling the pressure as Oracle continues to desupport older versions up through 184.108.40.206? Perhaps you want to upgrade to Oracle 12c but you want to remain compatible to your existing product and environment. Segue has the professional resources to help you evaluate your options and to select a course of action.