Oracle RAC New Features For Beginners

Oracle 12c R1 New Features For DBAs

Oracle 12c R1 New Features For DBAs :

1: Enterprise Manager and Other Tools

Enterprise Manager (EM) Cloud Control home page

Enterprise Manager Express home page versus Enterprise Manager Database Control

SQL Developer with new functionalities

OUI, DBCA

2: Basics of Multitenant Container Database (CDB)

Benefits of the multitenant architecture

Differences between the root container and pluggable database containers

Structure of the root

Structure of Pluggable Database (PDB)

CDB_xxx and DBA_xxx views

Impacts in Security, Data Guard, Oracle GoldenGate, Oracle Streams, XStream, and Scheduler

3: Configuring and Creating CDB and PDBs

Tools: DBCA and SQL*Plus

Configuration and creation of CDB

Exploring the Structure (CDB_xxx views and EM)

Tools used: SQL Developer, DBCA and SQL*Plus and EM Database Express

Create a new PDB from PDB$SEED

Create a PDB from a non-CDB

Clone a PDB into the same CDB or into another CDB using DB links

Plug in an unplugged PDB

4: Managing CDB and PDBs

Connect to CDB as administrator

Connect to a PDB using a service name

Start up a CDB

Open / Close a PDB (SQL*Plus, srvctl, EM)

Open / Close all PDBs

Shut down a CDB

Preserve or discard the PDBs open mode when the CDB restarts

Change PDB state

5: Managing Tablespaces, Common and Local Users, Privileges and Roles

Create permanent tablespaces in the root and PDBs

Manage common and local schemas and users in the root and PDBs

Manage system and object privileges to common and local grantees granted “commonly” or “locally”

Manage common and local roles granted “commonly” or “locally”

6: Managing Backup / Recovery / Flashback

Backup a whole CDB

Backup a PDB

Recover CDB from redo log files, control files, undo datafiles loss

Recover PDB from PDB datafiles loss

Flashback at CDB level

Explain the two methods of migration

7: Online Datafile Move and Automatic Data Optimization

Data classification in 12c : tablespace, group, object, row levels

Configure heat map

Automatic movement and compression

Compression levels and types

Policy declaration: simple declarative SQL extension

Customized automated action execution with user-defined function

Execution in scheduled maintenance windows and by MMON

Customized schedule with DBMS_ILM package

8: In-Database Archiving

Challenges of old data in tables and 11g solutions

In-database archiving new solutions

Use ROW ARCHIVAL clause to enable row lifecycle state for applications

Set ROW ARCHIVAL VISIBILITY for session level visibility control

Use predicate on ORA_ARCHIVE_STATE column

Temporal Validity versus Temporal History (Transaction Time of FDA)

New clause of CREATE / ALTER TABLE to set a Temporal Validity: PERIOD FOR

New SQL temporal data type

9: Auditing Enhancements

Review of 11g R2 audit trail implementation

Overview of the Unified Audit Trail

Enabling the Unified Audit Trail

Creating a separate tablespace for the unified audit trail

Granting the AUDIT_ADMIN role to a user for audit trail configuration and management

Configuring the Unified Audit Trail to set a tolerance level for loss of audit records

Creating audit policies

10: Privileges Enhancements

Implementing Separation of Duty for Database Administration Tasks

Using Database Privilege Analysis

Overview of Database Privilege Analysis

Granting the CAPTURE_ADMIN role to enable management of privilege captures

Creating and starting/stopping privilege captures

Viewing privilege profile data

Querying DBA_PRIV_CAPTURES

Explaining the purpose of the default ORA$DEPENDENCY profile

11: Oracle Data Redaction

Overview of Oracle Data Redaction

Types of Masking Policies

Administering the EXEMPT REDACTION POLICY system privilege to enable a user to view unmasked values

Managing Masking Policies

Best practices for defining policy expressions

Understanding Masking of Statements Containing Subqueries

Viewing Information About Masking Policies by Querying REDACTION_POLICIES and REDACTION_COLUMNS

12: General RMAN New Features and FDA Enhancements

Making Database Connections With RMAN

Using the SYSBACKUP Privilege

Using SQL, DESCRIBE Command, Duplication Operation with the NOOPEN option

Backing up and Restoring Very Large Files

Creating Multisection Backups

Transporting Data Across Platforms

Prerequisites and Limitations

Transporting Data: Processing steps

13: Monitoring DB Operations

Overview

