Setup Oracle sql plus client on AWS Ubuntu/Linux

Setup Oracle sql plus client on AWS Ubuntu/Linux

Dependencies :

• AWS Instance with Ubuntu/Linux
• Oracle Instant Client package
• Oracle SQL Plus package

Steps to Install the Client : 

1. First we need to install alien package

sudo apt -get install alien

2. Install downloaded instant rpm package<client>

sudo alien -i oracle-instantclient11.2-basic-11.2.0.3.0-1.x86_64.rpm 

3. Install downloaded sql plus package

sudo alien -i oracle-instantclient11.2-sqlplus-11.2.0.3.0-1.x86_64.rpm 

4. Install libaio1,libaio-dev packages if not already installed. Usually in vanilla ubuntu 14 l

ibaio1, libaio-dev packages are not pre-installed. 

5. Export oracle client lib directory path to LD_LIBRARY_PATH variable. 

export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib/${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}

6. Test the client now.

Following sql prompt will appear by using credentials are correct.

ubuntu@ip-272-300-203-2222:~/oracle_client$ sqlplus64
username/password@//rds_hostname:1521/ORCL
SQL*Plus: Release 11.2.0.3.0 Production on Thu Apr 14 07:44:56
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
connected to:
oracle Database 11g Enterprise Edition release 11.2.0.4.0-64 bit production
With the portioning ,Oracle Label Security,Olap,Data Mining ans Real Application Testing Options

OSB Performance Tuning – RouterRuntimeCache

A critical performance tuning parameter for Oracle Service Bus (OSB) is the setting for RouterRuntimeCache.  The following article describes this parameter and the impact of changes to it.

Main Article

Many customers start out with smaller projects for an initial release.  Typically, these applications require 20-30 Proxy services.  But as time goes on and later phases of the project rollout, the number of proxy services can increase drastically.  The RouterRuntimeCache is a cache implemented by OSB to improve performance by eliminating or reducing the amount of time spent on compiling the proxy pipeline.

By default, OSB will not compile a pipeline until a request message for a given service is received.  Once it has been compiled, the pipeline is cached in memory for re-use.  You have probably noticed in testing that the first request to a service takes longer to respond than subsequent requests, and this is a big part of the reason.  Since free heap space is often at a premium, this cache can not be infinite in size so this cache has a built in limit.  When the cache is full, the least recently used entry is released and the pipeline that is currently being requested is placed into cache in its place.  The next time a request comes in for the service who’s pipeline was released, that pipeline has to be re-compiled and placed in cache, again forcing out the least recently used pipeline.  Once a pipeline is placed in cache it is never removed from cache unless forced out by a full cache scenario as above, or if the service is updated, forcing it to be recompiled.

The default size limit of the RouterRuntimeCache is 100 entries (or pipelines).  It is limited by the number of services in the cache, not the memory used by the cache so the amount of memory used by a full cache will vary greatly based on the complexity of the services, the extent and complexity of inline xquery, etc.  If your project grows beyond 100 proxy services, system performance can degrade significantly if the cache size is not increased to hold all frequently used services.

Unfortunately, the way to tune this cache is not exposed through the OSB console. As of 11g PS5, the only way to set this parameter is via a system property specified on the Java command-line. The property name is com.bea.wli.sb.pipeline.RouterRuntimeCache.size.   For example,

“java … -Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size=500 …
weblogic.Server …”.

In this example, OSB will cache 500 proxies, instead of the default 100.  Because increasing the RouterRuntimeCache.size value will require more space in the heap to hold the additional proxies, be aware that you may need to reevaluate your JVM memory settings to allow OSB to continue to perform optimally.

Purging and partitioned schemas

SOA Suite 11g and 12c both require regular database maintenance for optimal performance. A key task in managing your SOA Suite database is a regular purging strategy. You should be doing this, so read the Oracle SOA Suite database growth management strategy if you haven’t already: 

One of the best practices for managing large SOA Suite applications is to use Oracle Database partitioning. In 11g this is usually a fairly ad-hoc setup, though the whitepaper has everything you need to know about setting it up; in 12c, the “LARGE” RCU profile is partitioned (with monthly partitions).Purging a partitioned schema usually involves running the check and move scripts, to ensure your partitions don’t contain “LIVE” data (based on your retention policy), followed by dropping the “OLD” partitions and rebuilding the indexes.However, there are times where you may want to run a purge to clean up data that doesn’t neatly align with the partitions, for example in a load testing environment. 

      The purge scripts, by default, won’t touch any table that is partitioned. If your favourite table isn’t mentioned in the purge debug log output (example below), then it is probably because it is partitioned.

To force the purge scripts to consider partitioned tables, you need to enable the “purge_partitioned_component” flag to the “delete instances” purge function (see below). The purge script will then purge partitioned tables.Obviously, this is not intended for regular production use and it should never be used there.

An example invocation with the flag set:
soa.delete_instances(max_runtime => 300, min_creation_date => to_timestamp('2000-01-01','YYYY-MM-DD'), max_creation_date => to_timestamp('2000-12-31','YYYY-MM-DD'), purge_partitioned_component=TRUE);

The example output below is from a soa.delete_instances run that has a partition on composite_instance. Note that there is no mention of composite_instance in the output.
There are several tables which can be partitioned, as well as whole units (such as BPEL). The purge script will skip any that have a partition. (If you are interested, you can search the PLSQL packages in a SOAINFRA schema for ‘is_table_partitioned’ to see which tables are checked and which columns it considers for partitioning).01-JAN-2000 12:00:00 : procedure delete_instances