Oracle archive files are about to bring my production dbase to a grinding halt. The application is depositing one ~100MB .ARC files daily.
How can I compress these .arc files or delete them?
I'm running running Oracle 10.2 with admin privileges.
I work in SQL Server so am out of my comfort zone here.
The backup process will handle your archived log files.
The best tool for the job is RMAN - Oracle Recovery Manager.
This will make your *.arc files go away:
On your host:
$rman target /
# datafiles and archived log files
RMAN>backup database pluss archivelog delete input;
# archivelog files only
RMAN>backup archivelog all delete input;
RMAN>show all; -- inspect the configuration. (Where the backup default is going)
These are redolog file backups, needed to recover the database in case of disk or media failure. You can learn more here:
http://docs.oracle.com/cd/B19306_01/server.102/b14231/archredo.htm
You mention this is a production database, so I assume you generate backups at least once a day. If you use RMAN for your backups, you can use RMAN to purge old or obsolete redolog files, and even set a retention policy to automatically delete obsolete redolog files after some time. You can learn how here:
http://docs.oracle.com/cd/B19306_01/backup.102/b14192/maint003.htm#i1006294
Related
I take a daily backup of my Oracle production database. The backup is created using RMAN and includes control files and archived logs up to the point the backup was taken. For disaster recovery purposes, I want to test the restore of the backup to a new server. (The production database will remain fully operational throughout.)
My question is: when I restore the backup and recover the database on the new server, is it possible to further recover it beyond the archived logs contained in the backup, by using additional archived logs that have been created on the production database since the backup was taken? If so, how would I go about this?
i am learning about backup recovery on oracle. i see the script to backup for both DB and archive log. but i think backup archive log maybe can not use when recovering database. all data change in archive log, which was already backup, it in the backup up DB also.
for exmaple:
i backup DB at 1h00, finish at 2h00
at 2h00, i backup archive log. finish at 2h10
at 4h,DB corrupted, i have to recover DB from DB backup. i think archive log when i backup at 2h00 is not use in that case.
if i incorrect, please correct me. what perpose when we do backup archive log.
An archived redo log file is a copy of one of the filled members of a redo log group. and it must be emptied to create space for the new changes that are constantly happening in your DB. But, If your database is started with archive log mode than before emptying any redo logs it is moved to one of the offline destination files, which is called the archive log.
Archived redo logs are used in case you lost your data due to any situation: DB crashed, data corruption, or any. In such a situation archive logs (from the last backup taken to a time when DB is corrupted) are used. It is described as following with your own example:
DB backup was taken at 2h00
DB corrupted at 4h00
You can use the Good backup that was taken at 2h00 and then use redo logs from archive logs to make all the changes that were happened during 2h00 to 4h00
Your answer: You should take the backup of the archive logs created after the last good backup. All archive logs backup is not needed. and archive log backups should be taken frequently and store it in other than the DB server machine. All the old Archive log backups will be not needed once you take the full DB backup. (You can delete old archive log backup once full DB backup is taken)
You can find more details about the complete recovery of data where archive redo logs are needed from oracle documentation.
How to check that Vertica backup (or database) is in valid state and I can restore database from it without problems?
P.S.
Several days ago I have a very negative experience with Vertica backup: vbr create backups from broken database. When I tried to restore database from such "backup" the vbr utility restore it but I couldn't to start database (Vertica run recovering process and finish it with error). Seems like vbr doesn't check state of database before backup.
As of 7.2.2, vbr can do integrity checks on backups. From the documentation:
A quick check gathers all backup metadata from the backup location specified in the configuration file and compares that metadata to the backup manifest. A quick check does not verify the objects themselves. Instead, this task outputs an exceptions list of any discrepancies between objects in the backup location and objects listed in the backup manifest.
[...] A full check verifies all objects listed in the backup manifest against file system metadata. A full check includes the same steps as a quick check.
The command is:
vbr -t [quick-check | full-check] -c configfile.ini --report-file=path/filename
You can also look at Talena software (my company) if you are interested in granular backup and recovery of your vertica database as well as other databases such as Cassandra, Hadoop, etc.
I've just started a job and have identified an issue in which the database isn't currently being backed up properly so to speak. We are doing one back up every 6 hours that uses the Oracle native backup utility, but we were also sold a process by a company in which they stated that they could in essence perform "warm" backups of our database by simply taking file system copies of our database files and when we needed to restore we'd simply shut down Oracle and then copy over the files that had been copied, restart Oracle and the world would be whole again. The challenge is the fact that we have not gotten this to work just yet. I need to spend some more time reviewing the message that Oracle is giving, but my primary question is, "Is it possible" to take copies of Oracle files while Oracle is still running and to use those files at a later date to restore the database? I know that it works if the database is shut down, and then copies are made, but this is the first that I've heard that a copy (file system) can be made while the database is running. Any guidance would be greatly appreciated. Here is the error that we are getting.
ORA-00314: log 3 of thread 1, expected sequence# 1939 doesn't match 1944
ORA-00312: online log 3 thread 1: 'E:\ORACLE\ORADATA\ITMS\REDO03.LOG'
Yes, it is possible, but you have to put all the tablespaces into backup mode first and take them out afterwards (e.g. ALTER TABLESPACE x BEGIN BACKUP and ALTER TABLESPACE x END BACKUP; you'll need to check the syntax and make sure it's appropriate for your situation!). Oversimplifying hugely, this tells Oracle not to write to any of the data files, so they're all kept in a consistent state.
The two main problems you get otherwise are that individual files are updated while you're copying them so a single file can be corrupted; and more visibly that different files have different internal timestamps and sequences so Oracle won't allow them to be used.
If you're using a process you've bought in then it should already be taking care of all that though. It sounds the backup is OK and it's the restore that you haven't got working.
I haven't been involved in a restore from a hot backup for some time so someone else will need to give the detail on the actual error. My read of it is that you've tried to open with the restored data files but the later live redo logs. When restoring I think you either have to RECOVER the database using the redo logs generated since the backup was taken; or if you're trying to restore to that point in time then you can open the data with the RESETLOGS directive and lose all the changes from all the redo logs that came later. But really take more informed advice than this...
As far as I know, there are two ways that you can "copy" datafiles from a running Oracle instance.
The datafiles are copied for a
tablespace when the tablespace is in
"BEGIN BACKUP" mode.
You are using a high-end journalling
filesystem such as Veritas that can
snapshot and track block
changes on the filesystem while the
copy is taking place.
It is possible. You must must be in ARCHIVELOG mode.
An example script would be for manual:
Alter tablespace USERS begin backup;
host cp -p /u02/oradata/PROD/users01.dbf /u03/backup/PROD/
host cp -p /u02/oradata/PROD/users02.dbf /u03/backup/PROD/
Alter tablespace USERS end backup;
However, I would recommend just using RMAN. RMAN is QUITE ROBUST, included free, and will do the hot backup, as well as cold. It will clone to another instance, clone as a point in time, recover to a certain point in time, etc. Any manual backup procedure should be migrated to using the RMAN.
If you wanted to backup the entire database while it is open (I prefer as Oracle with DBA so you can avoid passwords in scripts, but ymmv):
$ ORAENV_ASK=NO
$ ORACLE_SID=PROD
$ . oraenv
$ rman target=/
Recovery Manager: Release 10.2.0.4.0 - Production on Thu Oct 28 14:23:29 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: PROD (DBID=x)
RMAN> backup as compressed backupset database plus archivelog;
...
Backup Complete.
I've effectively done this with a non-mission-critical database running on Amazon EC2. My backup strategy is to periodically take a snapshot of the EBS volume. To restore a backup, I create a new EBS volume from the snapshot, start up the instance using it, then run RECOVER DATABASE.
This loses any transactions that were in-flight at the time when the snapshot was taken, of course.
I would like to backup an Oracle 10G as simple as possible.
It is in NOARCHIVELOG mode and I can shut down for backup (it is only a development server).
After reading tons of documentation abour rman I tried this way in rman:
shutdown immediate;
startup mount
backup database;
sql 'alter database open';
As I see it works fine, list backup shows backups.
Than I made some modifications (droping some tables, adding data) and I tried to restore backup:
shutdown immediate;
startup mount
restore database;
recover database;
sql 'alter database open';
It also seems to work fine but I can't get back the previous state of the database. I don't understand why. I also don't understand why need to use recover.
Thanks
Hubidubi
The "restore database;" command will read the backup from the backup media media so that your database files are exactly like they were when the last backup was taken. It does not restore control files.
The "recover database;" command will apply incremental backups (not applicable - your example only has a full backup) and apply archive logs (also not applicable, you're in "NOARCHIVELOG" mode.) It may also write to the control files - if it does, you can see why it's required.
After the restore/recover/open commands you issued in your question your database is as it was at the time of the backup. Any transactions committed after the backup are lost and can't be recovered because you're in "NOARCHIVELOG" mode. You need to be in "ARCHIVELOG" mode to do a complete "point in time" recovery.
byw, what files, if any did you delete, rename or move to really simulate a true media failure? I'll bet you didn't delete one of your control files. You need to practice that scenario.