Database Testing and Patch Querying

Srinivas Maddali

Database Testing

The following sections describe database testing features.

Mask-At Source or Mask During Subset

To mask confidential data for non-production use, enterprises needed to make a copy of the production database and then mask the data before sharing it with non-production users such as testers or developers. Masking at the source or masking while subsetting at the source database allows enterprises to provision a secure and reduced size test system directly from the production database without the need for a full production database copy. Enterprises may choose to execute the masking or subsetting operations or both to provision the test database in a single workflow.

Masking at the source or masking while subsetting at the source ensures that sensitive production data never leaves the source database when provisioning test systems and, therefore, complies with data privacy policies.

Self-Update for Oracle Applications Masking and Sub-setting Templates

Enterprises can mask sensitive data using data masking templates for Oracle applications such as Fusion applications and E-Business Suite. Given the complexity of enterprise applications such as Fusion applications or E-Business Suite, the process of manually importing the data masking templates can be complex.

Using self update for Oracle applications masking and subsetting templates, enterprises can directly download these templates from Oracle and import them into their Oracle Enterprise Manager Cloud Control 12c environment with no manual intervention.

Enterprises can easily and seamlessly implement the best practices for protecting sensitive data and provisioning reduced sized databases in their Oracle applications non-production environments using the self update option for Oracle applications masking and subsetting templates.

Database Replay Support for Database Consolidation

Database Replay now supports simultaneous execution of multiple database captures on a single consolidated database. The consolidated database can be a CDB with multiple PDBs or a traditional database consolidated using schema consolidation methods. Consolidated database replay supports scheduling of the individual replays enabling investigations of various scenarios (for example, what if all my individual workloads hit their peak utilizations at the same time).Consolidated replay supplies the ability to assure desired database performance for database consolidation projects, whether consolidating onto an Oracle database machine or other consolidated infrastructure.

Database Replay Workload Scale-Up and Characterization

Database Replay supports creation of a new workloads based on existing captured workloads. The new workloads can be used for capacity planning and validation of various what-if scenarios.Workload manipulation techniques such as workload filtering by various dimensions (such as time, services, and module) and scheduling are used to compose a new workload. Additionally, a custom workload scenario, or scaled-up version of the original workload, can be easily created by using a combination of workload manipulation techniques such as filtering, sub-setting by time, and scheduling them to run at the same time.

A database workload captured using Database Replay can be characterized by various attributes such as request types, activity, access or transaction patterns, and application-defined attributes. This allows division of the captured workload into smaller, more manageable and autonomous units that can also be used to better understand captured workload. Database workload scale-up and characterization capabilities allow businesses to perform capacity planning and system testing under various what-if scenarios.

Enhanced Database Replay Reporting

Database Replay reporting has been enhanced to provide insight into the causes of slow or fast replay. Utilizing the Active Session History (ASH) Analytics framework, Database Replay provides additional replay reports allowing you to quickly analyze and understand all of the performance characteristics of your database replay. In addition, you can use ASH Analytics to produce customized reports.

Enhanced Database Replay reporting reduces the time spent by users in analyzing replay performance.

General

The following section describes a new general feature.

Query-able Patch Inventory

Using DBMS_QOPATCH, Oracle Database 12c provides a PL/SQL or SQL interface to view the database patches that are installed. The interface provides all the patch information available as part of the OPatchlsinventory -xml command. The package accesses the Oracle Universal Installer (OUI) patch inventory in real time to provide patch and patch meta information.

 Using this feature, users can:

1.   Query what patches are installed from SQL*Plus.

2.   Write wrapper programs to create reports and do validation checks across multiple environments.

3.   Check patches installed on Oracle RAC nodes from a single location instead of having to log onto each one in turn.