What is Oracle Goldengate?

After Oracle corp. acquiring Goldengate software there is a lot of buzz about Oracle Goldengate and it is one of the hot topics at Oracle open world 2010.

Oracle Goldengate can be used as a replication tool, ETL, and even as a DR solution.

Oracle Goldengate (GG) is probably the best replication software and it is very easy to configure and deploy it in large scale environment. Here are some of the things you need to be aware of:

1) All GG configuration files are ascii text based files. Very easy to make changes but it is prone to human errors in an environment having many DBA's working on it.

2) In order to use parallel apply threads, GG breaks down the database transaction into multiple transactions based on the hashing key defined for range split of the data. So, transactional consistency will not be guaranteed during real time but there won't be any data loss, but make sure that your application can tolerate this.

3) If there is no primary key or unique index exists on any table, GG will use all the columns as supplemental logging key pair for both extracts and replicats. But if you define key columns in the GG extract parameter file and if you don't have the supplemental logging enabled on that key columns combination, then GG will assume missing key columns record data as "NULL", which is a huge deal, and this will introduce logical data corruption on the target.

4) GG started supporting bulk data loads with their 11.1 release but any NOLOGGING data changes will be silently ignored without any warning.

5) GG doesn't support compression on the source database.

6) GG does support DDL replication but it is not easy to do selective DDL replication, it replicates every DDL that happens on the source database which is not desirable for some customers.

7) Tables being replicated to on the target can also be written to by any other application or DBA's.

8) GG supports ignoring data conflicts for updates after the first instantiation of the target database until it catches up. But it is very easy to forget turning off that parameter and any updates being lost will not be alerted by GG.

9) GG still works by reverse engineering the Oracle redolog. This may not be totally true with GG 11, but I expect GG to interpret Oracle redo more directly in later versions of 11 or 12.

10) GG dynamically decides to change the key columns that form the supplemental logging based on the state of primary key (i.e. in VALIDATED or NONVALIDATED state), which can introduce data corruptions on the target databases as the expected key columns data is missing in the trail files and they will be set to NULL. They now have the patch available for this, you can set "_USEALLKEYCOLUMNS and ALLOWNONVALIDATEDKEYS" parameters in GLOBALS file to get around this problem.


Use cases:

I think Oracle is not promoting logical standby as much as they should have. Oracle logical standby guarantees data consistency, data integrity, maintains order of transactions, and doesn't let target database tables to be modified by others which by itself offer great confidence in data quality.

Oracle Xstreams offers greatest flexibility and superior performance in extracting data from the source database and applying the same to the target database.

For Oracle database upgrades or having a logical DR standby it is better to use Oracle logical standby, use Xstreams if you want more flexibility and high performance in moving data across databases, and use GG for keeping the downstream database up to date for reporting, ETL purposes, or to move data across hybrid databases.

Brief discription about RAC

RAC stands for Real Application Clusters. It allows multiple nodes in a clustered system to mount and open a single database that resides on shared disk storage. Should a single system fail (node), the database service will still be available on the remaining nodes.

In RAC database, comprises of multiple instances, however there will be only one database.

A non-RAC database is only available on a single system. If that system fails, the database service will be down (single point of failure).

Oracle Database 10g Real Application Clusters (RAC) enables the clustering of the Oracle Database. A RAC database comprises of multiple instances residing on different computers to access a common database residing on shared storage.

Why Real Application Cluster ?

The basic principle behind the Real Application Cluster is greater throughput and scalability due to the combined power of multiple instances running on multiple servers

Real Application Cluster provides high availability and scalability for all application types. The RAC infrastructure is also a key component for implementing the Oracle enterprise grid computing architecture. Multiple instances access a single physical database prevents the server from being a single point of failure. Combining smaller servers into a cluster can be achieved to create scalable environment that support mission critical business applications.

Real application Cluster uses Oracle Cluster ware for the infrastructure to bind multiple servers so that they operate as a single system.

Oracle Clusterware is a portable cluster management solution that is integrated with the Oracle database. The Oracle Clusterware is also a required component for using Real application Cluster.

In Oracle Database 10g, Oracle Provides you with an integrated software solution that addresses cluster management, event management, application management, connection management, storage management, load balancing and availability. These capabilities are addressed while hiding the complexity through simple-to-use management tools and automation.

Oracle Real Application Clusters 10g provides an integrated cluster ware layer that delivers a complete environment for applications.

