Friday, September 20, 2013

Introduction to the Multitenant Architecture

This post contains information specific to the Oracle Multitenant option, and contains the following topics:

About the Multitenant Architecture

The multitenant architecture enables an Oracle database to function as a multitenant container database (CDB) that includes zero, one, or many customer-created pluggable databases (PDBs). A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to an Oracle Net client as a non-CDB. All Oracle databases before Oracle Database 12c were non-CDBs.

About Containers in a CDB

A container is either a PDB or the root container (also called the root). The root is a collection of schemas, schema objects, and nonschema objects to which all PDBs belong (see "Overview of Containers in a CDB").
Every CDB has the following containers:
  • Exactly one root
    The root stores Oracle-supplied metadata and common users. An example of metadata is the source code for Oracle-supplied PL/SQL packages (see"Data Dictionary Architecture in a CDB"). A common user is a database user known in every container (see "Common Users in a CDB"). The root container is named CDB$ROOT.
  • Exactly one seed PDB
    The seed PDB is a system-supplied template that the CDB can use to create new PDBs. The seed PDB is named PDB$SEED. You cannot add or modify objects in PDB$SEED.
  • Zero or more user-created PDBs
    A PDB is a user-created entity that contains the data and code required for a specific set of features. For example, a PDB can support a specific application, such as a human resources or sales application. No PDBs exist at creation of the CDB. You add PDBs based on your business requirements.
The following graphic shows a CDB with four containers: the root, seed, and two PDBs. Each PDB has its own dedicated application, and is managed by its own PDB administrator. A common user exists across a CDB with a single identity. In this example, common user SYS can manage the root and every PDB. At the physical level, this CDB has a database instance and database files, just as a non-CDB does.
Description of cncpt345.png follows
Description of the illustration cncpt345.png

See Also:
Oracle Database Administrator's Guide for an introduction to the multitenant architecture

About User Interfaces for the Multitenant Architecture

You can use the same tools for both CDBs and non-CDBs. For example, you can use:
See Also:
"Tools for Database Administrators"

Benefits of the Multitenant Architecture

Large enterprises may use hundreds or thousands of databases. Often these databases run on different platforms on multiple physical servers. Because of improvements in hardware technology, especially the increase in the number of CPUs, servers are able to handle heavier workloads than before. A database may use only a fraction of the server hardware capacity. This approach wastes both hardware and human resources.
For example, 100 servers may have one database each, with each database using 10% of hardware resources and 10% of an administrator's time. A team of DBAs must manage the SGA, database files, accounts, security, and so on of each database separately, while system administrators must maintain 100 different computers.
To show the problem in reduced scale, Figure 17-1 depicts 11 databases, each with its own application and server. A head DBA oversees a team of four DBAs, each of whom is responsible for two or three databases.
Figure 17-1 Database Environment Before Database Consolidation
Description of Figure 17-1 follows
Description of "Figure 17-1 Database Environment Before Database Consolidation"
A typical response to the management problem is to place multiple databases on each server. The problem is that the multiple database instances do not share background processes, system and process memory, or Oracle metadata. Another response is to logically separate the data into schemas or virtual private databases. The problem is that these virtual entities are difficult to manage, secure, and transport.

Benefits of the Multitenant Architecture for Database Consolidation

