Feed aggregator

Advert – MOW

Jonathan Lewis - 4 hours 49 min ago

I’ve just noticed that Miracle Open World is less than a month away – so I just had to bounce this advert to the top of the blog to remind people about this event, which probably has the highest concentration of international speaker per square metre of any Oracle conference in the world. But you [...]

Forms : LongBridge "FormsImageBean" Java Bean NEW Version 2.1

Francois Degrelle - 8 hours 15 min ago

LongBridge "FormsImageBean" Java Bean NEW Version 2.1

LongBridge FormsImageBean
Image Capture, Storage, Retrieval
Manipulation and Management

New, Improved & Productive FormsImageBean (Version 2.1) for your Real-World Document Management needs !!!

Version 2.1 features include:

[...]

OC4J 10.1.3.x - Accessing a Data Source remotely without oc4jadmin user

Pas Apicella - Sun, 2010-03-14 19:59

I previously showed how one would remotely access JNDI object's which include EJB's , Data Sources etc as shown in this post below.

http://theblasfrompas.blogspot.com/2008/07/enable-remote-clients-to-access-oas.html

Typically internally I use oc4jadmin who has access to everything and of course it has no issues. However in the real world 2 things are just about certain.

1. A Data Source would most likely be created at the container level for applications to share allthough it's not uncommon for them to be created at the application level.

2. The OAS administrator would almost certainly provide a separate user for JNDI access.

With such a setup the user created won't be able to access container specific JNDI objects such as data sources as most likely the OAS administrator won't make the user given part of the "oc4j-administrators" group. In this case the same principals as the blog entry apply however you won't find a container orion-application.xml.

So assuming you have a Data Source created in the HOME container you would need to alter the file below and then stop/start the instance to allow users to access container specific JNDI objects such as a Data Source. This demo assumes your user is part of the group called "users" as per the blog entry above.

$ORACLE_HOME/j2ee/home/config/application.xml


<namespace-access>
  <read-access>
    <namespace-resource root="">
      <security-role-mapping>
              <group name="oc4j-administrators" />
              <group name="ascontrol_admin" />
              <group name="users" />
      </security-role-mapping>
    </namespace-resource>
  </read-access>
  <write-access>
      <namespace-resource root="">
        <security-role-mapping>
                <group name="oc4j-administrators" />
                <group name="ascontrol_admin" />
                <group name="users" />
        </security-role-mapping>
      </namespace-resource>
  </write-access>
</namespace-access>

http://feeds.feedburner.com/TheBlasFromPas

Categories: Fusion Middleware

Oracle and Google Nexus

Paul Wright - Sun, 2010-03-14 18:59

Hi All, Nice paper from Pete on Sentrigo Hedgehog usage which also references the Java vulnerability work by David. I noticed that David’s 11g presentation is up at YouTube http://www.youtube.com/watch?v=IZq3D2pvyNE ~ I have already seen the vulnerability being adapted to provide other CREATE SESSION to DBA escalations not yet published… this research is opening the door to [...]

Toward a NoSQL taxonomy

DBMS2 - Sun, 2010-03-14 17:24

I talked Friday with Dwight Merriman, founder of 10gen (the MongoDB company). He more or less convinced me of his definition of NoSQL systems, which in my adaptation goes:

NoSQL = HVSP (High Volume Simple Processing) without joins or explicit transactions

Within that realm, Dwight offered a two-part taxonomy of NoSQL systems, according to their data model and replication/sharding strategy. I’d be happier, however, with at least three parts to the taxonomy:

How data looks logically on a single node
How data is stored physically on a single node
How data is distributed, replicated, and reconciled across multiple nodes, and whether applications have to be aware of how the data is partitioned among nodes/shards.

After talking with Dwight, and also with Cassandra project chair Jonathan Ellis, I feel I’m doing decently in understanding the first of those three areas. But there’s a long way yet to go on the other two.

In Dwight’s opinion, as I understand it, NoSQL data models come in four general kinds.

Key-value stores, more or less pure. I.e., they store keys+BLOBs (Binary Large OBjects), except that the “Large” part of “BLOB” may not come into play.
Table-oriented, more or less. The major examples here are Google’s BigTable, and Cassandra.
Document-oriented, where a “document” is more like XML than free text. MongoDB and CouchDB are the big examples here.
Graph-oriented. To date, this is the smallest area of the four. I’m reserving judgment as to whether I agree it’s properly included in HVSP and NoSQL.

As Dwight sees it, JSON (JavaScript Object Notation) is the emerging markup standard for the document-oriented data models, and to some extent the BLOB part of key-value models as well. Reasons seem to include:

JSON is something web developers are likely to know anyway.
JSON, unlike XML, is schema-less. In the NoSQL world, that’s perceived as a good thing.
Perhaps for both these reasons, JSON is perceived as easier to use than XML.

Except as noted, I’m not aware of anything that solidly contradicts the above.

Dwight went on to say that there are two main NoSQL replication/sharding models, in line with the seminal papers to which I previously linked:

Based on or resembling Dynamo. The core idea here is accepting eventual consistency among nodes as being good enough, even if that means you sometimes read dirty data. The benefit is that you never are blocked from writing. By way of contrast, systems that enforce true inter-node consistency (think of a two-phase commit) can shut you down from writing if consistency guarantees aren’t being confirmed in a timely manner. Thus, in a Dynamo-like scheme you write data to multiple nodes, via consistent hashing; then when the time comes you read one or more nodes, and hope that what you’re getting back is a correct result.
Based on or resembling BigTable. In this model you’re trying to keep the nodes fully consistent in the usual way, e.g. by synchronous replication. Indeed, what’s being kept consistent is both data itself, and metadata about the data’s location. Details surely vary a lot from implementation to implementation.

