Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Fragmentation - why it is usually good for VFP native da
Message
De
19/01/2003 15:58:45
 
 
À
19/01/2003 08:11:58
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00742043
Message ID:
00743296
Vues:
17
>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
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform