Again let's talk about backups. There are two types of backup:
• Saying backups cold. In this case the base is inaccessible to users and it performs a simple file copy appropriate to restore in case of trouble.
• The hot backup. Aurrez you understand, it is a backup open database while user continues to work on their preferred base. It is usually this type of configuration found in production mode or can not afford to stop a database to save.
However, in some cases (Bureau study, Publisher, test environment, ..) it may be desirable to set up a backup strategy without it becoming too complicated.
Again, a bit of thought before acting will save time later and avoid crisis situations.
Start from the premise that the base is large and arrange for any table contains many columns of type CLOB.
Notes: The table imports with CLOB columns are very long, because processed line by line.
Solution 1: export for backup / import for restoration.
Compared our case study, it may be possible but may take considerable time.
So in case of data loss, restoration can be problematic:
• Duration of import / export relatively long.
• In panic mode, we do not think at all. And you can forget, for example to create tables containing CLOB (if you still use the utility imp.exe) to redirect tablespace (impdp.exe), and probably other issues that do not come to mind.
Solution 2: Stopping the base, and all copies of the database file or from a tape backup location.
So to restore, just stop again and copy the database files.
As everyone knows, database administration and recovery tests in most editors are a high priority. (Irony -)). So when restoring the probality missing a data file is quite high and hit the restoration of your database becomes more complicated.
I suggest you stop the "DIY" and uses this ORACLE kindly put at our disposal.
I am willing to nominate Recovery Manager (RMAN).
To restore, it is necessary to have a backup.
Before effecuter it, you connect yourself with a test user and create some tables and fill.
Unless you (which should be the case) schemes with applications you need.
Step 1:'s perform a cold backup database:
Start> Run> cmd
sqlplus / nolog
CONNECT / AS SYSDBA
SHUTDOWN IMMEDIATE;
QUIT
RMAN target /
RMAN> STARTUP MOUNT;
RMAN> BACKUP DATABASE FULL;
RMAN> ALTER DATABASE OPEN;
RMAN> QUIT
Note: Throughout this example, we see that RMAN has authority to stop or start a base!
Step 2: Returning in SQL PLUS
TRUNCATE TABLE T1;
DROP TABLE T3;
sqlplus / nolog
SQL> CONNECT LAO / LAO - (this is my test with three user table t1, t2, t3. Original?)
Whoops! I wanted to do the opposite!
Quickly go into panic mode;
SQL> CONNECT / AS SYSDBA
SQL> SHUTDOWN IMMEDIATE;
And while my database is stopped, a colleague of goodwill deletes files related to SYSTEM tablespace (which of course were not saved) ==> laws MURPHY (maximum pain in the ass).
You can always go with your dump!
Step 3: stop the panic and remembered that we had taken the time to think to solve this kind of problems.
Start> Run> cmd
SET ORACLE_SID = oradb (if ever there are several bases on your computer).
RMAN target /
RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE;
.... If all goes well, a little message that says "End of restore in DD / MM / YY"
RMAN> QUIT
Just a little effort,
sqlplus / nolog
SQL> CONNECT / AS SYSDBA
SQL> RECOVER DATABASE UNTIL CANCEL;
The insults you receive some of our friend ORACLE.
Simply type without trembling and then CANCEL
SQL> ALTER DATABASE OPEN RESETLOGS;
Oh and magic, a message saying "Database changed"
Let's crazy!
SQL> CONNECT LAO / LAO
Maintanant and you can check! the tables are all the, and with the same number of lines at the time of backup.
Conclusion: This method is the same that the proposed solution number 2: one small detail is that RMAN handles for you to know which files to backup and especially where they are!