I’m fuzzier on this stuff than on the data models, because to date nobody has ever explained to me how an actual live system (MongoDB, Cassandra, whatever) implements its replication strategy. Also, while I think that in both these models applications are allowed to be ignorant of the replication/sharding strategy, I’m not as sure of that as I’d like to be.

If we stop here, we already have something useful. MongoDB has a document data model, and is in the BigTable-like replication camp, at least at first. Cassandra has a table-like data model, and is on the Dynamo-like eventual consistency side. But to say those are the only differences that matter would be like saying that all shared-disk RDBMS (e.g., Oracle and Sybase IQ) are essentially alike. That, of course, would be nonsense.

So a third dimension needed in this taxonomy is how the systems actually bang data on and off of disk (or silicon, as the case may be). I don’t yet have an overview of that. I know something of how Cassandra does it, and will write about same in a future post, but that’s about it. So please stay tuned.

Categories: Other

Afraid to COMMIT;

Chet Justice - Sun, 2010-03-14 16:07

Going through some old documents, I found this little gem I had uncovered doing some analysis of the source code.

I found this crazy enough to save, so I hope you enjoy it.

I found 14 or 15 commits in a 115 line procedure. I was shocked and stunned. It was wrong on so many different levels. I share with you the pain I went through.

We'll start off with a call to the logging table (just a quick note, this was not a stored procedure but a INSERT statement).

log_something;

Creating a record in the THIS_TABLE, it will have a status of A. Everything in there has a status of A.

INSERT INTO this_table (my_id, start_date) 
VALUES ( l_my_id, sysdate)
RETURNING table_id INTO l_table_id;

I know some could argue for COMMITs being inside stored procedure, but it was hammered into my head at an early age that the calling application should perform the COMMIT.

COMMIT;

THIS_TABLE had multiple "rules" tables. I understood the concept, but the implementation was not so good. This is the first "rules" table.

UPDATE rule_tab
  SET status = 'D'
WHERE my_id = l_my_id
  AND status = 'A';

Just so you are aware, that STATUS column had no constraint on it other than the size VARCHAR2(1).

Guess what time it is?

COMMIT;

Here is the second

UPDATE other_rules_table
  SET status='D'
WHERE my_id = l_my_id
  AND status='A';

Guess what?

COMMIT;

OK...here comes the other awesome part...to switch the status back to A (Active), we're going to create a job...in 30 minutes

dbms_job.submit
  ( job => ln_jobno, 
    what => 'update rule_table set status=''A'' where my_id = '||l_my_id||' AND status = ''D'';', 
    next => sysdate+(.5/24));

COMMIT;

I kind of understand that one...for the job to go into the queue you have to issue the COMMIT.

For some reason, it's now cool to use a nested block.

BEGIN
  dbms_job.submit
    ( job => ln_jobno, 
      what => 'update other_rule_table set status=''A'' where my_id = '||l_my_id||' AND status = ''D'';', 
      next => sysdate+(.5/24) );

  COMMIT;
EXCEPTION
  WHEN OTHERS THEN
     insert into errors (name,error_date, text) 
     values ('it broke', sysdate, ' MY_ID '||l_my_id||' creating job  to set to a ');
     COMMIT;
END;

Now we have 2 jobs created, one to update THIS_TABLE and one to update my first "rules" table. -10 for using DML in a job. -10 for not putting them into a single job that could fail together. -30 for not creating a stored procedure to do this.

But wait, it's not over yet. We're getting to the very best part I think.

