OATS 9.1 Oracle XE

Question

Guys
I installed OATS 9.1 on Win2003 and couldn't get the OLT or OTM to work (I was getting a 404 errror so Weblogic had installed but the app wasn't deployed properly). There were loads of errors in the logs about deployment failure and messages like:
Task 0 failed: [Deployer:149026]deploy application oats.ear on AdminServer,oats.
Target state: deploy failed on Server AdminServer
javax.naming.NameNotFoundException: Unable to resolve 'OATS_common_DS'. Resolved ''; remaining name 'OATS_common_DS'
Target state: deploy failed on JMS Server oats
javax.naming.NameNotFoundException: Unable to resolve 'OATS_common_DS'. Resolved ''; remaining name 'OATS_common_DS'
I also was getting ORA-27101 errors
The problem was that ORACLE_HOME wasn't set! Don't know why the install didn't do this?? So I set it to C:\OracleATS\oxe\app\oracle\product\10.2.0\server (Control Panel, System, Advanced, Environment Variables, System)
Hope that helps anyone else who has this problem.
After setting the ORACLE_HOME I just restarted the service using the batch file under the program group

Answer 1

the equivalent of MSSQL Server's detach and move the database filesTransporting tablespaces is similar. SYSTEM cannot be transported, all tablespaces must be completely self contained, i.e. you can't transport just one tablespace containing a table that has an index in a different tablespace unless both tablespaces are included in the the transport set.
Also non-data schema objects- procedures, functions, sequences, etc., those are all stored in SYSTEM so a no-rows export (or data pump) is one way to capture those objects for import at the target.
Its pretty simple as long as schema objects are well placed, especially if you are not migrating to a different OS. The source tablespace(s) are placed in read only mode, the datafiles copied to the target database host, and a data pump (or exp) grabs the object metadata for the tablespace into a dump (export) file. Create all the object owners (schemas) at the target, and import the metadata.
There is a procedure that can be run to check if the desired set of tablespaces are self contained:
exec sys.DBMS_TTS.TRANSPORT_SET_CHECK('DATA,INDEXES[,...]', TRUE);
-- takes a few moments, check for violations:
SELECT * FROM sys.TRANSPORT_SET_VIOLATIONS;
... -- should be no rows selected, if ready for the exp or datapump go for it:
alter tablespace data read only;
alter tablespace indexes read only;
alter tablespace ... read only;
select ts# from v$tablespace where name in ('DATA','INDEXES'[,...]);
... list of ts#
select name from v$datafile where ts# in ( <ts#>,<ts#>[,...]);
... the list of datafiles to copy to targethttp://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/dbxptrn.htm#sthref989