Oracle Real Application Cluster (RAC) uses Oracle Clusterware for the infrastructure to bind multiple servers so that they operate as a single system

Main Components of Oracle Real Application Cluster 10g

It comprises of two main components

1. Oracle Clusterware
2. Oracle Software

In RAC 10g Clusterware is called CRS layer which resides below Oracle software Layer. Second layer is the Oracle software itself.

Oracle Real Application Cluster (RAC) is the Oracle Database option that provides a single system image for multiple servers to access one Oracle database. In RAC, each Oracle instance usually runs on a separate server.

Oracle Clusterware is software, enables the servers to be bound together to operate as if they were one server. The Oracle Clusterware comprises of two clusterware components: a voting disk to record node membership information and the Oracle Cluster Registry (OCR) to record cluster configuration information. In Oracle Clusterware each node is connected to a private network by way of a private interconnect.

The Oracle Clusterware comprises several background processes that facilitate cluster operations such as Cluster Synchronization Service (CSS) and Event Management (EVM).

What are the Real Application Cluster Main Processes ?

The main processes involved in Oracle RAC are primarily used to maintain database coherency among each instance. They manage what is called the global resources.

• LMON: Global Enqueue Service Monitor
• LMD0: Global Enqueue Service Daemon
• LMSx: Global Cache Service Processes. Where x can range from 0 to j
• LCK0: Lock Process
• DIAG : Diagnostibility Process

There are several tools that are used to manage the various resources available on the cluster at a global level. Some of the tools used are Server Control (SRVCTL), DBCA and Enterprise Manager.

Oracle Clusterware is a portable cluster management solution that is integrated with the Oracle database. The Oracle Clusterware enables you to create a clustered pool of storage to be used by any combination of single-instance and RAC databases.

Oracle Clusterware is the only clusterware that you need for most platforms on which RAC operates. You can also use clusterware from other vendors if the clusterware is certified for RAC.

The combined processing power of the multiple servers can provide greater throughput and scalability than is available from a single server. RAC is the Oracle Database option that provides a single system image for multiple servers to access one Oracle database. In RAC, each Oracle instance runs on a separate server.

RAC is a unique technology that provides high availability and scalability for all application types. The RAC infrastructure is also a key component for implementing the Oracle enterprise grid computing architecture. Having multiple instances access a single database prevents the server from being a single point of failure. RAC enables you to combine smaller commodity servers into a cluster to create scalable environments that support mission critical business applications

What are the Storage Principles for RAC Software and CRS ?

The Oracle Software 10g Real Application Clusters installation is a two-phase installation in the first Phase, You install CRS. In the second phase, you install the Oracle Database software with RAC components and create a cluster database.

The oracle home that you use for the CRS software must be different from the one that is used for the RAC Software. CRS and RAC software is installed on cluster shared storage.

Note:- Cluster Software and Oracle software is usually installed on a regular file system that is local to each node. This permits online patch upgrades without shutting down the database and also eliminates the software as a single point of failure.

Do you need special hardware to run RAC ?

RAC requires the following hardware components:

• A dedicated network interconnect - might be as simple as a fast network connection between nodes; and a shared disk subsystem.

RAC and Shared Storage Technologies

1. Supported shared storage for Oracle grids:



• Network attached Storage
• Storage Area Network


2. Supported file systems for Oracle grids:-



• Raw Volumes
• Cluster file system
• ASM
Want to know more about Real Application Cluster Click Oracle Real Application Cluster

Components of Real application Cluster

Oracle Real Application Cluster 10g provides you with an integrated software solution that addresses cluster management, event management, application management, connection management, storage management, load balancing and availability. These capabilities are addressed while hiding the complexity through simple-to-use management tools and automation.

Cluster platforms depend on the cluster management program to track the cluster node status. Basically there are two types of cluster managers, first one is oracle supplied and second one is vendor supplied.

In Oracle 10g , oracle provided clusterware can be used independently or on top of the vendor provided cluster software.

Cluster Ready Service’ (CRS) is Oracle provided portable clusterware, which is portable and works on all the platforms to implement RAC database solution.

RAC Software Principles

Addition to the background processes found in single instance database, You see few additional background processes associated with RAC instance. These processes are primarily used to maintain database coherency among each instance. They manage what is called the global resources:-

• LMON:- Global Enqueue Service Monitor
• LMD 0:- Global Enqueue Service Daemon
• LMSx :- Global Cache Service Processes
• LCK 0 :- Lock Process
• DIAG :- Diagnosibility Process

