Archives of the TeradataForum

Message Posted: Thu, 20 Dec 2001 @ 09:13:36 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

A few comments on items in this thread:

- Teradata supports Raid 5 on LSI disk arrays in production configurations without restrictions.

- Teradata does not support EMC with Raid S (EMC's Raid 5 implementation) because EMC has dropped support of that offering.

- Teradata does not generally recommend Raid 5 at this time. Raid 5 was invented when disks were very small, space on them was an absolute premium to the point that it was worth giving up some performance. With today's much larger disks, Raid 5 is no longer as relevant, to the extent that a major industry player (EMC) has abandoned it altogether.

- There is a performance downside to Raid 5. The penalty is roughly 20% for all writes. For Teradata this includes at least single row updates, utility updates, restores, and spool writes. Your mileage will vary of course depending on the total system utilization and your configuration.

- There is also a moderate availability penalty to Raid 5. If one disk fails, there are 3 disks which each became single points of failure until the failed one is repaired. In a raid 1 configuration, only the 1 mirror disk is a single point of failure until it is repaired. Further, the Raid 5 software in the array controller is significantly more complex than the raid 1 software, exposing the system to a somewhat higher probability of SW errors that might damage data.

- The cost per megabyte in LSI arrays (and EMC as well) has come down significantly with each generation. Each time the drives double in size for instance, it requires half as many arrays to store the same volume of data. This, and the raw size of the disks is the macro trend which is moving the industry away from Raid 5, and leading to Raid 1 being Teradata's advocated solution. This is not a claim that enterprise disk arrays are inexpensive because they are not, but they are on the same curve as the cost of the underlying components, particularly the disks themselves.

- If it is absolutely required to increase the disk space of a configuration without adding any components, then the system may be converted from Raid 1 to Raid 5. There is a significant impact though because the data cannot be converted in place. All data must be archived or extracted, then the disks must be reformatted and restriped, the Teradata disk configuration must be redefined, and all data reloaded onto the system.

- Once the system has been converted, there will be two performance penalties. The first is the 20% write penalty mentioned above. The second comes as the larger disk space is filled with data. If the data added is accessed equally with the existing data, then each AMP will have more work to do and all response times will extend proportionally.

- There are several things that should be considered prior to the drastic step of changing the Raid protection on a system. Teradata value compression can have a significant impact on storage requirements, especially on large tables. Reviewing data types on large tables can have an impact as well: BYTEINT or SMALLINT instead of INTEGER, CHAR VARYING instead of long fixed character strings, Decimals defined with appropriate total digits,... Can all make a difference. More complex changes such as reviewing the data model for redundancy can help, but of course require more effort to implement.

	<Prev	Next>		<<First	<Prev	Next>	Last>>