The process of consolidating data from multiple databases into one database on one computer is known as database consolidation. Starting in Oracle Database 12c, the Oracle Multitenant option enables you to consolidate data and code without altering existing schemas or applications.
The PDB/non-CDB compatibility guarantee means that a PDB behaves the same as a non-CDB as seen from a client connecting with Oracle Net. The installation scheme for an application back end that runs against a non-CDB runs the same against a PDB and produces the same result. Also, the run-time behavior of client code that connects to the PDB containing the application back end is identical to the behavior of client code that connected to the non-CDB containing this back end.
Operations that act on an entire non-CDB act in the same way on an entire CDB, for example, when using Oracle Data Guard and database backup and recovery. Thus, the users, administrators, and developers of a non-CDB have substantially the same experience after the database has been consolidated.
Figure 17-2 depicts the databases in Figure 17-1 after consolidation onto one computer. The DBA team is reduced from five to three, with one CDB administrator managing the CDB while two PDB administrators split management of the PDBs.
Using the multitenant architecture for database consolidation has the following benefits:
  • Cost reduction
    By consolidating hardware and sharing database memory and files, you reduce costs for hardware, storage, availability, and labor. For example, 100 PDBs on a single server share one database instance and one set of database files, thereby requiring less hardware and fewer personnel.
  • Easier and more rapid movement of data and code
    By design, you can quickly plug a PDB into a CDB, unplug the PDB from the CDB, and then plug this PDB into a different CDB. The implementation technique for plugging and unplugging is similar to the transportable tablespace technique.
  • Easier management and monitoring of the physical database
    The CDB administrator can attend to one physical database (one set of files and one set of database instances) rather than split attention among dozens or hundreds of non-CDBs. Backup strategies and disaster recovery are simplified.
  • Separation of data and code
    Although consolidated into a single physical database, PDBs mimic the behavior of non-CDBs. For example, if user error loses critical data, a PDB administrator can use Oracle Flashback or point-in-time recovery to retrieve the lost data without affecting other PDBs.
  • Secure separation of administrative duties
    A user account is common, which means that it can connect to any container on which it has privileges, or local, which means that it is restricted to a specific PDB. A CDB administrator can use a common user account to manage the CDB. A PDB administrator uses a local account to manage an individual PDB. Because a privilege is contained within the container in which it is granted, a local user on one PDB does not have privileges on other PDBs within the same CDB.
  • Ease of performance tuning
    It is easier to collect performance metrics for a single database than for multiple databases. It is easier to size one SGA than 100 SGAs.
  • Support for Oracle Database Resource Manager
    In a multitenant environment, one concern is contention for system resources among the PDBs running on the same computer. Another concern is limiting resource usage for more consistent, predictable performance. To address such resource contention, usage, and monitoring issues, you can use Oracle Database Resource Manager (see "Database Resource Manager").
  • Fewer database patches and upgrades
    It is easier to apply a patch to one database than to 100 databases, and to upgrade one database than to upgrade 100 databases.
See Also:
Oracle Database Administrator's Guide

Benefits of the Multitenant Architecture for Manageability

The multitenant architecture has benefits beyond database consolidation. These benefits derive from storing the data and data dictionary metadata specific to a PDB in the PDB itself rather than storing all dictionary metadata in one place. By storing its own dictionary metadata, a PDB becomes easier to manage as a distinct unit, even when only one PDB resides in a CDB.
Benefits of data dictionary separation include the following:
  • Easier migration of data and code
    For example, instead of upgrading a CDB from one database release to another, you can unplug a PDB from the existing CDB, and then plug it into a newly created CDB from a higher release.
  • Easier testing of applications
    You can develop an application on a test PDB and, when it is ready for deployment, plug this PDB into the production CDB.
See Also:
"Data Dictionary Architecture in a CDB"

Path to Database Consolidation

For the duration of its existence, a database is either a CDB or a non-CDB. You cannot transform a non-CDB into a CDB or vice versa. You must define a database as a CDB at creation, and then create PDBs within this CDB.
The basic path to database consolidation is:

Creation of a CDB

The CREATE DATABASE ... ENABLE PLUGGABLE DATABASE SQL statement creates a new CDB. If you do not specify the ENABLE PLUGGABLE DATABASE clause, then the newly created database is a non-CDB and can never contain PDBs.
Along with the root (CDB$ROOT), Oracle Database automatically creates a seed PDB (PDB$SEED). The following graphic shows a newly created CDB:
Description of admin095.png follows
Description of the illustration admin095.png

Example 17-1 shows a simple query for determining whether the database to which an administrative user is currently connected is a non-CDB, or a container in a CDB.
Example 17-1 Determining Whether a Database Is a CDB
SQL> SELECT NAME, CDB, CON_ID FROM V$DATABASE;
 
NAME      CDB     CON_ID
--------- --- ----------
CDB1      YES          0
See Also:

Creation of a PDB

The CREATE PLUGGABLE DATABASE SQL statement creates a PDB. This PDB automatically includes a full data dictionary including metadata and internal links to system-supplied objects in the root. You can only create a PDB in a CDB and not within another PDB.
The following graphic depicts the options for creating a PDB:
Description of cncpt358.png follows
Description of the illustration cncpt358.png

The following graphic shows a CDB that contains six PDBs. hrpdb is a newly created PDB. salespdb was a pre-existing PDB that was unplugged from a different CDB and plugged into this CDB. The remaining four PDBs, each of whose names contains the prefix test, were copied from salespdb.
Description of cncpt350.png follows
Description of the illustration cncpt350.png