BEGIN
  dbms_job.submit
    ( job => ln_jobno, 
      what => 'insert into errors (name,error_date, text) 
                       values (''wow'', sysdate, ''error turning it back on') ;', 
      next => sysdate+(.5/24));

EXCEPTION
  WHEN others THEN
      insert into errors (name,error_date, text) 
      values ('doing stuff', sysdate, ' MY_ID '||l_my_id||' creating job to log errors');

    COMMIT;
END;

Did I catch a "niner" in there?

Did you catch what that final job did? It "logged" an error from the previous 2 jobs. Really? Do jobs work like that? I'm not really sure that they do.

This little snippet is just a snapshot into my life over the last few years. This kind of thing is everywhere. (I know everywhere!). I've mentioned before, but I've been reading The Daily WTF since 2005. Daily. I've learned more from that site than perhaps any other because you learn what not to do...which is just as important as what to do. It takes years to gain the necessary experience (read: screwing up) to know what not to do, The Daily WTF speeds that up significantly by allowing you to witness others mistakes. We've all made them, to be sure. It's whether we learn from them that is important.

Categories: BI & Warehousing

Installing Oracle 11gR2 on Ubuntu 9.10

The Anti-Kyte - Sun, 2010-03-14 13:46

Finally, I’ve got everything in place for the big one – installing 11gR2 on my Ubuntu server.
As far as the server is concerned, I’ve posted on everything I’ve done since I installed it onto the machine.
The pre-requisites for this Oracle installation were :

Installing the server and setting up ssh
Tunneling X over SSH
I also setup a SAMBA share on the server. This is not directly relevant to the Oracle setup but I’ve included a link to it here as it serves to complete the picture of the state of the server before I started the installation. It also has a section on mounting a USB stick on the server, which may be relevant when it comes to transferring the Oracle files onto the server.
Whilst I’m mentioning links, I should acknowledge the helpful information I got from here and especially here.

Whilst I’m here, I probably don’t need to mention that Oracle isn’t exactly supported on Ubuntu at the time of writing, so I assume that, if you are planning to go down this route, it’s for your own edification and amusement. If your planning to setup a production database environment, then you really should be doing so on a supported OS.

One final, but pertinent point to note is that, like many of my recent adventures with Ubuntu Server, this was achieved after a certain amount of trial and error. I know Oracle pretty well. However, I make no claims to being a linux expert. The steps that follow worked for me. That doesn’t mean that there’s not an easier/better/safer way to do it.

Pre-Requisite Checks

First stop are the pre-checks as recommended in the Oracle Installation Guide.
Once you’re happy that you’ve got the tin to do the job, it’s time to get the software.

Getting Oracle

Unfortunately, there’s no rpm package for this version, so you need to download 11g release 2 from here.
As I’m running the 32-bit server, I got the Linux x86 version of Oracle Database 11g Release 2 ( 11.0.2.0.1.0)

As you’ll notice from my previous posts, the server was prone to get a little unhappy when copying large files or large amounts of data generally to it from an external device. However, extracting the compressed download files worked fine.
To achieve this, I downloaded the required files onto a trusty memory stick, mounted it on the server, then unzipped it.
The files are in zip format, so I needed to get the unzip package :
sudo apt-get install unzip

Now with the USB mounted on /media/external (have a look here if you need details on how to do this):

cd /media sudo unzip /media/external/linux_11gR2_database_1of2.zip -d . sudo unzip /media/external/linux_11gR2_database_2of2.zip -d . cd sudo unmount /media/external
This should extract the files in the zips into a newly created directory called database under /media.

NOTE – it’s probably a good idea to make sure all is working as expected after unzipping the first file – i.e. that the database directory has been created and that all of the files have been extracted under that directory.

Updating the packages on the Server

Connect to the server, switch to root and update the packages currently on the server
sudo -su apt-get update
Once this is done, reboot the server so we’re sure that all the changes take effect.
# reboot

Getting Required Packages

Connect to the server again and ( as root) download some more packages ( I’ve listed these as one command at a time to make it easier to read) :
sudo su - apt-get build-essential apt-get libaio1 apt-get gawk apt-get ksh apt-get libmotif3 apt-get alien apt-get libtool apt-get lsb-rpm

NOTE – the following packages are also required for the Oracle install, but they were already present on the server :

gcc
make
binutils
rpm

Final Server Preparations

We need to tweak the server environment, setup some users, and create some links.
First off, update the shell ( we’re still connected as root here, hence the # prompt)
cd /bin # ls -l /bin/sh lrwxrwxrwx 1 root root 4 2008-04-28 19:59 /bin/sh -> dash # ln -sf bash /bin/sh # ls -l /bin/sh lrwxrwxrwx 1 root root 4 2008-05-01 22:51 /bin/sh -> bash
Add users and groups
# set -o vi # addgroup oinstall Adding group `oinstall' (GID 1001) ... Done. # addgroup dba Adding group `dba' (GID 1002) ... Done. # addgroup nobody Adding group `nobody' (GID 1003) ... Done. # usermod -g nobody nobody # useradd -g oinstall -G dba -p password -d /home/oracle -s /bin/bash oracle # passwd oracle Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully # mkdir /home/oracle # chown -R oracle:dba /home/oracle #

Create symbolic links
# ln -s /usr/bin/awk /bin/awk # ln -s /usr/bin/rpm /bin/rpm # ln -s /usr/bin/basename /bin/basename

Not entirely sure why we need to do this bit, but I did
# mkdir /etc/rc.d # for i in 0 1 2 3 4 5 6 S ; do ln -s /etc/rc$i.d /etc/rc.d/rc$i.d; done

Create the ORACLE_BASE directory
# mkdir -p /u01/app/oracle # chown -R oracle:dba /u01 #

Now we need to change some config files :
/etc/sysctl.conf – make sure that the following parameters are set to these values. These should all be placed at the end of the file.

fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 1048576
net.core.wmem_max = 1048576
net.ipv4.ip_local_port_range = 9000 65535
fs.aio-max-nr = 1048576

/etc/security/limits.conf – add these settings to the end of the file :

oracle soft nproc 2047
oracle hard nproc 16384
oracle hard nofile 65536
oracle soft nofile 1024

/etc/pam.d/login – add the following line at the end of the file

session required /lib/security/pam_limits.so

In order to make sure that all of these settings had taken effect, I did a reboot at this point :
sudo reboot

Installing the Oracle Software

Now, cross everything, check that you are indeed wearing your lucky underpants…time to do the install.
Start a terminal session on the client and ssh into the and check the setting
ssh -X administrator@server

First, we need to get the value of the DISPLAY variable as we’ll need to set it when we su to the oracle user so that the installer GUI will run on the client ( remember, we have no X-Windows desktop on the server).
echo $DISPLAY localhost:10.0
Now we need to make sure that the server is running in the correct runlevel
sudo runlevel N 2
The last number in the output of the runlevel command is the current runlevel.
The server is currently at runlevel 2, we need it to be at 3 so :
sudo init 3 sudo runlevel 2 3
NOTE – at this point, I opened a separate ssh session on the server and su’d to root on that session, just in case I hit any issues during the installation process. On the fifth attempt to get the install to work this changed into for when I hit issues.

Now we’re ready to fire up the installer.
su – oracle cd /media/database ./runInstaller -ignoreSysPrereqs

After a short pause, you should now see this screen :

Please bear in mind that these screenshots were taken over numerous installation attempts so the step numbers displayed at the top may not match up to what you see. However, the screens themselves should be the same as the ones below.

Oracle Installer - screen 1

Uncheck the I wish to receive security updates via My Oracle Support – if you’re installing on Ubuntu, your doing it for your own research purposes so aren’t going to have paid for Oracle support anyway.
Click Next

Installer Step 2

We’re just going to install the software at this point, so select Install database software only ( as per the screenshot above) and click Next

Installer Step 3

We’ve got enough on our plate just trying to persuade oracle to work on this platform, so let’s keep it simple and just go for Single database installation.
Click Next

Installer Step 4

English (United Kingdom) ? Surely this should read English( Proper, not that strange dialect they use in The Colonies across the Atlantic). Enough of the jingoism, make the appropriate selection and click Next.

Installer Step 5

We’re going for Enterprise Edition. Click Next
Steps 6, 7 and 8 should provide you with default suggestions, which I accepted in each case.

Installer Step 9

This is where it gets a bit interesting. The first time I tried this, I hadn’t set all of the parameters in sysctl.conf and limits.conf to oracle’s liking. Some of these come up as fixable and the Fix & Check Again button is enabled.
If you click this, Oracle will direct you to a script that you can run as root to correct the problems :

Installer Fix Scripts

If you do go down this route, hit Check Again once you’ve run the script(s).
As you can see, the installer complains about a number of things which you can by-pass by checking the Ignore All checkbox in the top left-hand corner.

Note, for the record, oracle complained about the following packages being missing ( which I ignored) :

make-3.80
binutils-2.15.92.02
gcc-3.4.6
libaio-0.3.105
glibc-2.3.4-2.41
compat-libstdc++-33-3.2.3
elfutils-libelf-0.97
elfutils-libelf-devel-0.97
glibc-common-2.3.4
glibc-devel-2.3.4
glibc-headers-2.3.4
gcc-c++-3.4.6
libaio-devel-0.3.105
libgcc-3.4.6
libstdc++-3.4.6
libstdc++-devel-3.4.6
sysstat-5.0.5
unixODBC-2.2.11
unixODBS-devel-2.2.11
pdksh-5.2.14

Once you’re happy, Click Next

Installer Step 10

At this point, I did select Save Response File, just in case I needed to try a silent installation. Fortunately, I didn’t, but it’s probably worth doing, just in case.
Click Finish

Installer Progress

This will take a while, but at least you get a progress bar.
Once it’s all completed, click Next and you get this confirmation

Installer Final Screen

Click Finish
Celebrate with a beverage of your choice…but not too much, we still need to create a database.

Creating a database using Database Configuration Assistant

First of all, we need to get another package. On the server :
sudo apt-get lesstif2

Now we can run the Database Configuration Assistant ( DBCA).
This time, connect to the server as oracle :
ssh -X oracle@server

Make sure that the DISPLAY variable is set. If not, set it to the value it was for the software installation. So, if it was localhost:10.0 for that session then :
export DISPLAY=localhost:10.0 echo $DISPLAY localhost:10.0
now we just need to fire it up :
cd $ORACLE_HOME/bin ./dbca

Just click through the first couple of screens until you get to :

DBCA Screen 3

Hot Tip : when you pick a Global Database Name and SID here, make sure it’s no longer than 8 characters.
If you’re foolish enough to pick one with more characters ( such as orakarmic, to take a completely random example), you’ll find that, when you come to check your new database, it thinks it’s called ORAKARMI, at least, in v$instance.
On reflection, orakoala would probably a better, not to mention fluffier, choice.
Anyway, once you’ve chosen a database name, click Next.

DBCA Screen 4

Uncheck the Configure Enterprise Manager box here. Once again, we want to keep things as simple as possible.
Click Next

DBCA Screen 5

Choose your passwords. Obviously, it’s a good idea to make a note of them at this point !
Click Next through the next few screens until you get to :

DBCA Screen 8

I’d like the sample schemas installed.
Keep clicking next until…

DBCA Screen 11

Click Finish
At this point, you should get a nice screen confirming what dbca is going to do. You should do.
I haven’t got a screenshot of this because dbca popped up a blank screen. I’m not sure whether this was Java having a sulk, or some problem with my setup.
Although nothing was displayed, I managed to get past this screen by randomly clicking in the bottom third of the window until I evidently managed to hit the relevant button…because I then got this screen :

Something's happening but we're not going to tell you what

Yes, it’s supposed to have a prograss bar on it, but all I got was the animated gif. Eventually however, Java decided to behave itself once more and displayed :

Eureka !

Nearly done. One final ingredient required. What’s that you say ? More beer ? Good guess…

Post Installation Configuration

We want to make sure that any sessions we start on this server have the correct environment variables set, so edit /etc/profile and add :

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
export PATH=$PATH:/u01/app/oracle/product/11.2.0/dbhome_1/bin
export ORACLE_BASE=/u01/app/oracle
export ORACLE_OWNR=oracle

Next, we want the database to start when the server boots.

Edit /etc/oratab and change the line :

sid:/u01/app/oracle/product/11.2.0/dbhome_1:N

to :

sid:/u01/app/oracle/product/11.2.0/dbhome_1:Y

where SID is the name of the database you created.

Next, we want to create a script to execute on startup to start the database and the listener :
cd /etc/init.d sudo vi oracledb
The script should be as follows :

#!/bin/bash
#
# Run-level Startup script for the Oracle Listener and Instances
# It relies on the information on /etc/oratab
# Based on script listing at
# http://www.pythian.com/news/1355/installing-oracle-11gr1-on-ubuntu-810-intrepid-ibex/
# Mike 7/3/10
#
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
export ORACLE_OWNR=oracle
export PATH=$PATH:$ORACLE_HOME/bin 

if [ ! -f $ORACLE_HOME/bin/dbstart -o ! -d $ORACLE_HOME ]
then
    echo "Oracle startup: cannot start"
    exit 1
fi 

case "$1" in
    start)
        # Oracle listener and instance startup
        echo -n "Starting Oracle: "
        su $ORACLE_OWNR -c "$ORACLE_HOME/bin/lsnrctl start"
        su $ORACLE_OWNR -c "$ORACLE_HOME/bin/dbstart $ORACLE_HOME"
        touch /var/lock/oracle
        echo "OK"
        ;;
    stop)
        # Oracle listener and instance shutdown
        echo -n "Shutdown Oracle: "
        su $ORACLE_OWNR -c "$ORACLE_HOME/bin/lsnrctl stop"
        su $ORACLE_OWNR -c "$ORACLE_HOME/bin/dbshut $ORACLE_HOME"
        rm -f /var/lock/oracle
        echo "OK"
        ;;
    reload|restart)
        $0 stop
        $0 start
        ;;
    *)
        echo "Usage: `basename $0` start|stop|restart|reload"
        exit 1
