Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Fragmentation - why it is usually good for VFP native da
Message
From
19/01/2003 15:58:45
 
 
To
19/01/2003 08:11:58
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00742043
Message ID:
00743296
Views:
15
>My main objective is to change the perception that fragmentation is always bad. My reason for doing so is that I then hope that MS orsome software house can be convinced to make tools to let us do something USEFUL **WITH** fragmentation, rather than always AGAINST fragmentation.

Hi Jim,

The impression I've gathered from these threads is that there are some circumstances in which fragmentation may help VFP file I/O performance. However, I think it's a bit of a stretch to claim it *usually* improves it.

If, for example, you have 2 or more separate VFP databases on the same disk, or those additional databases plus other non-VFP apps/data, then ongoing disk fragmentation is not likely to be as "optimal" as necessary to see improvements.

As for someone creating a "fragmentation" tool (dev. code name: "Grenade"? ;-)) I don't think this will happen, for the reason I outline in the next paragraph. Continuing with the multi-app scenario outlined above, how can you be sure, if you "optimally fragment" App#1, that you haven't hurt the other apps - i.e. take from Peter to pay Paul?

Historically, to wring every last iota of performance out of the file system, RDBMS vendors have implemented their databases as single files, in pre-allocated, contiguous disk space. The DBMS is then free to manage the placement of DB objects within this space however it wants - it knows the OS can't move file fragments outside the pre-allocated range. There are at least 2 major downsides - it adds another layer of complexity in DB object management, and it could be quite painful to expand the size of a database on a crowded disk or volume. Also, if that single file gets corrupted, those are all your eggs in that single basket (have you ever talked to anyone who's suffered a corrupted Access .MDB?) This is the way Sybase and the early (Sybase-based) versions of SQL Server used to work. I don't know if that's still the case with SQL Server, or its major competitors.

I'd suggest that in the specialized cases where vendors could use the extra performance fragmentation may give them in specific circumstances, they will probably implement this monolithic, single-file approach which ensures they can organize their DB objects optimally, while not treading on anyone else's file/data structures.
Regards. Al

"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov

Neither a despot, nor a doormat, be

Every app wants to be a database app when it grows up
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform