64-bit oracle 10g as CMS for BOEXI R2 SP1

[Ruune]

I did a search on this, and surprisingly it hasnt come up yet. Basicallly, what seems to be happening is that we have an initial development server of BOEXI R2 SP1 installed with the CMS hosted on a Solaris 32-bit oracle 10g server. I have been advised that we are required to move to another server, which is a 64-bit Redhat Oracle 10G server.

The problem arises when I try and change the datasource. If I simply point it to the new server's TNSnames entry (which I can successfully tnsping, plus connect through SQL plus.) The account also has all necessary rights- verified through creating/dropping tables, procedures, and views.

When the server is stopped, I point it to the new TNSnames entry and it fails to resolve the cluster name of the CMS, but it takes the entry. I then try to "recreate the current datasource" to build a blank environment in the new database. This hangs and the whole CCM crashes. Restart, and the CMS service is still stopped. Event viewer indicates "Database failure. Reason ." (real helpful, huh?) The CMS log indicates an OCI call error. That tells me something is screwy with the scripting.

I also tried migrating from oracle server to oracle server to no avail- just hangs. However, migrating from the old (32-bit) to a local (BOEXI server installed) MySQL database, it works w/o a hitch.

After going over this every way I can possibly think of, I thought of adding the "-trace" switch on the cms command line. I then started with the old CMS, shut it down, switched datasources, and attempted to recreate the new CMS from scratch. I let it hang, then went to the CMS log, which showed several lines of SQL being executed with no problems, until it gets to a certain line and returns a datatype mismatch error- got BLOB info for a numeric, or vise versa.

With all that said, BO support is saying that they dont think 64 bit is tested or supported- even though the platforms.txt file says that 10G is supported, without regard to 32 or 64-bit.

So now, I ask- has anyone run into this before, or is anyone else running a 64-bit datasource for their CMS?



These aren't the droids you're looking for.
He can go about his business.
Move along.

 

[Turkbear]

Hi,
One thing to try ( after ensuring that your Oracle client
on the BOE server can connect to the 10g 64bit instance) is to export the CMS schema from the existing server and impport into the new one..then ( after shutting down the CMS service, of course), edit the BOE server's tnsname.ora file to point to the new instance..restart it and see what happens.





To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[Ruune]

yeah- that was actually the first thing we tried. When I did this, all I changed was the hostname (fully qualified w/ domain) in the tnsnames.ora file. Still did the same thing. I should also mention that these two servers are on the same domain and subnet with no firewall between them.

Thanks though...

These aren't the droids you're looking for.
He can go about his business.
Move along.

 

[Turkbear]

Hi,
OK..There may be issues with 32bit client software connecting to the 64bit instance ( there are 2 versions of some Oracle tools because of this) -
One thing to check:
look at the structure of the 2 schemas' tables..they should be the same..

With trace enabled, start the 32 bit one and capture the sql used- do the same with the 64 bit..examine the differences and there may be a answwer...

We have just started building 64bit Oracle servers so I cannot test this yet...





To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[Ruune]

thats interesting... But I dont think it even finishes building the schema.

Also, since there is a solitary client for 32-bit and 64-bit, wouldnt they be called through the OCI in the same manner?

These aren't the droids you're looking for.
He can go about his business.
Move along.

 

[Ruune]

confirmation-
In looking at the table structure, I found the following:

CMS_INFOOBJECTS5- missing SI_KEYWORD, SI_KEYWORDISTRUNCATED, LOV_KEY, OBJNAME, OBJNAMEISTRUNCATED

CMS_RELATIONS5- table is completely missing.

Other than that, the table structure is identical.

When trying to create a new CMS on the 64-bit server (i.e. a blank repository), the last SQL statement that executes is:
SELECT SI_TABLE, SI_HIDDEN_OBJECT, SI_RUID, SI_RUNNABLE_OBJECT, SI_INSTANCE_OBJECT, SI_GUID, SI_CUID, SI_PLUGIN_OBJECT, SI_NAMEDUSER, SI_RECURRING, ObjectID, ParentID, TypeID, OwnerID, LastModifyTime, ObjFlags, UserFlags, ScheduleStatus, NextRunTime, Aliases, CRC, Properties FROM CMS_InfoObjects5 WHERE ObjectID in (4)

