Sometimes I wish that there was just one language and therefore just one keyboard.
I'm working in Belgium right now and at this customer there is no possibility to use my laptop on the network. Instead they have a thin client concept based on Citrix. That is ok but working with a Belgian keyboard just makes my hands hurt.
I have switched the locale to English. But now I have to convince my eyes that there are different keys.
Also after locking the PC I mistyped my password too often (the Citrix environment was still on FR) so the helpdesk had to unlock my account.
I have not yet done Oracle related work on this machine but I cannot imagine what will happen when doing some interessting stuff with the DB or the Application Server and entering $#@%^& instead of some numbers or terminating each command with an m (that's where they've put the semicolon).
Saturday, September 22, 2007
Tuesday, September 18, 2007
Differences between the standalone OHS and the AS OHS
In my previous post http://achatzia.blogspot.com/2007/09/stand-alone-oracle-http-server-vs-as.html I said that there are two separate code trees for the OHS.
Now I found at least one difference. If you have a look at the mod_oc4j.conf file you will see that the standalone version includes
LoadModule oc4j_module modules/mod_oc4j.so
while the AS version does include
LoadModule oc4j_module modules/ApacheModuleOc4j.dll
This of course is the Windows version. If somebody wants to check if such a difference exists with a Unix version I would like to hear that as well.
Now I found at least one difference. If you have a look at the mod_oc4j.conf file you will see that the standalone version includes
LoadModule oc4j_module modules/mod_oc4j.so
while the AS version does include
LoadModule oc4j_module modules/ApacheModuleOc4j.dll
This of course is the Windows version. If somebody wants to check if such a difference exists with a Unix version I would like to hear that as well.
Friday, September 07, 2007
Stand alone Oracle HTTP Server vs AS 10.1.x OHS
I just learned the following, which I wanted to share with you.
One reason for using the 10.1.3.3 HTTP Server rather than the companion cd - Apache 2.0 - version is that no generic patchsets are ever issued for the Apache 2.0 version. It means that the MOD_OC4J component which comes with the 2.0 version always stays the same and neve
r receives any bug fixes. You can also more easily configure the base 10.1.3 HTTP Server as part of an OracleAS 10.1.3 cluster topology.
I had the idea that a stand alone OHS in the web tier (e.g. in the DMZ) would be a better setup as there are less points to attack, especially as there is a direct exposion to the Internet.
I'll try to switch to the AS 10.1.3.x version instead of the stand alone OHS to see if this solves my problem.
However I do not understand why Oracle keep different patch regimes with their software when they should share the same code base?
One reason for using the 10.1.3.3 HTTP Server rather than the companion cd - Apache 2.0 - version is that no generic patchsets are ever issued for the Apache 2.0 version. It means that the MOD_OC4J component which comes with the 2.0 version always stays the same and neve
r receives any bug fixes. You can also more easily configure the base 10.1.3 HTTP Server as part of an OracleAS 10.1.3 cluster topology.
I had the idea that a stand alone OHS in the web tier (e.g. in the DMZ) would be a better setup as there are less points to attack, especially as there is a direct exposion to the Internet.
I'll try to switch to the AS 10.1.3.x version instead of the stand alone OHS to see if this solves my problem.
However I do not understand why Oracle keep different patch regimes with their software when they should share the same code base?
Thursday, September 06, 2007
11g on Oracle Enterprise Linux
I thought that using the Oracle Enterprise Linux for the 11g would be a pretty cool idea.
Actually the installation experience is not different from a normal RH ES version. I would have thought that a couple of necessary packages were already included (unixODBC, libaio, etc) but I guess that this is the age-old problem of having the OS out there for some time when the software (DB) is still in development.
It would be awesome if Oracle would come up with a intermediate release of the OEL when they bring out a new version of the DB or the AS (yes I like to daydream :-)
When installing the software no issues were detected. However when I build the Database (dbca) it seemed to hang at 45%. I retried three times (sample schemas on/off). Then I left it running while I was having lunch. And guess what: it just takes a little bit longer. So when installing 11g just bring a little bit of patience with you.
Actually the installation experience is not different from a normal RH ES version. I would have thought that a couple of necessary packages were already included (unixODBC, libaio, etc) but I guess that this is the age-old problem of having the OS out there for some time when the software (DB) is still in development.
It would be awesome if Oracle would come up with a intermediate release of the OEL when they bring out a new version of the DB or the AS (yes I like to daydream :-)
When installing the software no issues were detected. However when I build the Database (dbca) it seemed to hang at 45%. I retried three times (sample schemas on/off). Then I left it running while I was having lunch. And guess what: it just takes a little bit longer. So when installing 11g just bring a little bit of patience with you.
Flashback Recovery Area full
Ok, I promise I will take more time to read things like manuals and other documents when it comes to new features in the database.
Take the Flashback Recovery Area (FRA). Oracle does store archive logs in there, which is cool as it speeds up the recovery. The bad thing is that the Oracle Database behaves like a small child. When you do not look it will do strange things.
So I was busy setting up the online backup of an infrastructure database. This one is still in 10.1.x while all the others in this environment are on 10.2.x .
For the RMAN I have a catalog (also 10.2.x) so I had some problems with the versions as the 10.1.x database refused to get into the 10.2.x RMAN catalog. I thought that I have plenty of space for the archivelogs in the ASM (everything was RAC of course).
I turned my attention to some other issues (aka not watching your kid for a moment). Then during an important demo for the client a developer told me that he cannot use the OID.
Of course I checked, but the OID was running, and the database was running as well (ps -ef | grep smon) . Ok, a quick look at the alert.log showed that the database was struggeling with ORA-19815. Apparently the archive log destination was full.
I checked with the ASM which I had cleaned up a day before. Still 30% free?!?!
Metalink revealed that the FRA was full. Now Oracle has done everything to shield the FRA from direct access. This means that I had to get rid of the archivelogs in the FRA with RMAN.
However I still wanted to use the available catalog. Finally I decided to have one backup with RMAN (10.1.x) without the catalog. As the database was already in limbo I went to some drastic measures:
- shutdown abort
- startup
- shutdown immediate
- startup mount
- alter database flashback off;
- alter database open;
Then I tried to set the db_recovery_files_dest_size to a lower value in order to trigger the cleanup process.
- alter system set db_recovery_files_dest_size=1G scope=both;
I also changed the db_flashback_retention_target from 1440 minutes t 120 minutes.
- alter system set db_flashback_retention_target=120 scope=both;
Obviously this did not help because the v$recovery_file_dest still showed that I had 0 bytes of reclaimable_space and 267 files in the FRA.
So now I took the non-catalog RMAN with a deletion of the archive logs. When doing this the FRA is cleaned up as well.
So everything was working again and nobody in the demo was aware of this (the infra is just used for some specific logins that were not used).
Conclusion: Databases behave like little kids, always be aware what they are doing. Fortunately there are manuals for the Database ;-)
Take the Flashback Recovery Area (FRA). Oracle does store archive logs in there, which is cool as it speeds up the recovery. The bad thing is that the Oracle Database behaves like a small child. When you do not look it will do strange things.
So I was busy setting up the online backup of an infrastructure database. This one is still in 10.1.x while all the others in this environment are on 10.2.x .
For the RMAN I have a catalog (also 10.2.x) so I had some problems with the versions as the 10.1.x database refused to get into the 10.2.x RMAN catalog. I thought that I have plenty of space for the archivelogs in the ASM (everything was RAC of course).
I turned my attention to some other issues (aka not watching your kid for a moment). Then during an important demo for the client a developer told me that he cannot use the OID.
Of course I checked, but the OID was running, and the database was running as well (ps -ef | grep smon) . Ok, a quick look at the alert.log showed that the database was struggeling with ORA-19815. Apparently the archive log destination was full.
I checked with the ASM which I had cleaned up a day before. Still 30% free?!?!
Metalink revealed that the FRA was full. Now Oracle has done everything to shield the FRA from direct access. This means that I had to get rid of the archivelogs in the FRA with RMAN.
However I still wanted to use the available catalog. Finally I decided to have one backup with RMAN (10.1.x) without the catalog. As the database was already in limbo I went to some drastic measures:
- shutdown abort
- startup
- shutdown immediate
- startup mount
- alter database flashback off;
- alter database open;
Then I tried to set the db_recovery_files_dest_size to a lower value in order to trigger the cleanup process.
- alter system set db_recovery_files_dest_size=1G scope=both;
I also changed the db_flashback_retention_target from 1440 minutes t 120 minutes.
- alter system set db_flashback_retention_target=120 scope=both;
Obviously this did not help because the v$recovery_file_dest still showed that I had 0 bytes of reclaimable_space and 267 files in the FRA.
So now I took the non-catalog RMAN with a deletion of the archive logs. When doing this the FRA is cleaned up as well.
So everything was working again and nobody in the demo was aware of this (the infra is just used for some specific logins that were not used).
Conclusion: Databases behave like little kids, always be aware what they are doing. Fortunately there are manuals for the Database ;-)
Subscribe to:
Posts (Atom)