Current kilobytes written

[ewill11]

Can anyone tell me why the "Current kilobytes written" varies widely from job to job? On a recent backup, some job ID's showed 96 Kbytes written, some showed 16416 Kbytes.

 

[DanKellen]

If you are talking about running the same class multiple times, I would suggest that either your data is also changeing wildly, or your backups are failing intermittently. What is the status when you only get 96 KBytes? And does a "Backup Problems" report indicate any problems?

If you are talking about different classes, then they are backing up different disks or filesystems.

 

[ewill11]

I get no problems reported. This is a backup of an Oracle database. What happens is the job kicks off - say a level two backup - and it in turn kicks off what appears to be a separate job of each backup piece (I'm just guessing here.)

For instance, this morning at 00:03 my level two kicked off using the cumu-backup schedule. It in turn kicked off 143 other "jobs" that all used the Default-Policy schedule. All of them got the little blue man - operation successful. The blue guy with the cumu-backup schedule wrote 0 Kbytes. One of the other jobs (Default-Policy schedule) wrote almost 900,000 Kbytes. Several of the Default-Policy schedule jobs wrote only 96 Kbytes. It took over six and a half hours to run all 143 jobs.

 

[DanKellen]

I haven't worked with Oracle, but the behaviour you describe is the same with SQL Server.
The first job is like a master job that runs a script, but doesn't actually back anything up. Your class will have the script under the Scripts tab. You should find your 143 items in there.
For SQL Server, each database is a different job. For Oracle, it's probably based on what RMAN sees. And so each job varies in size, based on what it is backing up.