Hi Doug,
Likely, this was reclaimed free space in the database although we should
confirm that. If this is a single dbunload operation, as part of the
unload/reload process (dbunlod -an), we will calculate how much we
"think" we need for the new database (based on the old database size)
and will attempt to pre-allocate that much free space in the new
database (which will save on OS file fragmentation while re-inserting
the data).
Questions:
- What does "dbinfo -u" report for both of these databases?
- What is the version and build of our software being used?
- Can you explicitly list the load/unload steps you used to generate
these two databases? I assume your initial "dbunload -u" step went to
..dat/reload.sql files, and then you initialized a new database, thjen
ran reload.sql on the database, then the rebuild of that new database
happened via "dbunload -an", or...?
---
*Note: If this is urgent because it's a production down situation,
please open a technical support case:
http://www.sybase.com/contactus/support/
Regards,
Doug Stone wrote:
Quote:
The new db was 1.2 gig, about 200 meg smaller--expected with the loss of
audit tracking.
Then I ran db unload on the new database without the -u parameter,
thinking that I would optomize the index structure.
That database was not quite 300 meg!... The loss of 900 meg on a 1.2
gig db is totally unexpected.
What may be happening?
Can I generate a log during the dbunload process which might explain the
loss in size?
The app seems to run normally against this much smaller db.
Any suggestions/thoughts apprecieated.
Thanks,
Doug
p.s. This is a down production db. |
--
Jeff Albion, Sybase iAnywhere
iAnywhere Developer Community :
http://www.sybase.com/developer/libr...ere-techcorner
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
SQL Anywhere Patches and EBFs :
http://downloads.sybase.com/swd/summ...&timeframe =0
Report a Bug/Open a Case : http://case-express.sybase.com/cx/