The following sections describe the different techniques for creating PDBs.

Creation of a PDB from Seed

You can use the CREATE PLUGGABLE DATABASE statement to create a PDB by copying the files from PDB$SEED, which is a template for creating PDBs. The following graphic illustrates creation from the seed:
Description of admin089.png follows
Description of the illustration admin089.png

The following SQL statement creates a PDB named hrpdb from the seed using Oracle Managed Files:
CREATE PLUGGABLE DATABASE hrpdb
 ADMIN USER dba1 IDENTIFIED BY password
See Also:
Oracle Database Administrator's Guide to learn this technique

Creation of a PDB by Cloning a PDB

This technique copies the files associated with the source PDB to a new location and associates the copied files with the new PDB. You can clone a PDB that resides in the same CDB or in a different CDB. If in a different CDB, then you must use a database link to specify the remote CDB that contains the PDB to be cloned. The following graphic illustrates cloning a PDB from an existing PDB in the same CDB:
Description of admin091.png follows
Description of the illustration admin091.png

If the underlying file system of a PDB supports storage snapshots, then you may specify the SNAPSHOT COPY clause to clone a PDB using storage snapshots. In this case, Oracle Database does not make a complete copy of source data files, but creates a storage-level snapshot of the underlying file system, and uses it to create PDB clones. Snapshot copies make cloning almost instantaneous.
The following SQL statement clones a PDB named salespdb from the plugged-in PDB named hrpdb:
CREATE PLUGGABLE DATABASE salespdb FROM hrpdb
See Also:
Oracle Database Administrator's Guide to learn how to perform this technique

Creation of a PDB by Plugging in an Unplugged PDB

In its unplugged state, a PDB is a self-contained set of data files and an XML metadata file. This technique uses the XML metadata file that describes the PDB and the files associated with the PDB to associate it with the CDB. The following graphic illustrates plugging in an unplugged PDB:
Description of admin090.png follows
Description of the illustration admin090.png

The following SQL statement plugs in a PDB named financepdb based on the metadata stored in the named XML file, and specifies NOCOPY because the files of the unplugged PDB do not need to be renamed:
CREATE PLUGGABLE DATABASE salespdb USING '/disk1/usr/financepdb.xml' NOCOPY
See Also:
Oracle Database Administrator's Guide to learn how to perform this technique

Creation of a PDB from a Non-CDB

You can use any of the following techniques to create a PDB from an existing non-CDB:
  • Execute DBMS_PDB.DESCRIBE on a non-CDB in Oracle Database 12c
    You place a non-CDB in a transactionally consistent state, and then run the DBMS_PDB.DESCRIBE function to generate XML metadata about this database. While connected to the root in the CDB, you execute the CREATE PLUGGABLE DATABASE statement to create a PDB from the existing non-CDB.
    See Oracle Database Administrator's Guide to learn how to perform this technique.
  • Use Oracle Data Pump with or without transportable tablespaces
    You can use Oracle Data Pump to define a data set on a non-CDB. This non-CDB can be in the current or a previous Oracle Database release, for example, Oracle Database 10g. You create an empty PDB in an existing CDB, and then use Oracle Data Pump to import the data set into the PDB.
    A Full Transportable Export using Oracle Data Pump exports all objects and data necessary to create a complete copy of the database. Oracle Data Pump exports all objects that can be exported using the transportable option, and then exports the remaining objects using direct-path INSERT and external tables. The Full Transportable dump file contains all objects in the database, not only table-related objects. Full Transportable Export is available starting in Oracle Database 11g Release 2 (11.2.0.3) for import into Oracle Database 12c.
    See Oracle Database Administrator's Guide to learn how to perform this technique.
  • Use Oracle GoldenGate replication
    You replicate the data from the non-CDB to a PDB. When the PDB catches up with the non-CDB, you fail over to the PDB.
    See Oracle Database Administrator's Guide to learn how to perform this technique.
The following graphic illustrates the technique of running the DBMS_PDB.DESCRIBE function on a non-CDB, and then creating a PDB using the non-CDB files:
Description of admin098.png follows
Description of the illustration admin098.png

See Also:

Multitenant Environment Documentation Roadmap