esac 

exit 0

Now make the script executable and set it to run at boot time :
chmod a+x /etc/init.d/oracledb update-rc.d oracledb defaults 99

Testing Server Changes

Connect via ssh as oracle, check that the environment variable changes in /etc/profile have been picked up :
ssh oracle@server echo $ORACLE_HOME orakarmic
Now we want to test our script. First off, we need to shutown the database :
export ORACLE_SID=orakarmic sqlplus / as sysdba


SQL> shutdown immediate

SQL> quit
Now connect to the server as the administrator and run the script
ssh administrator@server sudo /etc/init.d/oracledb start
This should start the TNS Listener and the database. To check :
lsnrctl status
The output of this command should include the line :
Service "orakarmic.server" hasd 1 instance(s). Instance "orakarmic", status READY, has 1 handler(s) for this service...
You should also be able to connect to the database via SQL*Plus as before.

If you now reboot the server, you can then verify that both the listener and the database have started correctly :
ssh oracle@server lsnrctl status export ORACLE_SID=orakarmic sqlplus system/password SQL> select status from v$instance;
The query should return a status of OPEN.

Connecting to the database from a client machine

And finally…

The client needs to have an oracle client or similar installed.
There should be a file called tnsnames.ora in $ORACLE_HOME/network/admin.

Simply add an entry for your new database in this file. It will something like this :

ORAKARMIC =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mikeserver)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orakarmic.mikeserver)
    )
  )

You should now be able to connect to the database from the client :
sqlplus system/password@orakarmic


SQL*Plus: Release 10.2.0.1.0 - Production on Sat Mar 13 18:46:37 2010 
Copyright (c) 1982, 2005, Oracle.  All rights reserved. 
Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

I seem to remember someone mentioning beer.

Filed under: Oracle, Ubuntu Tagged: dbca, Install Oracle 11gR2 on Ubuntu 9.10

Project Dependencies Curtailing Your Plans?

OracleContractors - Sun, 2010-03-14 12:55

I thought I would kick off this blog with a confession. I often stay to watch the credits at the end of a film. Sometimes it’s to see the outtakes (often quite amusing…), other times to see the effort that went into the production. Some of those job titles are very creative (e.g., regarding the role titled ‘Best Boy,’ well, what about Best Girl??). After recently watching the credits role in Avatar, I was curious about steps they took to manage project dependencies, in particular given the multitude of production teams.

Thinking about your current project, consider the project dependencies that might cause delays in meeting key milestones. You probably have seen some of these dependencies in your travels. Some are predictable, some take up the time of your limited resources, some lead to scope creep on your project, and others surface during your project out of the blue.

Returning to the Avatar film for a moment, there’s an interesting scene when the main character faces a ‘right of passage’ task. Let’s refer to this mission as his project (and no, I will not give anything away). His task? To ‘bond’ with a flying bird. His ‘sponsor’ informs him just before boarding the bird that he will know he has found the right bird to fly, as this is the one that will first try to kill him. His facial expression says it all. Who could have anticipated this? And not to mention this all took place a top a mountain floating in mid-air? One wrong move, and ……you get the idea. I suspect your project dependencies may be more predictable. Maybe.

When was the last time you evaluated your project’s dependencies and assessed their risk to your project? Consider the following questions -

· How will delays on other projects/initiatives impact your project plan and workload of your resources?

· Has your project board weighed in on the impact of these dependencies?

· Have you introduced sufficient contingency within the project plan?

· Have you considered new dependencies that have surfaced since your project launch, and factored them into the project plan?

Project methodologies introduce tools to track issues and risks, but how frequently do you monitor project dependencies and assess their impact? These risks may not be as choppy as those found when boarding a flying bird for a ride to prove your worth (maybe…), but consider best practices to minimize the turbulence. Define concrete steps to bring them to conclusion, move them forward at each opportunity and monitor throughout the project.

