Sunday, January 22, 2012

WebLogic 10.3.5 Clustering Notes

Official Oracle Documentation on WebLogic Clustering is here
  1. Click here for the recommended architecture
  2. What means of cluster communications are considered ideal?
    The choice is between  Unicast and IP Sockets.  "When creating a new cluster, Oracle recommends that Unicast is used for messaging within a cluster.  Multicast is used only for backwards compatibility".
  3. What about IP sockets?
    It seems that "IP sockets provide a simple, high-performance mechanism for transferring messages and data between two applications". Are IP sockets the best performance alternative? It seems to be.
  4. We should use the native socket reader implementation
    "For best socket performance, configure the WebLogic Server host machine to use the native socket reader implementation for your operating system, rather than the pure-Java implementation." See here for instructions on how to configure native ip sockets
  5. Deployment guidelines:
    1. Even though "partial" deployments are supported, it is better that all Servers in the cluster must are running during deployment
    2. Cluster membership should not change during the deployment process.
  6. Load balancing, Software or Hardware?
    1. Software: use of HttpClusterServlet deployed as a front-end application.
    2. Hardware: Clusters that employ a hardware load balancing solution can use any load balancing algorithm supported by the hardware. These can include advanced load-based balancing strategies that monitor the utilization of individual machines. For load balancing hardware instead of a proxy plug-in, it must support a compatible passive or active cookie persistence mechanism, and SSL persistence.
    3. From this page, It seems that Round-Robin Load Balancing is the only method supported for Servlets/Jsps.  All other methods are for EJBs
  7. Replication
    Coherence*Web seems to be a good option for Http session replication, particularly for large ADF applications that use jbo application modules.  See this page for more info.
  8. Failover
    1. Whole Server Migration: In the event of failure, the whole server is migrated to another web logic server in the cluster.  Used for failover of "pinned" services such as JMS and the JTA
    2. Service Migration: In the event of failure of a service, the service is migrated to another web logic server in the cluster.

To be continued soon...

Saturday, January 21, 2012

Working with the new SQLLocalDB From Microsoft

SQLLocalDB  is a new, lightweight database engine from Microsoft.  You can get it from here.  I have downloaded it and installed the 64 bit version on my Windows 7 laptop.  However, after installation there are no shortcuts created so no gui to manage this "instance".

To start the database engine, open a command line window and type the following:
1.
cd "c:\Program Files\Microsoft SQL Server\110\Tools\Binn"
Substitute for your installation directory.
2. Type:
"SqlLocalDB create "SQL11Local" 11.0 -s"
This will create an sql server instance called "SQL11Local" and start it.
3. Type:
"SQLLocalDB info SQL11Local"
Note the Instance pipe name in the info window.  We will use that to connect to this instance from SQL Server Management Studio

Now start SQL management Studio and in the Server name textbox copy and paste the Instance pipe name from the info command results.  You should connect to the database instance and you can do all the usual things like create , delete and attach databases.

Wednesday, January 11, 2012

Transferring Data Of a Big 9i Oracle Database to 11gR2

Currently I was involved in upgrading a 40 GB Oracle database installation from 9i to 11g release 2. In place upgrade was out of the question since (1) We moved from Solaris to Linux and (2) Downtime should be kept to a minimum

The 9i setup consisted of an Oracle 9i enterprise server, with multiple database instances. One instance had 40 GB of data. This is the procedure we used, which I believe is the quickest way possible to move this amount of data:

On the 9i database server:
  1. Identify and Clear all tables with temporary data.  This includes temporary report tables, backup tables, log tables etc.  In our case, this saved us a gigabyte. 
  2. Export all database intances using the exp utility on the 9i server. Be careful to not allow connections to the database while exporting since sequences can be out of sync.  Do not export the sys user schema.
  3. Create scripts to create tablespaces, schema users and oracle directories 
Now, on the 11g database server
Note: Steps 1, 2 and 3 below can be scripted using bash and sqlplus.
  1. Create all tablespaces on the target 11g database.  Tablespace reorganization complicates the migration so I would advice against it.  Plus, the imp utility expects to find the same tablespaces when importing data of tables with CLOB or BLOB fields    
  2. Create all schema users on the target 11g database.
  3. Create all directories on the target 11g database, both on the database and also on the operating system level and grant the appropriate rights to the appropriate users.
  4. Run import with ROWS=N CONSTRAINTS=Y INDEXFILE=INDEXES.SQL, to create sql statement script for index creation.  Here's an example below.
    $ export ORACLE_SID=ORADB
    $ imp \'sys/oracle as sysdba\' file=/home/oracle/expdat.dmp log=createIndexes.log FROMUSER=oracleuser TOUSER=oracleuser ROWS=n INDEXES=Y CONSTRAINTS=Y INDEXFILE=INDEXES.SQL
  5. Run imp with options ROWS=n INDEXES=N CONSTRAINTS=N STATISTICS=NONE This will create empty tables in the database w/o constraints and indexes, and also import procedures, triggers, and sequences.
  6. Disable Constraints and Triggers in the database.  (click to get the scripts)
  7. Imports table data by running the imp utility with ANALYZE=n BUFFER=100000000 recordlength=65535 FEEDBACK=10000 IGNORE=Y ROWS=Y INDEXES=N CONSTRAINTS=N STATISTICS=NONE
  8. In sqlplus run INDEXES.SQL (created in step 4 above) to create database indexes
  9. Analyze tables in database.  In sqlplus run:
    exec dbms_stats.gather_schema_stats( 
         ownname          => 'oracleuser', 
         estimate_percent => dbms_stats.auto_sample_size, 
         method_opt       => 'for all columns size repeat', 
         degree           => 34 );