It is not even difficult and the idea behind was to load them into some email list to send out season greeting to all subscribers. To keep it simple here I will explain it by using a more common wordpress example, but in principle it can be done for any data the same way.

Most email clients are able to import a CSV (Comma separated List of Values) File by default, as also Excel or Access will ‘eat’ them without problems.

Now we have to invoke the MySQL Command Line Client or any other tool which enables us to execute a  SQL Statement hopefully we will ending up with such a prompt:

mysql>

There we first tell MySQL  to work with the specific database in question.

mysql> use DATABASE     (e.q   use wordpress)

With the command desc we can get a field description of our table.

mysql> desc TABLENAME   (e.q.  desc wp_users)

Knowing about the table structure now, with select we can extract the data wished:

mysql> select user_nicename as Name,user_email as Email from wp_users;
+——-+———————+
| Name  | Email               |
+——-+———————+
| admin | admin@localhost.com |
+——-+———————+
1 row in set (0.00 sec)

Seeing the output and being sure about the result will match our needs we are now finally going to spool the query result into a file:

mysql> select user_nicename,user_email into outfile ‘c:/temp/u_emails.csv’ fields terminated by ‘;’ from wp_users;
Query OK, 1 row affected (0.01 sec)

Content of "c:/temp/u_email.csv":

admin;admin@localhost.com

or as variation:

mysql> select user_nicename,user_email into outfile ‘c:/temp/u_emails.txt’ fields enclosed by ‘"’ terminated by ‘;’ from wp_users;
Query OK, 1 row affected (0.01 sec)

Content of "c:/temp/u_email.csv":

"admin";"admin@localhost.com"

And now it should be easy for you to import all emails addresses within your email client’s address book.

RMAN>
run{
…
alter database mount;
…
set until time "to_date(’27.10.2008 23:30:00′,’DD.MM.YYYY HH24:MI:SS’)";
…
restore database;
recover database delete archivelog;
alter database open resetlogs;
}

without rman catalog repository can fail with error:

RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

To solve the issue

• list the incarnation id of the database

RMAN> list incarnation;

using target database control file instead of recovery catalog

List of Database Incarnations

1   1   ORAV10  76765624 PARENT  1         22.11.2007 16:44:40
2   2   ORAV10  76765624 PARENT  4921103   09.04.2008 11:38:07
3   3   ORAV10  76765624 ORPHAN  15854298  27.11.2008 11:43:33
4   4   ORAV10  76765624 CURRENT 15854298  27.11.2008 17:38:11

• set the database in mount status to incarnation id that is fitting to the selected restore time

 
RMAN> shutdown immediate;
RMAN> startup mount;
RMAN> reset database to incarnation 2;

• repeat the database time based recovery

Be careful: Do not restore controlfile. If you do so, incarnation is set the latest id and you run into same error.

RMAN> list incarnation;

List of Database Incarnations

1   1   ORAV10  76765624 PARENT  1         22.11.2007 16:44:40
2   2   ORAV10  76765624 PARENT  4921103   09.04.2008 11:38:07
5   5   ORAV10  76765624 CURRENT 15783824  10.12.2008 16:03:56
4   4   ORAV10  76765624 ORPHAN  15854298  27.11.2008 17:38:11
3   3   ORAV10  76765624 ORPHAN  15854298  27.11.2008 11:43:33

In some cases you get errors during recovery
ORA-00283: recovery session canceled due to errors
ORA-00081: address range [0x60000000000A7D70, 0x60000000000A7D74) is not readable
ORA-00600: internal error code, arguments: [kcvsor_current_inc_rdfail], [0], [], [], [], [], [], []

In this case you have to restore an adequate controlfile created in selected recovery time frame and that has the same incarnation as the datafiles (see also oracle support Note:378273.1)

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.

• 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’;

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.