The Oracle Clusterware Software Components

When Oracle Clusterware operates, several platform-specific processes or services will also be running on each node in the cluster to support Oracle Clusterware.

Oracle Clusterware Processes on UNIX-Based Systems

• crsd—Performs high availability recovery and management operations such as maintaining the OCR and managing application resources. This process runs as the root user, or by a user in the admin group on Mac OS X-based systems. This process restarts automatically upon failure



• evmd—Event manager daemon. This process also starts the racgevt process to manage FAN server callouts



• ocssd—This process runs as oracle user and manages cluster node membership. Any failure of this process results in cluster restart



• oprocd—Cluster Process monitor. This process only appears on platforms that do not use vendor clusterware with Oracle Clusterware

Explain about Oracle Clusterware

Oracle Clusterware is a portable cluster management solution that is integrated with Oracle Database. Oracle Real Application Clusters (Oracle RAC) uses Oracle clusterware as the infrastructure that binds together multiple nodes which operate as a single server. Oracle Clusterware includes a high availability framework for managing any application that runs on your cluster. Voting disk and the OCR is created on shared storage during Oracle Clusterware installation process.

The Oracle Clusterware includes two important components: the voting disk and the Oracle Cluster Registry (OCR). The voting disk is a file that manages information about node membership and the OCR is a file that manages cluster and Oracle Real Application Clusters (Oracle RAC) database configuration information.

1. Voting Disk: - Manages cluster membership by way of a health check and arbitrates cluster ownership among the instances in case of network failures. RAC uses the voting disk to determine which instances are members of a cluster. The voting disk must reside on shared disk. For high availability, Oracle recommends that you have multiple voting disks. The Oracle Cluster ware enables multiple voting disks.

Note:- If you define a single voting disk, then you should use external mirroring to provide redundancy.

2. OCR File :- Cluster configuration information is maintained in Oracle Cluster Registry file. OCR relies on a distributed shared-cache architecture for optimizing queries against the cluster repository. Each node in the cluster maintains an in-memory copy of OCR, along with an OCR process that accesses its OCR cache.

When OCR client application needs to update the OCR, they communicate through their local OCR process to the OCR process that is performing input/output (I/O) for writing to the repository on disk.

The OCR client applications are Oracle Universal Installer (OUI), SRVCTL, Enterprise Manger (EM), Database Configuration Assistant (DBCA), Database Upgrade Assistant(DBUA), NetCA and Virtual Internet Protocol Configuration assistant (VIPCA). OCR also maintains dependency and status information for application resources defined within CRS, specifically databases, instances, services and node applications.

Note:- The name of the configuration file is ocr.loc and the configuration file variable is ocrconfig.loc

Oracle Cluster Registry (OCR) :- Maintains cluster configuration information as well as configuration information about any cluster database within the cluster. The OCR also manages information about processes that Oracle Clusterware controls. The OCR stores configuration information in a series of key-value pairs within a directory tree structure. The OCR must reside on shared disk that is accessible by all of the nodes in your cluster. The Oracle Clusterware can multiplex the OCR and Oracle recommends that you use this feature to ensure cluster high availability.