Categories: APPS Blogs

APEX 4.0 - New Features Application and Description

Dimitri Gielis - Sun, 2010-03-14 11:19

If you didn't have time to review APEX 4.0 Early Adopter I and II, but you want to have a quick look what new features will be in APEX 4.0, you can do that now...

There is an APEX 4.0 New Features Application which shows a lot of the new features in action.
e.g. the screenshot below shows the new features for tabular forms in action.

If you want more detail about the new features and when they got introduced (e.g. you reviewed EA1 but want to see what is new in EA2), you can go to the APEX 4.0 New Features Description.

I find it very useful to have something like above.

Categories: Development

Understanding the Sakai Product Council

Michael Feldstein - Sun, 2010-03-14 10:41

If you have never been involved with an open source project, one of the great sources of mystification (and anxiety) for you might be how a group of people spread out all over the world with a wide range of motivations can come together to work on a complex project and produce something coherent and useful. Of course, we know that such things do happen. (For a beautiful illustration of it happening under conditions of extreme lack of visible coordination, watch Jon Udell’s classic analysis of the evolution of a Wikipedia page, Heavy Metal Umlaut.) We know that it can work. But, from the outside, it’s hard to understand how.

The truth is that there is a wide range of governance structures that work for different open source projects, and none of them are particularly mysterious once you come to understand them better. Some projects, like Moodle and Linux, have structures that bear some superficial resemblance to normal management structures in that they have strong central managers who make a lot of final decisions. I say “superficial” resemblance because, in many cases, these managers are acting as part traffic cop and part adjudicator, rationalizing contributions and suggestions for direction from all corners of the community more than they are giving top-down commands.

Other open source projects, like Sakai, take a more distributed approach to management. When they can, they tend to modularize the development so that small groups can work largely independently from each other and can reduce the coordination required to those areas in which their pieces have to work together, either from a technical perspective through integration or from a functional perspective through, for example, common user interface conventions. For those functions where cross-module decision-making has to happen, the community develops mechanisms that look a lot like a representative democracy. In some cases, community members will vote directly on an issue that needs to be resolved. In other cases, they will select representatives to work together in a small group to work through the issues. Just how much (and what kind) of coordination is required depends on a number of factors. Software that has a significant user interface generally requires more coordination than software that does not. Programs where the modules share a lot of technical integration interfaces or services also tend to require more coordination than those that do not. Projects that are in the beginning of their life cycle tend to require more coordination those that are mature.

Over the years, the Sakai community has tried a number of different coordination structures. One of the most recent innovations (and experiments, really) is the Product Council (PC), of which I am a member. What follows here is my own personal meditation on how the PC came about, what function it is attempting to serve and how successful we’ve been at it so far.

(...)
Read the rest of Understanding the Sakai Product Council (1,331 words)

© michael.feldstein for e-Literate, 2010. | Permalink | No comment | Add to del.icio.us
Post tags: Product Council, Sakai, Sakai Product Council, Sakai Project

Partition form updates with partial form submit using af:subform with ADF

Frank Nimphius - Sun, 2010-03-14 06:26

A common application development use case is partial form submit, in which configurable parts of an input form are submitted while others are not. The form submit may be performed on a single page or across views, for example in the course of an entry wizard. ADF Faces provides the af:sub form component to partition input forms for partial submit. By default, the ADF binding layer does not know how to handle partial form submits and instead produce validation errors, unless developers tell it how to. This blog entry is an addition to the af:subform discussion in the Oracle Fusion Developer Guide book by Mc Graw Hill.

[Read more] [Get more]

Frank

Don’t be smart. Never implement a resource bundle cache!

Eduardo Rodrigues - Sun, 2010-03-14 05:09

by Eduardo Rodrigues

Well, first of all, I’d like to apologize for almost 1 year of complete silence. Since I’ve transferred from Oracle Consulting in Brazil to product development at the HQ in California, it’s been a little bit crazy here. It took a while for me to adjust and adapt to this completely new environment. But I certainly can’t complain, cause it’s been AWESOME! Besides, I'm of the opinion that, if there’s nothing really interesting to say, then it’s better to keep quiet :)

Having said that, today I want to share an interesting experience I had recently here at work. First I’ll try to summarize the story to provide some context.

The Problem

A few months ago, a huge transition happened in Oracle’s internal IT production environment when 100% of its employees (something around 80K users) were migrated from old OCS (Oracle Collaboration Suite) 10g to Oracle’s next generation enterprise collaboration solution: Oracle Beehive. Needless to say, the expectations were big and we were all naturally tense, waiting to see how the system would behave.

Within a week with the system up and running, some issues related to the component I work on (open source Zimbra x Oracle Beehive integration) started to pop up. Among those, the most serious was a mysterious memory leak, which had never been detected before during any stress test or even after more than a year of production, but was now causing containers in the mid-tier cluster to crash after a certain period.

After a couple days of heap dump and log files analysis, we discovered that the culprit were 2 different resource caches maintained by 2 different components in Zimbra’s servlet layer, both related to its internationalization capabilities. In summary, one was a skin cache and the other was a resource bundle cache.

Once we dove into Zimbra’s source code, we quickly realized we were not really facing a memory leak per se but an implementation which clearly underestimated the explosive growth in memory consumption that a worldwide deployment like ours has a huge potential to trigger.