The log continues on as follows:
[Fri May 11 17:56:37 2007] 3056 3148 trace message: DBSubSystemOracle::Read: End
[Fri May 11 17:56:37 2007] 3056 3148 trace message: DBQ: Time required to read 1 objects: 8.253004 ms
[Fri May 11 17:56:37 2007] 3056 6060 trace message: <System Subsystem> BuildDefaultObjs: Creating hardcoded default object This APS
[Fri May 11 17:56:37 2007] 3056 6060 trace message: [UID=0;USID=0;ID=4 ] SetObjectInternal(objid=4): Start
[Fri May 11 17:56:37 2007] 3056 6060 trace message: [UID=0;USID=0;ID=4 ] DoFilters(objid=4,type=13)
[Fri May 11 17:56:37 2007] 3056 6060 trace message: [UID=0;USID=0;ID=4 ] Running type 0 filter at 7FD9F72C
[Fri May 11 17:56:37 2007] 3056 6060 trace message: ..[UID=0;USID=0;ID=4 ] DoneFilters(objid=4,type=13)
[Fri May 11 17:56:37 2007] 3056 6060 (.\ObjectSubsystem.cpp:1186): trace message: CObjectSS::AddPlaceholdersToMap: Setting up placeholder in map for Object 4
[Fri May 11 17:56:37 2007] 3056 6060 trace message: [UID=0;USID=0;ID=4 ] SetObjectInternal(objid=4): calling WriteNew
[Fri May 11 17:56:37 2007] 3056 3148 trace message: DBSubSystemOracle::Create: Start N = 1
[Fri May 11 17:56:37 2007] 3056 3148 assert failure: (.\ociwrapper\OCIStatement.cpp:175). (0 : Programmer error: OCI_INVALID_HANDLE).
[Fri May 11 17:56:37 2007] 3056 3148 assert failure: (.\dbssoracle_impl.cpp:3659). (0 : DBSubSystemOracle::Create: End with error).
[Fri May 11 17:56:37 2007] 3056 3148 assert failure: (.\dbssoracle_impl.cpp:489). (0 : ).
[Fri May 11 17:56:37 2007] 3056 3148 Log: level=2 cat=4 msg=33300 p=Database access error. Reason .
[Fri May 11 17:56:37 2007] 3056 3148 Log: level=2 cat=4 msg=33301 p=3


These aren't the droids you're looking for.
He can go about his business.
Move along.

 

[Turkbear]

Hi,
Instead of letting BOE create the CMS database, did you try
try just exporting the schema from the 32bit and importing into the 64bit..Not clear from your last response..





To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[Ruune]

yeah we tried an export from the original, then tried just pointing to the new (64-bit) server after the database was imported, and still couldnt get it to work.

These aren't the droids you're looking for.
He can go about his business.

 

[Turkbear]

Hi,
That error usually indicates a problem with the Oracle environment variable settings..
OracleHome,Library Path etc.
Have you verified all those with the installation notes for 10G 64bit and run all the needed root and Oracle scripts?










To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[Turkbear]

Hi,
also you might want to post this issue in the
Oracle 10G forum here -
it may be a common migration issue that others
have solved ( or not).





To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[Ruune]

I thought of that, but if I can connect through two different clients, using the same connection, it shouldnt be the oracle connection.

Also, from my understanding if the tnsnames entry has a fully qualified domain entry for the host string, it shouldnt matter whats in oraclehome or library path.

These aren't the droids you're looking for.
He can go about his business.

 

[Turkbear]

Hi,
There are more things dependent on the
correct Oracle_Home being set then just the
host name for SqlNet.

Since the CMS creation script is
using the Oracle Call Interface the Library files
are critical and must match the versions being accessed-
The Library path env. variable controls this.

The error message files are located
within Oracle_Home so to get good error messages
it must be set correctly.

That being said, I really suspect
that BOE's code is not 64bit compliant.





To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[Ruune]

my thoughts exactly

These aren't the droids you're looking for.
He can go about his business.