Networker Module for Oracle backup of index fails

[tilleyk]

I've created an RMAN script to do a full backup of my Oracle database. I can run the script successfully from the command line, but when I run the script from the client save set in nwadmin it fails.

It actually completes the database backup to the pool database but once it completes the database backup it tries to write the index to the default pool. The backup eventually fails when it times out trying to write the index to tape. There are no error messages, but the following messages are displayed:

"Done saving to pool database"
"media info:labeling a new writable volume for pool Default"
"waiting for 1 writable volumes to backup pool Default tape"

In the Group Control window the following displays:
"index failed"
"index aborted due to inactivity"

There are volumes labeled for both the Default and Database pools. I'm stumped.

 

[605]

I think you get confused by the pool names. You obviously have a pool 'Default tape' which is not the same as 'Default'.

Please check again and correct, if necessary.

 

[tilleyk]

My output messages that I quoted were incorrect. They were "waiting for 1 writable volumes to backup pool Default".

I double-checked. All the pools are labeled either Default or database. When I checked the Default volumes, they were all marked full, so I went back and marked the ones that weren't full to appendable.

Now when I try the backup again, it completes the database volume without any problem but then when it tries to backup the index, it mounts a Default volume and tries to write to it. Here are the messages when it mounts the Default volume:

"setting up for writing, moving forward 34 files"
"media warning:/dev/rmt/1mbn moving:fsf 34:I/O error"

It couldn't write to this volume so it timed out and mounted another Default volume and it did the same thing and eventually failed.

"setting up for writing, moving forward 9 files"
"savegroup alertatabase completed, 1 client failed"

Why is it trying to write to a Default volume rather than a database volume in the first place?

What would happen if I run the Database group with the No index save option? Would I be able to recover?

 

[605]

1. It tries to write to the pool 'Default' because of your pool setup.

We don't know your parameters but most likely you will use the 'client' which is wrong in this case. Do not forget that the 'Index and 'Bootstrap' backups belong to the NW server's client and not to any other (database) client.


2. With 'No index save' you will of course be able to recover, but it will be more complicated. How, depends on what you exactly need during the recovery process.

3. It seems that you have a problem with one of your tape drives. That's the obvious reason for the positioning error.
If this happens during writes, NW will mark the media as full. This is a precaution as it will prevent reusage.

As NW does not know whether it is the drive or the media, you need to investigate this problem further (tapeexercise).

 

[luftposter]

1) You started off by saying that the tapes were all marked full, which means that if they were not really full and were marked full, your tape drive must have had a problem.

I will suspect that the drive to which your database tapes are loaded is different from that to which your Default tapes are loaded; if they are not different, you should have been seeing the same behavior with the database tapes.

2) Regarding your question about backing up with the "no index option" in the pool configuration. You should not choose this option for a database backup; you'll NOT be able to recover the database because no NetWorker Module saveset can be recovered using (let's say) Saveset Recover. You should however be able to generate indexes by using the scanner command if you should go with that option.

 

[tilleyk]

I did a test.

I re-labeled a tape from each pool, default and database, and mounted them in each drive. Then I ran the scheduled backup. The database backup successfully completed on the database pool and the index successfully completed on the default pool.

The index backup seems to fail when there is data already on the tape. Or maybe it fails when one tape has to be unmounted and another tape mounted on the same drive.

 

[605]

It would be easier if you simply would provide the selection criteria for your 'database' pool.

 

[tilleyk]

My database pool has the following setup:

Pool Type: Backup
Label Template: database
Groups: database
Clients: blank
Save Sets: blank
Levels: full and incr
Devices:Both selected
Store Index entries:Yes
Auto media verify: No
Recycle to other pools: No
Recycle from other pools: No
Volume type preference:
Administrator: root@<networker server>

In the Client setup of my oracle server host:
Group:database
Save set: Full path to the RMAN script
Remote Access: root@<networker server>
Remote user: blank
Password: blank
Backup command: nsrnmo_tst
Aliases: oracle server host name
Storage nodes: nsrserverhost

Since my database pool has the database group selected and my oracle server host is part of the database group in client setup , I'm assuming this is where the pool selection occurs.

My oracle server host also belongs to the Default group in a separate Client setup to backup the Unix filesytem.

 

[605]

The problem is the pool's level: When you specify the level incr, index backups will be written with level 9 (you can easily verify this with mminfo).

To cure the problem, simply also check 'level 9' for this pool.

 

[tilleyk]

Checking level 9 for the pool seemed to do the trick! Thank you very much for your help!

 

[605]

One of the oldest issues:

Incremental level will result in Index level 9 backups

Never forget this.