Table 17-1 lists the most important topics for understanding and using CDBs, and includes cross-references to the appropriate documentation.
Table 17-1 Roadmap for the Multitenant Architecture Documentation
CategoryTopicDocumentation
Concepts
Overview of CDBs and PDBs
Administration
Creating and configuring a CDB
Administration
Managing a CDB
Administration
Creating and configuring a PDB
Administration
Managing a PDB
Performance
Troubleshooting PDBs
Backup and Recovery
Performing backup and recovery in a CDB
Security
Managing common users, roles, and privileges in a CDB
Miscellaneous
All other tasks relating to managing a CDB or PDB, including Oracle RAC, resource management, data transfer, and so on
Oracle Database Administrator's Guide is the primary task-oriented intermediate and advanced documentation for managing CDBs. This guide also contains See Also links to books that cover different CDB topics. For example, Oracle Database Utilities explains concepts and tasks specific to PDBs when using Oracle Data Pump.

Posted by at No comments:

Connecting to Container Databases (CDB) and Pluggable Databases (PDB) in Oracle Database 12c Release 1

The multitenant option introduced in Oracle Database 12c allows a single container database (CDB) to host multiple separate pluggable databases (PDB). This article describes how to connect to container databases (CDB) and pluggable databases (PDB).

Connecting to a Container Database (CDB)

Connecting to the root of a container database is the same as that of any previous database instance. On the database server you can use OS Authentication.
$ export ORACLE_SID=orcl
$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Aug 26 15:29:49 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL>
You can connect to other common users in similar way.
SQL> CONN system/password
Connected.
SQL>
The V$SERVICES views can be used to display available services from the database.
COLUMN name FORMAT A30

SELECT name, pdb
FROM   v$services
ORDER BY name;

NAME          PDB
------------------------------ ------------------------------
SYS$BACKGROUND         CDB$ROOT
SYS$USERS         CDB$ROOT
orcl.testbd.com                CDB$ROOT
cdb1XDB          CDB$ROOT
pdb1.testbd.com                               PDB1
pdb2.testbd.com                               PDB2

6 rows selected.

SQL>
The lsnrctl utility allows you to display the available services from the command line.
$ lsnrctl service

LSNRCTL for Linux: Version 12.1.0.1.0 - Production on 26-AUG-2013 16:00:35

Copyright (c) 1991, 2013, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
Services Summary...
Service "orcl.testbd.com" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:45 refused:0 state:ready
         LOCAL SERVER
Service "orclXDB.testbd.com" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
    Handler(s):
      "D000" established:0 refused:0 current:0 max:1022 state:ready
         DISPATCHER <machine: 192.xxx.xxx.100, pid: 22812>
         (ADDRESS=(PROTOCOL=tcp)(HOST=192.xxx.xxx.100)(PORT=1521))
Service "pdb1.testbd.com" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:45 refused:0 state:ready
         LOCAL SERVER
Service "pdb2.testbd.com" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:45 refused:0 state:ready
         LOCAL SERVER
The command completed successfully
$
Connections using services are unchanged from previous versions.
SQL> -- EZCONNECT
SQL> CONN system/password@//localhost:1521/orcl.testbd.com
Connected.
SQL>

SQL> -- tnsnames.ora
SQL> CONN system/password@cdb1
Connected.
SQL>
The connection using a TNS alias requires an entry in the "$ORACLE_HOME/network/admin/tnsnames.ora" file, such as the one shown below.
orcl =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.xxx.xxx.100)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.testbd.com)
    )
  )

Displaying the Current Container

The SHOW CON_NAME command in SQL*Plus displays the current container name.
SQL> SHOW CON_NAME

CON_NAME
------------------------------
CDB$ROOT
SQL>
It can also be retrieved using the SYS_CONTEXT function.
SELECT SYS_CONTEXT('USERENV', 'CON_NAME')
FROM   dual;

SYS_CONTEXT('USERENV','CON_NAME')
--------------------------------------------------------------------------------
CDB$ROOT

SQL>

Switching Between Containers

When logged in to the CDB as an appropriately privileged user, the ALTER SESSION command can be used to switch between containers within the container database.
SQL> ALTER SESSION SET container = pdb1;

Session altered.

SQL> SHOW CON_NAME

CON_NAME
------------------------------
PDB1
SQL> ALTER SESSION SET container = cdb$root;

Session altered.

SQL> SHOW CON_NAME

CON_NAME
------------------------------
CDB$ROOT
SQL>

Connecting to a Pluggable Database (PDB)

