Replication needs archiving?

[greenpiece]

Hi all,

I have a question, hope it's not too trivial.

How do i know if my database needs achiving? i was in charge of this new system of which i don't know the configurations. i only know the following:

1. It is linked to a standby server.
2. i suspect it's a multi-master configuration.
3. select what from dba_jobs give me

dbms_defer_sys.execute(...)
ADM_REPLICATION.restart_replication_queue
do_deferred_repcat_admin(...)

4. archiving has started and archives backup is not needed according to users.

i was thinking of stopping the archiving in order to save disk space but i'm afraid there may be repercussions and affect the link to the standby server. Is there anyway i can check?

Thanks in advance for any reply.

[Jeff Schussele]

Hi,

One question:

Is it going to tape?

No? You're setting yourself up for trouble.

Hot backups are one thing - BUT disks fail - period.
So get *something* on tape or sooner or later it's going to bite you. It's not a matter of IF a disk will fail - it's when!

My 2 cents,
Jeff

[Michael Tully]

Backups are your life blood!
Hardware will fail, you just don't know when.

Backups to tape are essential.

[Jeff Schussele]

Upon reflection. I feel like I should put even more fear into your psyche.
Can you spell HPMC?
I can think of a dozen causes for such off the top of my head that don't even involve disks.
You suffer one of these puppies w/o a tape backup - well....that's cause for dismissal in a lot of shops.
Not a pleasant thought, huh?
Get a hot backup product like BackTrack & then make sure you back up it's results...DAILY!!!

Sorry to be so blunt,
Jeff

[greenpiece]

Hi,
I was thinking of stopping the archiving process now because the disk is getting very full.

The users told me they don't need to backup because they just need 1 initial backup to recover the database back to the initial point, don't have to recover in time. They were told to backup to tape but they haven't been doing so because they think they don't need it.

I know the importance of hot backups but the users just don't need it, they seldom change the data in the database.

My concern now is whether stopping the archiving process will affect the replication that is existing.

[Sanjay Kumar Suri]

A standby database needs archive logs from the primary site for application.

Stopping the archiving process will stop the generation of archive log files in the the primary site and application of them on the standby database.

So your standby database will be badly affacted.

sks

[greenpiece]

Hi,

Oh, i thought for replication, it's pushing of transaction, not archive logs. Pardon me if i'm wrong.

[Duncan Edmonstone]

OK, people are talking at cross purposes here...

Replicated databases and standby databases are two seperate things in Oracle. AAIK replication doesn't really care about archived redo logs, while standby databases do, so:

- If you are using replication
- and you are stopping the database to do a cold backup

Then you don't need to have archiving enabled. You still do need to be doing backups though - a replicated database might save you from a physical corruption (failed disk), but it ain't gonna help when a logical corruption occurs, as all the corruptions will be replicated. So if you want no archive logs generated, you MUST get a good cold backup fairly regularly.

Users are always saying things like 'we don't need any backups', but this is one situation where they should be completely ignored! Protect your job, protect your data.

HTH

Duncan

[Mobeen_1]

Greenpiece,
Let me define couple of terms that you have been using and see if these work the same at your place.

1. Database Replication :-
This is replicating your database from
one server to another. The replication
rules could be defined at various levels
(based on tables.columns etc).

2. Archiving :-
The database archives basically deals
with archiving the database dumps for
a specified time.

As many of our friends have highlighted its certainly preferred that you have your database dumps archived to tape media. Failing to do so may throw up serious issues when you are dealing with server level recovery (you could be fine with object level recoveries). SO PLEASE ARCHIVE not only your database dumps but also your transaction logs at regular intervals and store it on A TAPE MEDIA

I was surprised to see that you mention that your users say a one-time archive is sufficient? If this is the case, is the database that you are running one without any updates ? If that is the case then it makes sense.

I would think that you clarify on these

regards
Mobeen

[R. Allan Hicks]

I'm a little confussed by your question:

Replication can be used for backup and recovery, but generally isn't. Replication does indeed push transactions to remote nodes that used either as a means to distribute the processing load across servers. Replication replicatessome of the database. Usually, the application tablespaces and unless you are really intimate with all of the internal tables in the system tablespace, I seriously doubt if the system tablespace is replicated.

If either system should for whatever reason become a melted pile of rubble, you will have to do a restore from somewhere since advanced replication does not replicate the entire database.

Archive logs (those pesky files that are filling your disk) are you lifeline as someone has already pointed out. Even with replication, you can not recover you system tablespace which is _very_ important since it contains the database data dictionary and tablespace definitions and so on. You must back up your archive logs and move them off the disk. If the disk fills, Oracle will do a "polite wait". That is, the Oracle server will stop runnning and wait for you to make space.

You said "standby database" which may be where my confusion comes in.... Replication is not usually an on-line standy sitiuation although I tried to use it that way when I was replicating. It can be an on-line and report server concept or as I said earlier it can be a multi-master scenario used for load distribution. Standby database is usually used in a dataguard context.

In dataguard, the archive logs are shipped across the network to a stand-by database. A standby database is one that is constantly in recovery mode. In recovery mode, the archive logs changes are rolled forward into the standby database. The object is to keep the two databases relatively synch'ed so that the standby database can become the on-line database in the event of a critical failure of the on-line machine.

Turning off archiving in the dataguard context is the same as turning off dataguard.

Some people (I'm not one of them) feel like since the databases are synchronized by the archive logs, that archive backups are not needed. You can delete the archive logs after they are applied to the standby database if and only if you have _complete_ faith that the archive logs have indeed been applied to the standby database. I for one, would back mine up because I wouldn't want to face management and tell them that the on-line database failed and the standby really wasn't getting backed up.

As to your question of how to know. The easiest method is to use replication manager from enterprise manager to inspect the setup. It will let you look into the job queues and so forth.

As others have pointed out, stopping archiving on a production database is not a real good idea. Archive logs are a pain, because hopefully, they are write only memory. But the day will come when a drive will out and out die, or have a bad spot on it and your system will come tumbling down.
Those users who told you that archiving was unnecessary will be no where to be found. Just like the guy who lays down on his horn to tell you to jump out in traffic won't be around when you get hit.

Also, ask the users who told you that archiving is unnecessary if they have ever messed up a where clause in a delete statement and accidently committed the transaction. With archive logging you can get the data back. With replication, if you are not fast enough, it will be applied to the remote databases and that user may have to consult the pyschic friends network to get the last 6 months of customer invoices.

I strongly recommend that you use RMAN to backup the tablespaces periodically and use RMAN to backup the archive logs with the delete option. Once the archive log is on the tape, RMAN will remove it. I know that this may sound like wearing a belt with your suspenders, and it could be, but you and only you as the DBA are responsible for the safty of the data.

Like the goalie in a soccer match, the ball may have gotten past all of your team mates, but you will be remembered as the one who didn't block the shot.

Life as a dba can be lonely.....

(Sorry I just got back from a backup and recovery seminar and am therefore a little preachy)