can I delete sysutils:bar_instance ?

select count(*) from sysutils:bar_instance50000000 rows can I delete sysutils:bar_instance? or I used onsmsync -t "" to expire some backup ? ------------------------------ ZhiWei Cui GBASE ------------------------------ #Informix

I would not recommend just deleting rows in the bar_instance table, as there are other tables that would need to be purged also. The proper and safest way is to use onsmsync to clean up all records in the various tables in the sysutils database. This will also delete records from the ixbar.<servernum> file (in $INFORMIXDIR/etc), which I expect is also very large. The problem in your case is that the onsmsync will probably take a VERY long time to run, as it is not very efficient. The alternative would be to manually purge old entries from the ixbar file and reload the sysutils tables from the smaller ixbar file. Suspend backups, including logical log backups (usually by changing alarmprogram.sh - BACKUPLOGS=N) dbexport the sysutils database take a copy of the ixbar file edit the ixbar file and remove everything except the backups that you want to keep recreate the sysutils database ($INFORMIXDIR/etc/bldutil.sh) run onsmsync -b (this will reload the sysutils database with the entries remaining in the ixbar file) Enable backups and logical log backups A warning with this approach though is that if you are using onsmsync to expire the backups themselves in the storage manager, then recreating sysutils/ixbar file will not do this. ------------------------------ Mike Walker xDB Systems, Inc www.xdbsystems.com ------------------------------

Tks. I want to expire back info use onsmsync -t "xxxx-xx-xx xx:xx:xx" ------------------------------ ZhiWei Cui GBASE ------------------------------

Yes, that will expire backups before the supplied date and time, and also remove those entries in the sysutils database tables and the ixbar file. You may find some objects before that date remain if onsmsync determines that they are needed in order to restore objects after that date. For example, if there is a Level 1 archive that occurred after that date and time, then the required Level 0 that was taken before that will not be expired. It is possible that you will see errors or encounter problems with the sync, but often these are not critical. I have seen problems when trying to expire too many backup objects, so it can be better to run first with an older date, and then continue to run in batches of (say) 6 months at a time. ------------------------------ Mike Walker xDB Systems, Inc www.xdbsystems.com ------------------------------