Since Oracle Version 10G ist is possible to transfer tablespaces no longer only between platforms of the same architecture. Now in 10G it also possible to transport from any platform to any platform, provided the platforms belong to the list below:

SQL>  select * from v$transportable_platform;

   PLATFORM_ID PLATFORM_NAME                    ENDIAN_FORMAT
  
             1 Solaris[tm] OE (32-bit)          Big
             2 Solaris[tm] OE (64-bit)          Big
             7 Microsoft Windows NT             Little
            10 Linux IA (32-bit)                Little
             6 AIX-Based Systems (64-bit)       Big
             3 HP-UX (64-bit)                   Big
             5 HP Tru64 UNIX                    Little
             4 HP-UX IA (64-bit)                Big
            11 Linux IA (64-bit)                Little
            15 HP Open VMS                      Little
             8 Microsoft Windows IA (64-bit)    Little
             9 IBM zSeries Based Linux          Big
            13 Linux 64-bit for AMD             Little
            16 Apple Mac OS                     Big
            12 Microsoft Windows 64-bit for AMD Little

But be aware that depending on which plattforms we deal with there might be some converting necessary or not!

To help you with that, I have carried together the little cook book about “How to do” below:

1. Set the tablespace to READ ONLY

SQL> alter tablespace USERS read only;
Tablespace altered. 

2. Export metadata

exp userid=\’/ as sysdba\’ transport_tablespace=y
tablespaces=users
file=users_tts.dmp log=exp_users_tts.log
statistics=none

3. Converting tablespace if necessary

Depending on we have to convert the file between endianness Little and endianness Big (forward or backward) we can do that with RMAN:

rman target=/

Recovery Manager: Release 10.2.0.3.0 – Production on Wed Dec 10 13:10:57 2008
connected to target database: orav10 (DBID=1953618181)

RMAN> convert tablespace ‘USERS’
2>  to platform=”Linux IA (32-bit)”
3>  db_file_name_convert=’/database/orav10/datafiles/users.dbf’,
4>  ‘/tmp/users.dbf’;

4. Move datafiles and export dump file

$ftp users_tts.dmp

and /database/orav10/datafiles/users.dbf (no conversion)
or /tmp/users.dbf (converted file if conversion had been required)

5. Import metadata

imp userid=\’/ as sysdba\’ TRANSPORT_TABLESPACE=Y
datafiles=/database/orav10/datafiles/users.dbf
(or /tmp/users.dbf )
file=users_tts.dmp log=imp_users_tts.log

6. Set the tablespace to READ WRITE

SQL> alter tablespace USERS read write;
Tablespace altered.

Working with the Oracle Flashback option we can restore the old data using flashback queries. Introduced in Oracle Version 9.2 the “AS OF” clause can be used to:

• find the old data
• restore the old data

Mistakenly set the salary of Manager King to a wrong value:

SQL> update emp set sal=4500 where ename=’KING’;
1 row updated.
SQL> commit;
Commit complete.

SQL> select ename, sal from emp where ename=’KING’;
ENAME             SAL
———- ———-
KING             4500

We can query the old value again using the “AS OF” clause and specifying a time interval:

Issuing this query will tell us the correct value as it was existing 15 minutes before.

SELECT ename, sal FROM emp
AS OF TIMESTAMP (SYSTIMESTAMP – INTERVAL ’15’ MINUTE)
WHERE ename = ‘KING’;

ENAME             SAL
———- ———-
KING             5000

Now we can use flashback query as a sub query in an update statement to restore back to the old value. The command is as follows:

update emp
set sal = (
SELECT sal FROM emp
AS OF TIMESTAMP (SYSTIMESTAMP – INTERVAL ’15’ MINUTE) where ename=’KING’)
where ename=’KING’;

In case you are going to use this for testing purposes, you might find it usefully to record the referencing SCN and use flashback query in combination with the recorded SCN.

SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
————————
                 4312233

Now changing a value on purpose:

SQL> update emp set sal=4300 where ename=’KING’;
1 row updated.

SQL> commit;
Commit complete.

SQL> select ename, sal from emp where ename=’KING’;
ENAME             SAL
———- ———-
KING             4300

Then you might not know the previous salary of MILLER but you do know the SCN when it refered to the old value and the original value can be updated and restored with flashback query by using the SCN noted prior to the update statement.

Here is the required query:

SELECT ename, sal FROM emp
AS OF SCN 4312233
where ename=’KING’;

ENAME             SAL
———- ———-
KING             4300

And you can restore the old value by updating the row or better you directly restore the old value using the following update with flashback sub query:

update emp
set sal = (
SELECT sal FROM emp
AS OF SCN 4312233 where ename=’KING’)
where ename=’KING’;

Oracle’s BI Publisher which is part of the Oracle Business Intelligence Suit has at least within Enterprise Computing environment established as a reliable and preferable choice when it comes to replace the somewhat aged Oracle Reports.

Once being familiar with it you will ask yourself about why switching tool when it comes to the need of creating reports in a normal web design world mostly using MySQL Databases within a “LAMP” environment.

Written as an universal reporting tool BI Publishes does offer us a more or less universal data interface based on JDBC connections. And being able to act itself as a callable web service offering WEBDAV services based on XML data exchange it anyway seems to be an excellent choice for this world.

Already Oracle’s installation instructions does give you a quick idea about setting up BI Publisher working against some MySQL Database. But acting  in a Web environment you might find it cool integration the BI Publisher within an already existing Apache Tomcat environment and for exactly this environment I will give you a short explanation about getting things together and ready for work.

First we will pick the BI Publisher software itself by copying the xmlpserver.war file from the distribution DVD and throwing it into the webapps folder of our Apache Tomcat. Waiting a few seconds until the self-deploying mechanism of the Apache Tomcat has extracted the files for us, we need to specify the access path to our project and development repository within the file xmlp-server-config.xml.

Having done that, we need to add the MySQL JDBC driver to our system and making it known within the environment of the Apache Tomcat. (The MySQL JDBC driver can be downloaded from: http://www.mysql.com/products/connector/j/.)

So with the downloaded fileready, we have to extract it to any place we like onto our disk. Just I would recommend you to put it somewhere close to your MySQL installation for you being able to later on remember it again. Finally extracted and ready to use, we have to add the information about the mysql-connector-java- -bin.jar file to the Java Classpath of the Apache Tomcat and finally restarting it:

Having this set, as a last step we have to invoke the BI Publisher itself, in which we then will configure the new JDBC data source within the Admin region of it:

And now with this tweaking ready, MySQL DB should connect, open and work for you like a charm.