Note:- You can replace a failed OCR online, and you can update the OCR through supported APIs such as Enterprise Manager, the Server Control Utility (SRVCTL), or the Database Configuration Assistant (DBCA

Want to know more about Real Application Cluster Click Oracle Real Application Cluster

Explain about Cluster File system

A cluster file system (CFS) is a file system that may be accessed (read and write) by all members in a cluster at the same time. This implies that all members of a cluster have the same view.If your platform supports an Oracle certified cluster file system, you can store the files that Real Application Clusters requires directly on the cluster file system.

A clustered file system is a file system which is simultaneously mounted on multiple servers. There are several approaches to clustering, most of which do not employ a clustered file system. While many computer clusters don't use clustered file systems, unless servers are underpinned by a clustered file system the complexity of the underlying storage environment increases as servers are added.

Distributed file system - the generic term for a client/server or "network" file system where the data isn't locally attached to a host.

Global file system - this refers to the namespace, so that all files have the same name and path name when viewed from all hosts. This obviously makes it easy to share data across machines and users in different parts of the organization.

OCFS2 (Oracle Cluster File System 2) is a free, open source, general-purpose, extent-based clustered file system which Oracle developed and contributed to the Linux community, and accepted into Linux kernel 2.6.16.

OCFS2 provides an open source, enterprise-class alternative to proprietary cluster file systems, and provides both high performance and high availability. OCFS2 provides local file system semantics and it can be used with any application. Cluster-aware applications can leverage parallel I/O for higher performance, and other applications can make use of the file system to provide a fail-over setup to increase availability.

Cluster file system - a distributed file system that is not a single server with a set of clients, but instead a cluster of servers that all work together to provide high performance service to their clients. To the clients the cluster is transparent - it is just "the file system", but the file system software deals with distributing requests to elements of the storage cluster.

Shared-disk cluster file system

The most common type of clustered file system is the shared disk file system, in which two or more servers are connected to a single shared storage subsystem, such as a stand-alone RAID array or SAN.

Symmetric file system - A symmetric file system is one in which the clients also run the metadata manager code; that is, all nodes understand the disk structures.

Asymmetric file system - An asymmetric file system is one in which there are one or more dedicated metadata managers that maintain the file system and its associated disk structures.

Shared-nothing clustered file system

Another clustered file system approach is to have each node use its own local storage, and communicate data changes to other nodes via some network or bus. In this case disks are not shared amongst nodes, but are instead dedicated to a single node and made readable and writable to other servers

Parallel file system - file systems with support for parallel applications, all nodes may be accessing the same files at the same time, concurrently reading and writing. Data for a single file is striped across multiple storage nodes to provide scalable performance to individual files.

SAN file system - These provide a way for hosts to share Fibre Channel storage, which is traditionally carved into private chunks bound to different hosts. To provide sharing, a block-level metadata manager controls access to different SAN devices. A SAN File system mounts storage natively in only one node, but connects all nodes to that storage and distributes block addresses to other nodes. Scalability is often an issue because blocks are a low-level way to share data placing a big burden on the metadata managers and requiring large network transactions in order to access data.

What is a raw device ?

A raw device is a disk drive that does not yet have a file system set up. Raw devices are used for Real Application Clusters since they enable the sharing of disks.

The term raw devices applies to the character oriented disk device files (as opposed to the block oriented ones) normally found in /dev. These device files are a part of the interface between the hardware disks and the UNIX system software.

Raw devices are character devices. A utility called raw can be used to bind a raw device to an existing block device. These "existing block devices" may be disks or cdroms/dvds.

Raw Partition:

A raw partition is a portion of a physical disk that is accessed at the lowest possible level. A raw partition is created when an extended partition is created and logical partitions are assigned to it without any formatting. Once formatting is complete, it is called cooked partition

SCSI, SAN and NAS, iSCSI

Although not directly related to CFS and raw devices questions arise around the storage technologies being used.

SCSI:

Disk drives are connected individually to the host machine by small computer system interfaces (SCSI) through one of a number of disk controllers.

SAN:

Storage Area Network is a shared dedicated high-speed network connecting storage elements and the backend of the servers.

NAS:

Network Attached Storage is a special purpose server with its own embedded software that offers cross platform file sharing across the network.

iSCSI:

Another form of network attached storage that communicates in block mode over Ethernet (Gigabit Ethernet) to special storage subsystems. Like NFS attached storage, iSCSI uses standard hardware and software to communicate - although a private network is recommended. Because it operates in block mode, use of iSCSI with RAC requires either a cluster file system or use of raw volumes.

Raw devices suitable for complex applications like Database Management Systems that typically do their own caching because, raw device offers a more "direct" route to the physical device and allows an application more control over the timing of IO to that physical device. A raw device can be bound to an existing block device (for example a disk) and be used to perform "raw" IO with that existing block device. Such "raw" IO bypasses the caching that is normally associated with block devices

In most UNIX systems it is a performance advantage to use raw device files for data storage. By using raw devices, the UNIX file system is bypassed and the operating system is able to perform more effective I/O.

Since file size is fixed by the size of the partition, because of this, file size is constrained by the size of the partition. If the partition becomes full, the raw device file must be moved to a larger partition. In the worst case, the disk must be reformatted in order to create a larger partition.

Why we use Oracle ASM for Oracle databases

What is the best way to store Oracle database data. Needless to say that the foundation should be EMC infrastructure of course, but apart from that, what kind of volume manager and/or filesystem works best for performance and other features?

There are many volume managers, and many filesystems available, more or less dependent on what hardware and operating system we run the database.

Some have a long track record, some are new kids on the block. Some are part of the operating system, others are 3rd party add-ons, for which you might need to pay licenses.

One way of storing Oracle database data is Oracle ASM.

Oracle ASM is Oracle’s volume manager specially designed for Oracle database data. It is available since Oracle database version 10g and many improvements have been made in versions 11g release 1 and 2. Oracle uses ASM in their own production environments and it is a core component in many of Oracle’s own offerings (such as Oracle Exadata) when maximum performance is needed.
It offers support for Oracle RAC clusters without the requirement to install 3rd party software, such as cluster aware volume managers or filesystems.
Although ASM is not absolutely required for an Oracle RAC cluster to be supported on EMC systems, we highly recommend using ASM because it lowers risk, cost, administration overhead and increases performance.

Oracle and other parties have developed alternatives for storage management of Oracle datafiles, such as Oracle OCFS (and OCFS2), SUN/Oracle ZFS, IBM GPFS and others. However, not all of these support Oracle clustering, and most of these filesystems (and volume managers) are complex to set up and require intensive tuning to drive good performance. Support (from Oracle, or OS vendors) can also be an issue.

Compared to standard volume managers and filesystems (either clustered or single system),  ASM has a number of advantages:

• It does not require large amounts of memory for cache. The memory not required for file system caching can be configured for Oracle memory (SGA) where it is more efficient (note that ASM requires typically a few hundred megabytes for internal administration, shared across all databases)
• ASM distributes chunks of data pseudo-randomly across all available logical disks in a disk group, thereby removing potential performance “hot-spots”
• ASM does not perform any I/O itself so there is no “translation layer” for Oracle I/O to datafiles into disk block offsets. I/O from databases is directly applied to disk volumes without modification. This again reduces overhead and improves performance.
• Therefore ASM also does no read-ahead (like filesystems) to read data in (filesystem) cache that is never used by the database.
• ASM does not require intensive tuning such as setting fragment sizes correctly and tuning file system journals. When creating an ASM disk group you only need to define the “chunk size” and whether or not to perform fine striping. It is unlikely to make configuration errors (causing performance issues) if a few simple ASM configuration guidelines are followed.
• ASM does not cause fragmentation (you could argue that ASM balancing is some sort of fragmentation. However, the allocation units are large enough – typically 1MB or more – to allow for very little disk “seeks” to read a number of subsequent (typically 8K) blocks
• ASM does not break large I/O’s (i.e. 128K) in multiple smaller ones (4K or 8K) like some filesystems do. One large I/O is faster than many small ones.
• No “journal” (AKA “intent log” etc) is required for consistency (this function is already done by Oracle redo logs and having a journalled filesystem is therefore only overhead).
• ASM can be managed from within Oracle tooling and does not require Unix administration (this can be an advantage or disadvantage depending on responsibilities of various administrators in the organization).
• Adding or removing storage to/from ASM is very easy and does not require careful planning (as is the case with volume managers and filesystems). After adding storage, ASM will automatically “rebalance” storage so all disks will be utilized equally. This again increases performance.
• ASM works on all major operating systems so it is platform independent.
• SAP now supports Oracle ASM.
• Finally, EMC fully supports ASM including various tooling that integrate with Oracle (such as Replication Manager, and backup and reporting tools).

Disadvantages? A few, maybe. Biggest disadvantages that I have identified:

• Migration from legacy filesystems to ASM can be a problem and often requires an outage
• It is hard (if not impossible) to view ASM contents with standard OS tools. In some cases, ASM data can be accidentally overwritten by OS admins who are using disk volumes that (to them) seem to be empty. However, there are administrative ways to prevent this from happening
• Backup cannot be done with traditional methods that just backup OS files so you need integrated tooling or use Oracle’s native tools (RMAN)

Last but not least, I have encountered a few situations where storage I/O load balancers (multipath drivers) also mess up the I/O’s coming from the higher level. In particular, I have seen Red Hat 5.6 native multipathing breaking 64K or 128K I/O’s into multiple 4K I/O’s. Still don’t know if this is a bug, undocumented feature, or works as designed. But it does not help Oracle performance. We switched to our own EMC Powerpath driver to replace it and immediately boosted performance without further tuning.

Make sure you understand the I/O stack end to end. The less complexity the easier it is (and the risk of making configuration errors). Using ASM (ideally, with EMC Powerpath) removes the risk of misconfigured volume managers, file systems and I/O path drivers.

Click/Open  below link for more information about ASM

https://drive.google.com/file/d/0B5kGedyNY3--bXBuSUsxdmpSOFE/view?usp=sharing