Both caches were simply HashMap objects and, ironically, their keys were actually the key to our problem. The map keys were defined as a combination that included client’s locale, user agent and, in the case of the skins cache, the skin name was also included. Well… you can probably imagine how many different combinations of these elements are possible within a worldwide system deployment, right? Absolutely! In our case, each HashMap would quickly reach 200MB. Of course, consuming 400MB out of 1GB of configured heap space with only 2 objects is not very economic (to say the least).

So, OK. Great! We found our root cause (which is awesome enough in this kind of hard-to-analyze-production-only bugs). But now comes the harder part: how can we fix it?!

The Solution

First of all, it’s very important to keep this very important aspect in mind: we were dealing with a source code that wasn’t ours, therefore, keeping changes as minimal as possible was always crucial.

One thing we noticed right away was the fact that we were most likely creating multiple entries in both maps that ended up containing identical copies of a same skin or resource bundle content. That’s because our system only supported 15 distinct locales, which means, every unsupported client locale would fallback to one of the supported locales, ultimately, the default English locale. However, the map key would still be composed with the client’s locale, thus creating a new map entry, and even worse, mapping to a new copy of the fallback locale. Yes, locales and skins that had already been loaded and processed, were constantly being reloaded, reprocessed and added to the caches.

So, our first approach was to perform a small intervention with the only intention to prevent any unsupported client locale from originating a new entry in those maps. Ideally, we would want to change the maps’ key composition but we were not very comfortable with this idea, mainly because we were not sure we fully understood all the consequences of that, and fix the problem causing another was not an option.

Unfortunately, days after patching the system, our containers were crashing with OutOfMemory exceptions again. As we discovered – the hardest way – simply containing the variation of the locale component in the maps’ key composition was enough to slow down the heap consumption but not enough to avoid the OOM crashes.

Now it was time to put our “fears” aside and dig deeper. And we decided to dig in two simultaneous fronts: the skin cache and the resource bundle cache. In this post, I’ll only talk about the resource bundle front leaving the skin cache front to a next post.

When I say “resource bundle”, I’m actually referring to Java’s java.util.ResourceBundle, more specifically its subclass java.util.PropertyResourceBundle. With that in mind, 2 strange things caught my attention while looking carefully into the heap dumps:

Each ResourceBundle instance had a “parent” attribute pointing to its next fallback locale and so on, until the ultimate fallback, the default locale. This means that each loaded resource bundle could actually encapsulate other 2 bundles.
There were multiple ResourceBundle instances (each one with a different memory address) for 1 same locale.

So, number 1 made me realize that the memory consumption issue was even worse than I thought. But number 2 made no sense at all. Why have a cache that is only stocking objects but is not able to reuse existing ones? So I decided to take a look at the source code of class java.util.ResourceBundle in JDK 5.0. The Javadoc says:

“Implementations of getBundle may cache instantiated resource bundles and return the same resource bundle instance multiple times.”

Well, turns out Sun’s implementation (the one we use) DOES CACHE instantiated resource bundles. Even better, it uses a soft cache, which means all content is stored as soft references, granting the garbage collector the permission to discard one or more of its entries if it decides it needs to free up more heap space. Problem solved! – I thought. I just needed to completely remove the unnecessary resource bundle cache from Zimbra’s code ant let it take advantage of the JVM’s internal soft cache. And that’s exactly what I tried. But, of course, it wouldn’t be that easy…

Since at this point I already knew exactly how to simulate the root cause of our problem, I started debugging my modified code and I was amazed when I saw that the internal JVM’s cache was also stocking up multiple copies of bundles for identical locales. The good thing was that now I could understand what was causing #2 above. But why?! The only logical conclusion was, again, to blame the cache’s key composition.

The JVM’s resource bundle cache also uses a key, which is composed by the bundle’s name + the corresponding java.util.Locale instance + a weak reference to the class loader used to load the bundle. But then, how come a second attempt to load a resource bundle named “/zimbra/msg/ZmMsg_en_us.properties”, corresponding to en_us locale and using the very same class loader was not hitting the cache?

After a couple hours thinking I was loosing my mind, I finally noticed that, in fact, each time a new load attempt was made, the class loader instance, although of the same type, was never the same. And I also noticed that its type was actually an extended class loader implemented by inner-class com.zimbra.webClient.servlet.JspServlet$ResourceLoader. When I checked that code, I immediately realized that class com.zimbra.webClient.servlet.JspServlet, which itself is an extension of the real JspServlet being used in the container, was overriding method service() and creating a new private instance of custom class loader ResourceLoader and forcefully replacing the current thread’s context class loader with this custom one, which was then utilized to load the resource bundles.

My first attempt to solve this mess was to make the custom class loader also override methods hashCode() and equals(Object) so they would actually proxy the parent class loader (which was always the original one that was replaced in method service()). Since the web application’s class loader instance would always be the same during the application’s entire life cycle, both hashCode and equals for the custom loader would consistently return the same results at all times, thus causing the composed keys to match and cached bundles to be reused instead of reloaded and re-cached. And I was wrong once again.

Turns out, as strange as it may look at first sight, when the JVM’s resource bundle cache tries to match keys in its soft cache, instead of calling the traditional equals() to compare the class loader instances, it simply uses the “==” operator, which simply compares their memory addresses. Actually, if we think more about it, we start to understand why they implemented this way. Class loaders are never expected to be constantly instantiated, over and over again, during the life cycle of any application, so why make an overhead method call to equals()?

