Alan McDonald wrote:

>>
>>I need to restore a database that was backed up ...
>>but when I compare file sizes, the restored database is 485MB, and the
>>backup from the 8th is 1.4GB, and it looks like not all the data has come
>>back. Am I doing something wrong, or what is going on here?
>>
>
>
> file sizes are not the best indicator here.
> Depending on page size setting, file sizes can be quite different.

The backup is just a dump of the data in the database - it doesn't
have a page size.

> There there is the issue of how much garbage there was in the oroginal file.

One difference between a database and a backup is that a
backup doesn't include the garbage. That means that backups
are normally smaller than databases.


Another difference between backups and databases is that the
backup doesn't include any of the header or structural
information present in the database - no page headers, no
record headers, no TIPS, no PIPs, no pointer pages, no
reserved space. That means that backups are normally smaller
than databases.

Another difference between a backup and a database is that the
backup includes index definitions but not the contents of
indexes. That means that backup files are normally smaller
than databases.

Another difference is that data in databases is compressed
using a very simple bytewise run length compression. The
backup file isn't. So, if your database contains lots of
fields that are defined as varchar(30000) and contain ten
characters, the backup is going to be larger than the database.

Normally, gbak restores all the data in a single transaction,
so either it's all there or none of it is. Restoring a database
happens in several phases - each representing a transaction. The
first phase creates the primary metadata. The second creates the
data. A third creates the indexes. A fourth activates constraints,
triggers, etc. A failure during the second phase would result in
an empty database of considerable size - the data is there, but
marked as rolled back.

Regards,


Ann