E811 SP1 Platform Pack Installation

Hi,

I'm currently running an E811 SP1 installation on a Solaris 5.9 machine with Oracle 10.1.0.4 DB.

The Database Platform Pack installation takes really long, which is approximately 1.5 days for 1 environment. Does it really take that long? The Database Creation for PS811 itself already takes 13 hours. Normally, when I install it on NT-based system with Microsoft SQL Server, it only takes a couple of hours to load everything. And there are a few Table Load errors ORA-00942, but actually the table is physically there.

Could it be the NLS_LANG conversion? Attached is the DB Load log file for PS811.

E811 SP1 8.95.A1, JJ10187, Win 2003 Deployment Server, Solaris 5.9 Enterprise Server(dedicated), Solaris 5.9 Database Server(dedicated) on Oracle 10.1.0.4, Win2003 JAS Server

You're on to something with the character set conversion. It can take an extended period of time to convert from one character set to another when dealing with the Oracle import process. Your log shows WE8ISO8859P1 as the local character set. WE8MSWIN1252 is the export character set and is the recommended character set for newly created JDE databases on Oracle. I believe the export process for Oracle uses USA7ASCII to further complicate matters.

You didn't mention the hardware configuration - which model of Sun server or workstation are you running? I wouldn't be surprised to see the kind of performance you are experiencing if you are using an older Ultra 5 or 10 workstation with IDE disks. To see that type of performance on a more modern server class machine with fast RAID disk or a SAN connection would imply a serious system bottleneck worthy of investigation.

In my personal experience, changing the local db character set to WE8MSWIN1252 at time of creation reduced the import of OneWorld Xe Central Objects from over 1 day to less than 4 hours. This was specific to my personal HP J5000 running HP-UX and Oracle 9.2.0.4 on SCSI disks in a JBOD configuration. Moving the Oracle datafiles to faster disk won't hurt and on a fibre channel disk based SAN with multipathing you will see very high performance and db creation time in a couple of hours on a slow machine and less on the latest and greatest.

For your reference, I installed 8.11 SP1 platform pack on the HP J5000 listed above in less than 8 hours including the db creation using Oracle dbca utility (the J5000 has dual 440 MHz PA-RISC 8500 processors, 3GB RAM, 72 GB Ultra2 SCSI disks, 10/100 integrated Ethernet and HP-UX 11i with the required patches loaded for Oracle 10g R1)

The DB server is a SunFire V440 UltraSPARC IIIi 8GB RAM running on an MSA box of RAID 5 HDisks. That's why I was very surprised it was running rather slow. Never expected the Lang Conversion to take such a heavy toll on the performance.

The ORA-00942 seems ok. The table is populated and now I'm in the midst of completing the installation. Everythings seems to run in place.

Thanks

WE8MSWIN1252 is a superset of WE8ISO8859P1, so there may have been some conversion (there would be none, if it were the other way around).

In fact, some data may have been corrupt in the process, because some characters in the first set may not exist in the second. In which case, you should probably change it with "ALTER DATABASE CHARACTER SET" to be WE8MSWIN1252.

On the other hand, this conversion is not likely to be the culprit. These sets are too close to have any noticeable effect on the performance of IMPORT - it would typically chew up a bit more CPU in the process, but not really much.

See how the performance goes, once you start using this DB in implementation and production. If I'm correct about the conversion not being the real cause of this issue, then you still have it and it should be visible later on.

ORA-00942 may be a permission issue - if the tables were created without any permissions set and the account used for IMPORT did not have explicit access to the tables set, it may have complained.

Or if the target user did not have the Default Tablespace set, or the Tablespace name was different from the one used in the source database.

In fact, the "Table or View does not exist" may, and probably does, refer to some other system table used in the IMPORT process. Have you cataloged all of the necessary Import/Export views in this database?

Have you got the same patchset (10.1.0.4) on the client?