Upgrading 9.0 to 16.0 on external disk

[thelmacottage]

We currently have a large V9 database (replicating) which we need to upgrade to V16 - The disk on the server is running very low and i would like to move it to a external USB drive attached to the server. The file locations ar

C:\\SDATA_LOG - This is holding the log files E:\\SDATA - This holds the main DB file (100GB)

Usually I would use dbunload -ar (Directory) - but as this creates a copy I would run out of disk space.

If I copy the main DB onto the external disk (F:) can I still run this command ? (leaving the log files on the C: dive) ? -If so do I just then copy the upgraded file back to the E:\\SDATA directory ?

Thanks

Mark

[MarkCulp]

If you move the v9 database to your external disk then I'd suggest that you use "dbunload -an newfile.db ..." to create a new v16 database on your C: disk. This has two advantages: (1) you will have a backup of your original v9 database, and (2) you do not need to move/copy the new database back to your c: drive when it is done.

HTH

[thelmacottage]

Thanks for the comments. The C: drive also very limited space. I would like to keep the main db file on a separate volume to the log files as well.

Would my suggestion above work ? It's not a problem copying files back and forth.

[MarkCulp]

I guess my main point is that there is really no advantage to using -ar instead of -an because -ar simply does -an (under the covers with a temporary database name) and then does a rename when it is done.... hence during the rebuild there must be enough space for both the old (v9) and new (v16) database. Go ahead and use -ar if you wish but I'd recommend always that you have a full backup of your database before using -ar just in case something goes wrong!

[VolkerBarth]

@Mark: Just as a side note: Does an external drive qualify as a fully-supported storage device? - I'm refering to that exhortation from the "The transaction log" docs page:

The database file and the transaction log file must be located on the same physical computer as the database server or accessed via a SAN or iSCSI configuration. Database files and transaction log files located on a remote network directory can lead to poor performance, data corruption, and server instability.

FWIW, the link following that quote still points to a Sybase URL which is not accessible anymore...

[thelmacottage]

@Volker: Wouldn't use this external drive in normal production - it's just a way to get over the problem of limited space on the main volume.