Direct connections to pluggable databases must be made using a service. Each pluggable database automatically registers a service with the listener. This is how any application will connect to a pluggable database, as well as administrative connections.
SQL> -- EZCONNECT
SQL> CONN system/password@//localhost:1521/pdb1.testbd.com
Connected.
SQL>

SQL> -- tnsnames.ora
SQL> CONN system/password@pdb1
Connected.
SQL>
The connection using a TNS alias requires an entry in the "$ORACLE_HOME/network/admin/tnsnames.ora" file, such as the one shown below.
PDB1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.xxx.xxx.100)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = pdb1.testbd.com)
    )
  )

PDB users with the SYSDBA, SYSOPER, SYSBACKUP, or SYSDG privilege can connect to a closed PDB. All other PDB users can only connect when the PDB is open. As with regular databases, the PDB users require the CONNECT SESSION privilege to enable connections.
Posted by at No comments:

Wednesday, September 11, 2013

New features in Oracle Clusterware 12c

1. Oracle Flex ASM - This feature of Oracle Clusterware 12c claims to reduce per-node overhead of using ASM instance. Now the instances can use remote node ASM for any planned/unplanned downtime. ASM metadata requests can be converted by non-local instance of ASM.

2. ASM Disk Scrubbing - From RAC 12c, ASM comes with disk scrubbing feature so that logical corruptions can be discovered. Also Oracle 12c ASM can automatically correct this in normal or high redundancy diskgroups.

3. Oracle ASM Disk Resync & Rebalance enhancements.

4. Application Continuity (AC) - is transparent to the application and in-case the database or the infrastructure is unavailable, this new features which work on JDBC drivers, masks recoverable outages. This recovers database session beneath the application so that the outage actually appears to be delayed connectivity or execution. Transaction guard (improvements of Fast Application Notification).

5. IPv6 Support - Oracle RAC 12c now supports IPv6 for Client connectivity, Interconnect is still on IPv4.

6. Per Subnet multiple SCAN - RAC 12c, per-Subnet multiple SCAN can be configured per cluster.

7. Each RAC instance opens the Container Database (CDB) as a whole so that versions would be same for CDB as well as for all of the Pluggable Databases (PDBs). PDBs are also fully compatible with RAC.

8. Oracle installer will run root.sh script across nodes. We don't have to run the scripts manually on all RAC nodes. 

9. New "ghctl" command for patching.

10. TAF is extended to DML transactions failover (insert/update/delete).


10. TAF is extended to DML transactions failover (insert/update/delete).
Posted by at No comments:

Saturday, August 17, 2013

ORA-16191: Primary log shipping client not logged on standby

Changing SYS password of PRIMARY database when STANDBY in place to avoid ORA-16191
Refrence DOC ID 806703.1

Applies to:

Oracle Server - Enterprise Edition - Version: 9.2.0.8 to 11.1.0.7 - Release: 9.2 to 11.1
Information in this document applies to any platform.

Goal

What are the steps to change the SYS password in PRIMARY when STANDBY database in place to avoid ORA-16191 -Primary log shipping client not logged on standby

Solution


INSTRUCTIONS
Its advisable to follow the steps below when you are planning to change the SYS password in PRIMARY

Step 1: Defer the remote archival destination (log_archive_dest_state_n) parameter in primary. In case of RAC defer LOG_ARCHIVE_DEST_STATE_n in all nodes.
Step 2: change the password in primary
Step 3: Recreate or copy the password file in standby. In case of RAC shutdown all instance of standby before recreating the password file.
Step 4: Enable the remote archival destination (log_archive_dest_state_n) parameter in primary

If the password is already changed, and you are getting ORA-16191 during log shipping then follow the below action.

Action: Copy the password file from PRIMARY to STANDBY (OR) recreate the password file in standby with the same password.


For 9i database
By default the redo is shipped via SYS user, Its not mandatory to have the SYS password to be identical in PRIMARY and STANDBY for 9i dataguard configuration.

For 10g database

a) Every database in a Data Guard configuration must use a password file, and the password for the SYS user must be identical on every system for redo data transmission to succeed.

b) REMOTE_LOGIN_PASSWORDFILE parameter setting should be either EXCLUSIVE or SHARED.


For 11g database With 11.0, we are using strong password authentication by default, and so the password file has to be identical at primary and physical, so it needs to be copied - i.e orapwd using the same password for SYS does not work anymore, unless you choose to bypass the strong authentication framework.

Turn off case sensitivity by changing the init.ora parameter
SEC_CASE_SENSITIVE_LOGON=FALSE
Create password files on both servers using the same password, and pass "ignorecase=Y" to orapwd utility.
Also, starting from 11g The REDO_TRANSPORT_USER database initialization parameter can be used to select a different user password for redo transport authentication by setting this parameter to the name of any user who has been granted the SYSOPER privilege. The REDO_TRANSPORT_USER parameter be set to the same value on the redo source database and at each redo transport destination.
Posted by at No comments:

Saturday, July 27, 2013

Fatal NI connect error 12514:

alert.log file has many entries for Fatal NI connect error.

Examples:

Fatal NI connect error 12514, connecting to:
 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.77.3)(PORT=1971))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=brtadbstd01_DGB.brta.gov.bd)(CID=(PROGRAM=oracle)(HOST=brtadb.brta.gov.bd)(USER=oracle))))

  VERSION INFORMATION:
    TNS for Linux: Version 11.2.0.3.0 - Production
    TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.3.0 - Production
  Time: 27-JUL-2013 09:15:33
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12564
   
TNS-12564: TNS:connection refused
    ns secondary err code: 0
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0

 Solution:

We will have an entry on the alert.log file every time a client connection of any kind fails to complete or is aborted.

One way to minimize the impact is by using the parameter SQLNET.INBOUND_CONNECT_TIMEOUT (default to 60 seconds on 10gR2 and 11g) but, sometimes, this value is not adequate.

Oracle also mentions the occurrence of this error if you use DB Console or Enterprise Manager to monitor your databases and the emagent will try to connect to the target database repeatedly and, statistically, some will fail (frequency will depend on how busy your system is).

Most of the time (certainly for DB Console and Enterprise Manager Agent) the application will try to connect again and it will succeed.

To fix the problem you could increase the value of SQLNET.INBOUND_CONNECT_TIMEOUT on the listener.ora and the sqlnet.ora file located on the server side.

If you already have a value you have considered adequate, you might want to add the following line on your listener.ora file:
DIAG_ADR_ENABLED_listener_name=OFF

This line will hide the error on the alert.log file and the error will be posted on the $ORACLE_HOME/network/log/sqlnet.log file
Posted by at No comments:
Memory Notification: Library Cache Object loaded into SGA
Heap size 8819K exceeds notification threshold (2048K)

Hello viewers:

Today Morning i have found that the  message on alertlog of oracle 10g r2 version 10.2.0.1. To  avoid these messages being generated, we need to adjust the size of a hidden initialization parameter. The hidden  initialization parameter is “_kgl_large_heap_warning_threshold”. We can avoid this message to set a high value or zero.

 Note:- Set  "_kgl_large_heap_warning_threshold" to a reasonable high value or zero to prevent these warning messages. Value needs to be set in bytes. The default threshold in 10.2.0.1 is 2MB. So these messages could show up frequently in some application environments. In 10.2.0.2, the threshold was increased to 50MB after regression tests, so this should be a reasonable and recommended value.

To modify this parameter:

login as sysdba

SQL> connect sys as sysdba
SQL> alter system set "_kgl_large_heap_warning_threshold"=52428800 scope=spfile ;
System altered.


SQL> shutdown immediate;
SQL> startup;


Now the following message will not come.
Posted by at No comments:

Friday, July 26, 2013

Why Oracle 12c?

Oracle Database 12c introduces a new multitenant architecture that makes it easy to deploy and manage database clouds. Innovations such as Oracle Multitenant, for consolidating multiple databases quickly, and Automatic Data Optimization with Heat Map, for compressing and tiering data at a higher density, maximize resource efficiency and flexibility. These unique advancements, combined with major enhancements in availability, security, and big data support, make Oracle Database 12c the ideal platform for private and public cloud deployments.
Benefits
  • New multitenant architecture enables higher levels of consolidation on the cloud without the need to change existing applications
  • Automatic Data Optimization features efficiently manage more data, lower storage costs, and improve database performance
  • Defense-in-depth database security addresses evolving threats and stringent data privacy regulations
  • Maximize availability with protection from server failure, site failure, human error, reduced planned downtime, and application continuity
  • Scalable discovery of business event sequences with enhanced in-database analytics capabilities for big data
  • Seamless integration with Oracle Enterprise Manager Cloud Control 12c enables administrators to easily manage the entire database lifecycle

 



Posted by at No comments:
Subscribe to: Posts (Atom)