Use cases

Current Tools

Define a DB operation

Monitoring: Bracketing an Operation

Monitoring the Progress of Operations

DB Operation Tuning

DB Operation Active Report

14: Real-Time ADDM and Compare Period Advisor

Emergency Monitoring

Real time ADDM

Use cases

Goals

Define Workload dimensions

Reported items

Root Causes

Requirements for a report

15: ADR and Network Enhancements

ADR file types

New File types

New File locations

New command for ADRCI

Improve performance by Compression

Setup Compression

16: In-Memory Column Store

In-Memory Database option goals and benefits

Row format and columnar format

New SGA component:

IMCU synchronization

Deployment and behaviors

Compression ratio

New dictionary tables and added columns

New statistics: IM %

17: In-Memory Caching

Setting up Full Database In-Memory Caching

Using Full Database In-Memory Caching

Explaining the two buffer replacement algorithms of Automatic Big Table Caching

Configuring Automatic Big Table Caching with PARALLEL_DEGREE_POLICY and DB_BIG_TABLE_CACHE_PERCENT_TARGET Using Automatic Big Table Caching

18: SQL Tuning

Adaptive Execution Plans

SQL Plan Directives

Statistics Gathering Performance Improvements

Histogram Enhancements

Enhancements to Extended Statistics

Adaptive SQL Plan Management

19: Resource Manager and Other Performance Enhancements

Manage resources between PDBs

Manage resources within a PDB

Manage resources with CDB and PDBs plans

Manage runaway queries

Control the in-memory database repopulation resource consumption

Automated maintenance tasks

Current Architecture: Unix multiprocess / one thread, NT/Windows one process / multithread

New Architecture: Multiprocess / MultiThread

20: Index and Table Enhancements

Multiple indexes on the same set of columns as long as some characteristic is different

Create table with INVISIBLE columns

Support for invisible columns

Describe online redefinition supports

Explain LOCK timeout during FINISH_REDEF_TABLE

Describe the Advanced Row Compression

Using the following DDL statements in an online manner

21: Oracle Database Cloud Service: Overview

Database as a Service Architecture & Features and Tooling

Software Editions: Included Database Options and Management Packs

Automated Database Provisioning

Managing the Compute Node Associated With a Database Deployment

Backing Up and Recovering Databases on Database as a Service

Performing Recovery by Using the Service Console

Patching Database as a Service

Using the Oracle Database Cloud Service Console to Manage Patches

 

Source:https://airydba.wordpress.com/

IBM Datapower Training-Concepts and Benefits

DataPower Immutable Image Concepts and Creation

With the advent of container orchestration, immutable infrastructure is more attainable than ever before. An immutable image is an image where by all file system objects are read-only or immutable, preventing changes to app binaries or configuration data at runtime.

Why is this important, three main reasons

1) Security. Security is an end to end approach with many levels of defenses, defense in depth. Immutable images provide a defense against attackers modifying the persisted state of a running application or allowing them to make their malicious changes permanent.

2) Configuration drift. Leaving a system open to configuration changes overtime will result in configuration inconsistencies across the cluster or differences from the original well tested configuration state. Live production debugging sessions are one of the main sources of drift.

3) Forces a engineering team to develop a well thought out plan for rolling out updates vs ad-hoc changes to a production environment. Rollout scheme at a minimum should support canary deployments, whereby a configuration change is tested against a small subset of the total user population.

These three benefits describe the foundation of a modern deployment system. They are the precursers to a pipeline. They are prerequisites to continuous integration and continuous delivery.

Immutable images are like guardrails on deployment process – they prevent you from falling off the edge by making it more difficult to make changes outside the official process. If someone tries to make a change outside the process – ether by mistake or with malice – they are less likely to succeed if the image is immutable.

Using an immutable image allows you more certainty to know that what you have deployed what you have intended to deploy. This is a valuble and useful property of any deployment wheather or not you are using CI/CD. If you are thinking about CI/CD with DataPower, using immutable images can help adoption. If you are already using CI/CD with DataPower, using immutable images provides a greater level of assurance that changes can only be made inside your pipeline.

Prerequisites

Before you attempt this tutorial, please be sure that you:

  • Have Docker installed and running
  • Have run DataPower as described on the DataPower Docker Hub page
  • Good understanding of Unix filesystem permissions

 

Lets first take a look at an example DataPower configuration

