Is there a better way of fixing this issue, besides doing a Dump/Load of the database
Yes: stop doing incremental backups. Yes, that's a serious answer. With after imaging enabled and AI log shipping/archiving in place as andre42 described, incrementals are unnecessary and inefficient. Which makes me think you don't have after imaging enabled.
In response to Rob Fitzpatrick: we are doing Incremental backups due to the amount of changes during productions hours.
Do you have after imaging enabled on the production database?
You must. If you're not sure of the answer, you can post the output of a proutil describe command run in a
proenv
session. E.g.:
proutil D:\hagenoa\hsi\data\gams1 -C describe
. Please enclose the output in [ CODE ] tags (without the spaces inside the brackets).
If you don't have after imaging enabled in production, then the size of your incremental backups is
not your most pressing concern. In this case, you must absolutely prioritize enabling AI and configuring it appropriately. If you're unsure of how to do so, or why this is so important, you should pressure your vendor to help you get this done.
if exist e:\hagenbak\backup\%1\gams1bu (
del e:\hagenbak\backup\%1\gams1bu
)
probkup online gams1 e:\hagenbak\backup\%1\gams1bu -com
Your script deletes the current backup before knowing whether the one it is about to execute is going to succeed. Food for thought...
Optimization note: you could benefit from adding "-Bp 10" to the end of your
probkup online
command line. This causes the backup client to use a small area (10 buffers) in the database buffer pool for its block reads, rather than using the entire buffer pool. This prevents it from "fouling" the buffer pool with contents of old blocks that are not useful to database clients, which would temporarily reduce the database's caching efficiency (i.e. increase physical disk I/O).
In response to TomBascom: We cannot upgrade, as this is what's provided for us from our MIS/ERP software and they only approve it with our current 10.2B SP6 version.
I understand that you are constrained by what your vendor will support. But there is a distinction to be made between a version upgrade (e.g. to v11.7 or 12.0) and the installation of a later service pack into an existing version. The latter carries much less effort and risk and keeps you on the same OE version. 10.2B08 contains a lot of bug fixes for issues in 10.2B06, and as a bonus it contains functionality that would make a dump/load/index rebuild on Windows more efficient. At a minimum, your vendor should be willing to entertain a discussion with you on the subject of installing the latest bug fixes available for your release.