Kbase P78662: All About Disk Striping
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
02/07/2008 |
|
Status: Verified
GOAL:
All About Disk Striping
GOAL:
Is striping an advantage?
GOAL:
Disk Striping
GOAL:
Is Disk Striping an advantage to use?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Versions
FIX:
1. Mirroring provides fault-tolerance by having duplicate copies of the mirrored disks. Thus if one fails, you don't lose the data. There may be some performance benefit for reading as well. If you have mirrored pairs, you can read from either or both of the pairs, spreading the load a bit.
2. Striping combines several drives into a single "logical drive" and provides better I/O performance by more or less equalizing the workload across the drives in the stripe set. If any drive in the stripe set fails, you lose the entire stripe set, so striping should
ot/ be used without also mirroring. Without mirroring, the stripe set is less reliable than indivdual disk drives (jbod).
3. You can do "poor man's striping" by slicing the database into extents that are allocated round-robin over several drives. For example, say you have a 10 GB database and four drives. You can make say 20 extents each 1 GB and put extent 1 on drive 1, extent 2 on drive 2, extent 3 on drive 3, extent 4 on drive 4, extent 5 on drive 1, and so on. This will give you some of the effects of a stripe set.
This won't be quite as good because the chunks are larger than you get with a stripe set. As the database grows, you have to keep following the pattern, so it is a little more work. Finally, you end up with an unnecessarily large number of files for the database.
4. You can put the bi log on the same stripe set as the data extents but performance will be better with the bi log on a separate drive. In some tests, with a heavy update workload, BI on the stripe set gave about 60% of the performance (i.e. throughput) compared to a separate drive. Your mileage may vary depending upon system and configuration.
5. The purpose of the AI log is primarily for fault tolerance. If you place the AI logs on the same storage as the data extents and/or BI log, then if you lose that storage, you lose the AI logs too. Therefore, the AI logs should always be stored separately from the data and BI logs.
To illustrate the value of the AI logs (and why you should not keep them with the data extents) see the synopsis below:
A person had gone into the wrong directory on their UNIX Operating System. They typed the command "rm *". This command removes all files in a given directory. The database just happened to be in that directory. There were about 100 users accessing the database at the time that the database extents were deleted. Since open files on UNIX are not actually deleted until they are closed, the users were unaffected and unaware there was a problem. No new users could log in, but users already accessing the database could continue working. The DBA (database administrator) realized what had happened and was aware how to fix the issue. The DBA, obtained the previous nights backup and restored it into another directory, and rolled forward all the AI extents except the last one. The DBA then sent the users a message saying he was going to shut the system down for 5 minutes so all users had to get off. The DBA then rolled forward the last AI extent and started the database server again. Everything was fine and nobody was the wiser.
Had the AI files been in the current directory, where the original person had performed the "rm *" command. The DBA would not have been able to recover to the current point in time. They would have lost all of their AI files if they were not archiving the regularly. They also would have lost the current AI file that was in a busy state. What this means is they would have lost data.