This project is a simple loopback (no backend required) HTTP service that responds back with details of the request in JSON format. The details of what the configuration does is not important here but that it is easy to test and verify before and after we make the image configuration immutable.

git clone https://github.com/ibm-datapower/datapower-tutorials/immutable-image

cd immutable-image

docker build . -t datapower

docker run --name datapower --rm -p 8080:8080 -d datapower

IBM DataPower Training is now running in the background. Use docker ps to view the state of the running container:

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                    NAMES
31e13aad5539        datapower           "/bin/drouter"      7 seconds ago       Up 16 seconds       0.0.0.0:8080->8080/tcp   datapower

Next test the configuration by issuing the following curl command:

curl http://localhost:8080/stillmutable

If everything went successfully so far you should see the following response:

{"method":"GET","uri":"/stillmutable"}

Understanding the current Dockerfile contents

Lets start by explaining some of key aspects of the example Dockerfile:

 1: FROM ibmcom/datapower:latest
 2: ENV  DATAPOWER_ACCEPT_LICENSE=true \
 3:      DATAPOWER_INTERACTIVE=true \
 4:      DATAPOWER_FAST_STARTUP=true
 5:
 6: COPY src/config /drouter/config
 7: COPY src/local /drouter/local
 8:
 9: USER root
10: RUN  set-user drouter
11: USER drouter
12:
13: EXPOSE 8080

Lines 1-3 can are explained here

Line 4 enables the fast startup option. This dramatically speeds up initial process load times and reduces the amount of memory needed to start the container. The catch is slower initial access to the WebUI, SOAP management and REST management services.

Lines 6 & 7 copy our source into the image. /drouter/config contains the configuration files and /drouter/local contains other non-configuration files such as scripts and other ancillary files that are referenced by config. In our case it contains the echo.js GatewayScript implementation.

By default, docker COPY will recursively copy files and directories with ownership under root. In this case root ownership is desired because all non-root users are automatically part of the root user group. With this knowledge we now know we will need to focus on group and other permissions to make our images immutable. COPY also typically preserves the file permissions found on the host or build system, therefore its always a best practice to explicitly set file and directory permissions after a COPY or ADD instructions.

Line 9 is required because all DataPower images run as non-root and the RUN instruction inherits its user from the parent Dockerfile. So we are effectively switching back to the root user temporarily to make changes to the image.

Line 10 runs a utility script to fixup permissions when switching from root to non-root.

Line 11 using the USER instruction to set the user name back to its default non-root value of drouter. The USER instruction sets the user name (or UID) to use when running the image and for any RUN, CMD and ENTRYPOINT instructions that follow.

Line 13 informs Docker that the container listens on TCP port 8080 at runtime. This is the port we configured the HTTP Frontside Protocol Handler to use.

Time to make the configuration immutable

Open the Dockerfile using a text editor and add the following lines after RUN set-user drouter. The first line recursively finds all directories in local and config (including local and config) and sets the permissions to drwxr-xr-x. The second line is similar but for normal files and sets the permissions to -rw-r--r--. Since process 0 runs as non-root (drouter), it cannot create new files or directories in these locations or move files in or out, or modify any existing files.

RUN find /drouter/local /drouter/config -type d | xargs chmod 755
RUN find /drouter/local /drouter/config -type f | xargs chmod 644

Combining the two lines into a single RUN command as per Dockerfile best practices, the completed Dockerfile should look like this:

FROM ibmcom/datapower:latest
ENV  DATAPOWER_ACCEPT_LICENSE=true \
     DATAPOWER_INTERACTIVE=true \
     DATAPOWER_FAST_STARTUP=true

COPY src/config /drouter/config
COPY src/local /drouter/local

USER root
RUN set-user drouter \
 && find /drouter/local /drouter/config -type d | xargs chmod 755 \
 && find /drouter/local /drouter/config -type f | xargs chmod 644
USER drouter

EXPOSE 8080

Build and confirm the image is still working as intended:

docker kill datapower

docker build . -t datapower

docker run --name datapower --rm -p 8080:8080 -d datapower

curl http://localhost:8080/immutable

Conclusion

Adding the two lines to the Dockerfile recursively altered and reduced the permissions scope making it impossible for the gateway runtime to make any future modifications to the configuration, hence immutable. Using a read-only data volume containing the necessary config and local mount points would be another great way to achieve a similar result.

 

Source: https://developer.ibm.com/datapower/2018/01/16/datapower-immutable-image-concepts-creation/