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.
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.
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.
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.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.