Kbase P26398: Should the database extents be on the same filesystem as the ai files
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
4/22/2008 |
|
Status: Verified
GOAL:
Where should extents be stored on the filesystem?
GOAL:
Should all the extents of an area be on the same filesystem?
GOAL:
Where should the ai files be stored on the filesystem?
GOAL:
Where should the bi files be stored on the filesystem?
GOAL:
Must the ai files be stored seperately to the database files?
GOAL:
What structure to use for the database?
FACT(s) (Environment):
All Supported Operating Systems
FIX:
In the past, we used to recommend each extent 1,2,3,4,5,6 (repeat) over the file system, which was like a cheap striping. Striping and mirroring used to be expensive, it's not anymore. By putting the extents in this way, we're optimision i/o which give a significant perfomance boost. Two requests for the same disk vs 2 requests for data on different disks is significantly faster.
Although we don't have any specific recommendations for where files should be stored, we do recommend the following:
+ The ai files should all be on the same filesystem but a different filesystem to the rest of the database. These are the files that are going to be relied upon for database recovery. The archive of the ai files must be completely seperate.
+ The same goes for each of the bi file extents and this should be on a different filesystem to the ai files. The ai and bi writes are single threaded (only write to one extent/file at a time) So it makes sense to have these on their own filesystem if possible, as these two files are always been written to while the database is up and running.
+ Must take into consideration filesystem limits. In other words, that the variable file extent will not exceed the filesystem limit.
If the filesystem crashes, then, well mirroring takes care of this these days, but in any event, worst case, the database will have to be restored from backup whichever filesystem crashed. If the filesystem is the one that ai files are on, well, so what. Stop the database, stop after imaging, probkup, start ai, recreate the target (hotspare) database from the probkup and roll forward the archived ai files that were on a different disk to the production ai files right?
If the filesystem that crashes is NOT the ai one, then after prorest of the appropriate database backup, you not only have the archived ai files, but also the most recent one's that weren't archived to bring the database right up to the "crashed" date/time once they are rolled forward - if you remembered to acrchive these before removing the damaged database.
EXAMPLE:
6 filesystems
3 storage areas each with 5 extents
bi file with 3 extents
5 ai files
SA1 EXT1 fs1
SA1 EXT2 fs2
SA1 EXT3 fs3
SA1 EXT4 fs4
SA1 EXT5 fs1
SA2 EXT1 fs2
SA2 EXT2 fs3
SA2 EXT3 fs4
SA2 EXT4 fs1
SA2 EXT5 fs2
SA3 EXT1 fs3
SA3 EXT2 fs4
SA3 EXT3 fs1
SA3 EXT4 fs2
SA3 EXT5 fs3
b1 fs5
 .; b2 fs5
b3 fs5
ai1 fs6
ai2 fs6
ai3 fs6
ai4 fs6
ai5 fs6.