data protection

[smi]

Hello,

I'm new to this Teradata and have a fair working knowledge of it. But I've got some questions about its architecture and terminologies. What is VPROC? What is AMP? What is the significance of these two? Are they related?

Should we make tables as FALLBACK or NO FALLBACK? Which one is good? Making a table FALLBACK protected will it bring down the overall performance of the system? What if I make the tables as NO FALLBACK? Which is advisable and Why?



James

 

[Mozc]

James,

A Vproc (virtual processor) is a generic term for VAMP and VPE. VAMPs are virtual AMPs and VPEs are virtual parsing engines. VPEs are basically responible for all communications to the client, such as, receiving SQL requests, parsing the SQL, optimizing, dispatching the SQL steps, and coordinating the result set back to the client. On the other hand, the VAMP generally consumes most of the CPU resources as it performs the actual database work (scanning, joining, computations, etc.) in parallel with all the other VAMPs. There is a science to the proper number of PEs and VAMPs in each configuration which is highly dependent upon numerous factors such as number of concurrent sessions required. These also should be balanced (a uniform number of PEs and VAMPs) across all the nodes within the system.

As for fallback protection one should highly consider the required serice levels. Are you required to support availability at 99.999%? Can your users tolerate a 24 hour outage? Are your users willing to pay a significant cost to expand your system to utilize additional data protection?

Fallback is basically RAID-1 or mirroring but managed at the DBMS level. Fallback does not impede select performance but does generally slow down bulk update, insert, and delete operations by 2x. Fallback will also result in 2x the storage costs. RAID-1 is mirroring at the hardware level and has similar characteristics BUT can provide some improvement on selects via sychronous reads. Don't make the mistake of blinding choosing fallback on top of your RAID-5 file system. Be careful and understand the costs.

Also, you can selectively turn fallback on or off by table should you have some tables that require different service levels than others.

I hope this helps.

Doug Drake
(MOZC)

 

[smi]

Doug Drake,

Thanks a lot for ur reply. I didn't understand why u said

"Don't make the mistake of blinding choosing fallback on top of your RAID-5 file system."

Does RAID-5 itself give protection to tables and data. I mean i don't know what RAID-1 or RAID-5 do. One more thing if I make some tables as NOFALLBACK and say AMP goes offline is it possible to retrieve the tables without any data loss.

Regards,

James

 

[Mozc]

James,

I only wanted to caution you against making the common mistake of applying fallback on top of the protection that you are likely to already have with RAID-5. The critical issue is that you should consider the availability requirements and costs relative to the benefits. Rather than just following a general recommendation from the vendor of implementing fallback seriously consider the costs and incremental protection it might provide.

RAID-1 is mirroring while RAID-5 is parity striping. Both are managed by the disk subsystem and not the DBMS. Since RAID-1 generates a mirror the cost in terms of storage is 200% (of the baseline) while RAID-5 varies but is often 125%.

In terms of performance RAID-1 is generally better for the typical DSS workloads because it provides synchronous reads. This is the reason why one now sees most Teradata implementations at RAID-1. Now you have to ask yourself if you really need fallback on top of the RAID disk protection one normally has through the disk subsystem.

If we speak about availability and use your scenario of loosing an AMP. This is actually a VAMP which is a process running on the node. This would normally occur in the scenario when you have a node outage. Well, VAMPs can and will migrate to other nodes within the same clique and therefore access to the data is still maintained.

However, this failover situation only applies to configurations where you have at least 2 nodes per clique. Some of the smaller systems are not configured as such and you could be faced with an outage for all non-fallback tables.

I would suggest that you discuss your specific configuration with your NCR support rep and understand what types of failures would cause a hard outage should you not utilize fallback. Also, keep in mind the probability of each type of failure. By far the most frequent failures are disk failures which would normally be remedied by RAID and therefore only marginal value by implementing fallback on top of RAID. This is not to state that there is little value in fallback. You should carefully quantify the marginal benefit verses the potentially significant cost.
Doug Drake
(MOZC)