> From: "Whil Hentzen (Pro*)" <[EMAIL PROTECTED]> > Second, whether your database can do incremental backups. If you have a > primarily archive oriented database and can't do incremental backups, > you will be backing up the same data over and over, and the backups can > get quite lengthy if the database gets large.
Are we talking about backups on a db, or on a file server? I am not fond of restoring from diffs, been burned enough in the past. That was diffs to a file server. > By just using pointers, the database size is minimized, and you can > backup the images separately a single time. Your database backup time > is minimized in this case. If your database can do incremental backups, > the problem is lessened, but if the number of images gets very large, I > think it can still start to impact database performance. In my experience a diff is the delta between now and the last full backup. I do a Start of month full and a daily diff. To restore, I restore the last full and then the most recent diff. After that I could get into the trans logs and bring you up to the last good log. The volume of rows in the data is the key and not the size of the table in the db. So a column is a blob, it will still crank in a query and if you know the PK, you have it right away. I know from having diagnostic imaging files in an oracle system. db was on the 800 gig size at the time but it cranked in delivering content. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
