I have 2 tablespaces which I want to backup when they are in a consistent state (let's say T0). When problems occur (T1), I want to be able to restore both tablespaces to their state at T0 without recovering all changes that occured between T0 and T1 (I want to ignore them all).
What I could do so far is backing up and recovering tablespaces (with changes that occured after the backup, which is not what I want).
I am using Oracle 11gR2 XE and RMAN.
I am looking for a solution compatible with Oracle 10 g and above.
Thank you for your time and help.
I think the best way to do that is transportable tablespace (http://www.oracle-base.com/articles/misc/transportable-tablespaces.php).
You'll transport your tablespace in an empty database before your operation.
After you have to do a full backup on your new database.
If a problem occur during your migration you could do the inverse operation.
Of course, test this solution before!
What about TABLESPACE POINT IN TIME recovery? Would it suit your needs?
PS: It has some prerequisites like NO FKs into tables in other tablespaces.
And maybe it is not allowed in XE releases.
Related
Does Oracle make use of temp tables during backup procedures?
This has brought up many conversations in the break room, but we are limited in our expertise.
I'm pretty sure, please correct me if i am wrong, but to fully qualify for ACID - you need a way to store the data when the database is taken offline, even for a moment.
SQL Server writes to the transaction log, then will catch up after the DB comes back online - but i am not sure if Oracle follows the same idea.
thank you
If you mean with "Backup" that a Tablespace or the whole database is taken to backup-mode with ALTER TABLESPACE tbname BEGIN BACKUP or ALTER DATABASE BEGIN BACKUP the database is not offline but the tablespace resp. the datafiles on the disk are not written into.
This is necessary to prevent a backup of the datafiles in an inconsistent state (fractured block). The blocks changed (called "dirty") during this process are written to the redo-logfile and applied later when ALTER DATABASE END BACKUP is issued.
Backups done with RMAN (Recovery Manager) dont need backup mode at all.
We have a shell script that perform a physical backup of our oracle database (tar + compress of all our database files). Recently, we created a tablespace containing tables that we dont need to backup its contents.
Is it possible to ignore data files relative to this tablespace and have a valid backup?
PS: we don't want to use RMAN.
I preface my remarks here with a note: this is NOT the normative pattern. Normally, we use RMAN to backup ALL the datafiles in the database. With that said...
Yes, it may be possible to restore and recover the database from a backup with a m ssing datafile. But the recovery will require that the tablespace be dropped when the database is restored.
For the simple case of a dropping a tablespace that contains a single datafile: first restore the database files, then:
STARTUP NOMOUNT;
ALTER DATABASE MOUNT ;
ALTER DATABASE DATAFILE '<complete_path_to_datafile>' OFFLINE DROP ;
ALTER DATABASE OPEN ;
DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS ;
Then, continue with database recovery ( RECOVER DATABASE ; )
Obviously, the tablespace_name you provide in the DROP TABLESPACE command would be the one related to the datafile that is dropped.
Obviously, this wouldn't work for the SYSTEM tablespace. And I wouldn't dare try this on other tablespaces like UNDO, SYSAUX, USERS. And there's different syntax for dropping and adding TEMPORARY TABLESPACES.
I don't know of any "gotchas" with the 'DROP TABLESPACE ... INCLUDING CONTENTS', but consider that objects in other tablespaces could be impacted. (Consider that the dropped tablespace might have indexes for tables in other tablespaces, impacts on foreign key constraints, impacts on stored procedures, and so on.)
And it goes without saying, that you would need to test this type of restore procedure in a test environment before you rely on this technique in production.
Without testing, you would be much better served by using RMAN to backup ALL of the datafiles.
NOTE: I have not done anything like this since Oracle 8, possibly Oracle 7.3 (back when we had to roll our own hotbackup scripts). Since we've started using RMAN, I haven't had a need to test anything like this.
NOTE: The RECOVER DATABASE may need to be run before the ALTER DATABASE OPEN. I think you may get an exception warning about "datafile needing more recovery", like you do when you start the database when a tablespace has been left in BEGIN BACKUP mode...
Daily we run mysql dumps on about 50 individual databases, package them up and then store them offsite. Some of these databases are rather large and contain myisam tables (which CANNOT be changed so suggesting it is pointless).. I have been reading up on using the skip-lock-tables option when doing a dump but have not read what the downside would be. All I see are basically different iterations of "it could have adverse effects if data is inserted to a table while it is dumping."
What are these adverse effects? Does it just mean we will miss those queries upon a restore or will it mean the dump file will be broken and useless? I honestly could care less if we lose NEW data posted after the dump has started as I am just looking for a snapshot in time.
Can I rely on these database dumps to contain all the data that was saved before issuing the dump.
--skip-lock-tables parameter instructs the mysqldump utility not to issue a LOCK TABLES command before obtaining the dump which will acquire a READ lock on every table. All tables in the database should be locked, for improved consistency in case of a backup procedure. Even with skip-lock-tables, while a table is dumped, will not receive any INSERTs or UPDATEs whatsoever, as it will be locked due the SELECT required to obtain all records from the table. It looks like this
SELECT SQL_NO_CACHE * FROM my_large_table
and you can see it in the process list with the SHOW PROCESSLIST command.
If you are using the MyISAM engine which is non-transactional, locking the tables will not guarantee referential integrity and data consistency in any case, I personally use the --skip-lock-tables parameter almost always. In InnoDB use the --single-transaction parameter for the expected effect.
Hope this helps.
We have a weekly maintenance plan to shrink all user databases and rebuild their indexes. This has working fine until we created a read-only database, now each time the plan runs it fails when it starts processing this database due to its read only state.
As far as I can see we have two options remove the read only flag from the database, this is possible but as the database is only updated once a quarter it makes sense from a performance point of view to make use of the read-only feature. Or manually select the database that the plan should run for i.e. all the users databases apart from the read only one, this then requires people to remember to add any new databases into the plan.
Does anyone have any suggestions of a better way of doing this?
Thanks
Neil
why are you shrinking the database in the first place?
also there's no need to maintain read opnly db's like that.
I'd remove the read only flag if you don't want to customise the maint plan.
Why are you shrinking DBs too? If the database grows to a given size, then this is probably it's natural current size.
Also remember that an index rebuild (rule of thumb) require free space of 120% of target table size. Eg 500 MB table needs 600 MB free space.
It's pointless to shrink then rebuild... and you'll have horrendous file fragmentation too
I suppose could modify the maintenance plan to start with a 'Execute T-SQL Statement' step, which removes the readonly flag (ALTER DATABASE database-name SET READ_WRITE) and add a final step to reset it:
ALTER DATABASE database-name SET READ_ONLY
I accidentally deleted some rows from the database. But I already have daily database backups.
How can I restore only deleted records from the backup database?
Thanks in advance
You didn't say a database server, so I can't be sure this will work, but I believe the syntax on MSSQL would be:
UPDATE livefile
SET livefile.bloodtypefield=oldfile.bloodtypefieild
FROM [hospital].[dbo].[tblPatientFile] livefile
INNER JOIN [hospitalRapor].[dbo].[tblPatientFile] oldfile on livefile.patientid=oldfile.patientid
I highly recommend running on a test database first to make sure it has the results you want. You will of course need a user who has access to both databases and depending on whether you have triggers etc defined that may take a long time to run on 400k rows.
I take it you have a restore of the database on the same server, in which case assuming all the previous data was correct you could, although you would overwrite any updates to the blood type that have been made since your error.
I would suggest you also backup your 'incorrect' database before you go any further, so that an additional mistakes can be rectified - undone easily so you can at least return to the initial 'error' state instead of compounding problems.