Typ=2 Len=1: 192

the following note/bug is related to http://oradbastuff.blogspot.com/2011/11/ora-07445-intelnewmemcpy382-sigill.html 

Batch Insert Of Data Sometimes Leaves "~" (Tilde) In A Number Field Using The -d64 Parameter In The Command Line [ID 1134992.1]

Applies to:

JDBC - Version: and later   [Release: 11.1 and later ]
Information in this document applies to any platform.


On : version, JDBC for Java

JDBC batch loading size of 5000 results in some rows having "~" char displayed in a NUMBER field. DUMP() shows that value is corrupted ("Typ=2 Len=1: 192").
It was found that the usage of a java VM parameter causes the data corruption.
The JVM parameter is –d64.

From the Sun website:


Specifies whether the program is to be run in a 32-bit or 64-bit environment. On Solaris these correspond to the ILP32 and LP64 data models, respectively. The -d64 option may only be used on 64-bit Solaris systems.

Currently only the Java HotSpot Server VM supports 64-bit operation, and the "-server" option is implicit with the use of -d64. This is subject to change in a future release.

If neither -d32 nor -d64 is specified, the default is to run in a 32-bit environment. This is subject to change in a future release.

Our server AUSSW91 is a Sun Solaris 64-bit operating system. I suspect that the Oracle JDBC drivers have a problem when running in 64-bit mode.

Note that the Oracle database is on 64-bit Linux (OEL), but the java app server is 64-bit Solaris.


The JDK used in production:

java version "1.6.0_04"
Java(TM) SE Runtime Environment (build 1.6.0_04-b12)
Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)

This is the one causing the issue.
It was tested in other machines with newer version and the problem is nor reproduced.


 Upgrade of the JDK 1.6 and all works fine.

Niciun comentariu:

Trimiteți un comentariu