A short memo about the procedure to change LATIN1 to LATIN2 code page in Oracle XE (I can’t remember where I originally found this tip, probably somewhere on OTN!?):

1) Make sure you download and install Oracle XE (Western European) version of XE (single byte character set) and not Universal (Unicode)

2) change the database character set to EE8MSWIN1250:

cmd> sqlplus /nolog
sql> connect / as sysdba 
sql> SHUTDOWN IMMEDIATE;
sql> STARTUP MOUNT;
sql> ALTER SYSTEM ENABLE RESTRICTED SESSION;
sql> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
sql> ALTER SYSTEM SET AQ_TM_PROCESSES=0;
sql> ALTER DATABASE OPEN;
sql> ALTER DATABASE CHARACTER SET INTERNAL_USE EE8MSWIN1250;
sql> SHUTDOWN;
sql> STARTUP RESTRICT;
sql> SHUTDOWN;
sql> STARTUP; 

That’s it. Now, you have Oracle XE with EE8MSWIN1250. This can be useful if you want to support old clients (for example Oracle Forms) that doesn’t recognize AL32UTF8 code page that is used in Universal distribution.

Oracle made two silly mistakes when 10g was released:

1. they put JAccelerator NCOMP (Java Native Compiler) component on Companion disk. Put mandatory component of the database on Companion disk and just wait for the flow of the Service Requests – and Oracle Support got the “feedback” from customers who overlooked the requirement to install this mandatory component from Companion disk.

They learned the lesson and corrected a mistake in Oracle11g where JAccelerator is installed at the time database SW is installed (you may argue that JAccelerator is really not a mandatory component in 10g…this is only true if you run database without JVM. Do you support any such db?;-).

2. second silly decision is really an old story – I don’t know who is the genius behind the idea to not let us choose which component we would like to install with OUI. We had to install tons of demo stuff just to get JAccelerator component on our server, followed by de-installation of components that we don’t need. If I choose “Custom Installation” I want control of what will be installed and what not – please, don’t treat me like an idiot.

Now, it’s time for a confession :-). Today (before I got necessary dose of caffeine), I was too quick while preparing test installation of Oracle 10.2.0.3 – after I finished installation of 10.2.0.1 base release, I patched this version with Patchset 10.2.0.3. In the middle of 10.2.0.3 installation, it struck me that I forgot to install JAccelerator. Fortunately, I was installing Oracle SW without the database, so the fix was easy after 10.2.0.3 installation finished:

1. I installed JAccelerator from 10.2.0.1 media
2. then re-installed 10.2.0.3 patchset. OUI will display additional panel, if detects that some components are already patched, showing all the installed components and you can browse the tree and check that only JAccelerator will be patched from 10.2.0.1 to 10.2.0.3.

I’m not quite sure, what would be the exact procedure if you installed JAccelerator after database was already created without it (JVM loaded without NCOMP). I guess JVM needs to be reloaded (see Metalink 276554.1 “How to Reload the JVM in 10.1.0.X and 10.2.0.X”)– not for the faint of heart!

Regards,
Ales

For quite some time we observed dead client connections on some of our production servers (in all cases: 32-bit Oracle10g 10.2.0.2, Windows 2003 SP1). We turned dead client detection ON by setting up SQLNET.EXPIRE_TIME in sqlnet.ora on the server side, trying different values (5, 10, 15 minutes). Despite of that, we noticed that DCD doesn’t work for no apparent reason. We confirmed that by tracing the session according to Metalink Note 1019019.102 “How to Check if Dead Connection Detection (DCD) is Enabled”. It was during this search on Metalink that we found out about Bug #5573896 “DCD IS NOT WORKING IF SET MORE THAN 1 MINUTE”. After setting SQLNET.EXPIRE_TIME=1 the problem with dead client connections disappeared – well, better said the problem was not as severe, as before we changed EXPIRE_TIME to 1 minute. Occasionally, we still find dead connections that Oracle doesn’t recognize as dead connections. According to Metalink note it’s a platform specific bug – it’s not known yet when’ll be fixed.

So far we found out that:
– this is the problem with Oracle 10.2.0.2/10.2.0.3 on Windows 2003 / XP
– we could not reproduce the problem running Oracle 10.2.0.2 on Windows 2000 (SP4)
– it doesn’t seems to affect Windows 2003 EMT64*

[Comment added, 2 November, 2007]
* Actually, it does affect Windows 2003 EMT64 as well. Last week we put in production Oracle 10.2.0.3 (+Patch 12) on 64-bit Windows 2003 EE with SP2. After a week in a production we noticed dead client connections as described above.

Regards,
Ales