> This problem made/makes a lot of work (recovering and reconstructing > data). It's pretty hard to defend SAP DB if it's doing such things > (some people argued with us about the functionality regarding backup > and recovery and in this case it's hard to find some reasons for SAP > DB
It's hard? I don't think so. Look at Postgresql. They also had embarassing bugs --- that's life. But they can't operate 24x7, because you have to vacuum the database from time to time. And during this time people can't use the database. This is not a problem with SAP DB. > It is possible (under *nix) > to create files with "holes" by jumping behind the file-end when > creating a file. These holes are returned as a bunch of zeros when > reading. Only if you are writing something in these holes the system > will create blocks on the harddrive. That is possible --- but it is not wanted. The database creates those big files in the hope that all blocks are at consecutive addresses. If you create data blocks on the file, your data will be plastered all around your hard drive. This add's several costly seek times to your data access times. Or you would have to defragment your hard disk from time to time. Maybe not the way you want to go with 15 - 20 GB of data ... _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