Finally, now I knew for sure what was the definitive solution. I just needed to transform the private instances of ResourceLoader into a singleton, keeping all the original logic. Bingo! Now I could see the internal bundle cache being hit as it should be. Problem solved, at last!

At the end, after having completely removed the custom resource bundle cache implemented in Zimbra’s servlet layer and performed the necessary changes to make Zimbra take full and proper advantage of the built-in bundle cache offered by the JVM, instead of wasting a lot of time and memory reloading and storing hundreds of instances of resource bundles, mostly multiple copies of identical bundles, I could now confirm that despite all different client locales coming in clients' requests, the JVM’s bundle cache was holding no more than those corresponding to the 15 supported locales. With that, we had finally fixed the memory burning issue for good.

Conclusion

As this article’s title suggests, don’t try to be smarter than the JVM itself without first checking whether it’s doing it’s job well enough or not. Always do carefully read the Javadocs and, if needed, check your JVM’s source code to be sure about its behavior.

And remember…. never implement a resource bundle cache in your application (at least if you’re using Sun’s JVM) and be very careful when implementing and using your own custom class loaders too.

That’s all for now and…
Keep reading!

Don’t be smart. Never implement a resource bundle cache!

Java 2 Go! - Sun, 2010-03-14 05:09

by Eduardo Rodrigues

Well, first of all, I’d like to apologize for almost 1 year of complete silence. Since I’ve transferred from Oracle Consulting in Brazil to product development at the HQ in California, it’s been a little bit crazy here. It took a while for me to adjust and adapt to this completely new environment. But I certainly can’t complain, cause it’s been AWESOME! Besides, I'm of the opinion that, if there’s nothing really interesting to say, then it’s better to keep quiet :)

Having said that, today I want to share an interesting experience I had recently here at work. First I’ll try to summarize the story to provide some context.

The Problem

A few months ago, a huge transition happened in Oracle’s internal IT production environment when 100% of its employees (something around 80K users) were migrated from old OCS (Oracle Collaboration Suite) 10g to Oracle’s next generation enterprise collaboration solution: Oracle Beehive. Needless to say, the expectations were big and we were all naturally tense, waiting to see how the system would behave.

Within a week with the system up and running, some issues related to the component I work on (open source Zimbra x Oracle Beehive integration) started to pop up. Among those, the most serious was a mysterious memory leak, which had never been detected before during any stress test or even after more than a year of production, but was now causing containers in the mid-tier cluster to crash after a certain period.

After a couple days of heap dump and log files analysis, we discovered that the culprit were 2 different resource caches maintained by 2 different components in Zimbra’s servlet layer, both related to its internationalization capabilities. In summary, one was a skin cache and the other was a resource bundle cache.

Once we dove into Zimbra’s source code, we quickly realized we were not really facing a memory leak per se but an implementation which clearly underestimated the explosive growth in memory consumption that a worldwide deployment like ours has a huge potential to trigger.

Both caches were simply HashMap objects and, ironically, their keys were actually the key to our problem. The map keys were defined as a combination that included client’s locale, user agent and, in the case of the skins cache, the skin name was also included. Well… you can probably imagine how many different combinations of these elements are possible within a worldwide system deployment, right? Absolutely! In our case, each HashMap would quickly reach 200MB. Of course, consuming 400MB out of 1GB of configured heap space with only 2 objects is not very economic (to say the least).

So, OK. Great! We found our root cause (which is awesome enough in this kind of hard-to-analyze-production-only bugs). But now comes the harder part: how can we fix it?!

The Solution

First of all, it’s very important to keep this very important aspect in mind: we were dealing with a source code that wasn’t ours, therefore, keeping changes as minimal as possible was always crucial.

One thing we noticed right away was the fact that we were most likely creating multiple entries in both maps that ended up containing identical copies of a same skin or resource bundle content. That’s because our system only supported 15 distinct locales, which means, every unsupported client locale would fallback to one of the supported locales, ultimately, the default English locale. However, the map key would still be composed with the client’s locale, thus creating a new map entry, and even worse, mapping to a new copy of the fallback locale. Yes, locales and skins that had already been loaded and processed, were constantly being reloaded, reprocessed and added to the caches.

So, our first approach was to perform a small intervention with the only intention to prevent any unsupported client locale from originating a new entry in those maps. Ideally, we would want to change the maps’ key composition but we were not very comfortable with this idea, mainly because we were not sure we fully understood all the consequences of that, and fix the problem causing another was not an option.

Unfortunately, days after patching the system, our containers were crashing with OutOfMemory exceptions again. As we discovered – the hardest way – simply containing the variation of the locale component in the maps’ key composition was enough to slow down the heap consumption but not enough to avoid the OOM crashes.

Now it was time to put our “fears” aside and dig deeper. And we decided to dig in two simultaneous fronts: the skin cache and the resource bundle cache. In this post, I’ll only talk about the resource bundle front leaving the skin cache front to a next post.

When I say “resource bundle”, I’m actually referring to Java’s java.util.ResourceBundle, more specifically its subclass java.util.PropertyResourceBundle. With that in mind, 2 strange things caught my attention while looking carefully into the heap dumps:

Each ResourceBundle instance had a “parent” attribute pointing to its next fallback locale and so on, until the ultimate fallback, the default locale. This means that each loaded resource bundle could actually encapsulate other 2 bundles.
There were multiple ResourceBundle instances (each one with a different memory address) for 1 same locale.