Service Actions and Events | Teradata VantageCore | EDW - Service Actions and Events - Teradata VantageCore VMware

Teradata® VantageCore powered by Dell Technologies - Enterprise Data Warehouse

Deployment
VantageCore
Edition
VMware
Product
Teradata VantageCore VMware
Published
April 2024
Language
English (United States)
Last Update
2024-04-24
dita:mapPath
csc1707954420061.ditamap
dita:ditavalPath
ayr1485454803741.ditaval
dita:id
csc1707954420061
Product Category
Cloud

Certain service actions may impact the operation or severely impact the performance of the system.

Failure to follow these guidelines may result in loss of data and extended downtime, which may not be supported by Teradata.

Coordinate any service actions that result in the disruption of infrastructure resources with Teradata to minimize impact. The following table describes prerequisites of service actions, observed impact, and recovery actions:

Service Action / Event Prerequisite action Impact Recovery action
VM pause/stop/restart (1 VantageCore VMware VM affected) Engage HSN to move database off affected VM Database is restarted once to transition from affected VM No additional recovery needed. System can remain running on HSN
VM pause/ stop/restart (>1 VantageCore VMware VM affected) Database offline Database needs to stay offline until all Analytics Database VMs are available Start database after Analytics Database VMs are available
SQLE VM movement vMotion not yet supported for VantageCore VMware VMs in this implementation NA NA
Host Reboot (1 VantageCore VMware VM affected) Engage HSN to move database off affected Host Database is restarted once to transition to HSN No additional recovery needed. System can remain running on HSN
Host Reboot (>1 VantageCore VMware VM affected) Database offline Database needs to stay offline until all Analytics Database VMs are available Start database after all Analytics Database VMs are available
Planned Storage LUN unavailability (all paths to any LUN unavailable) Database offline Database needs to stay offline until all LUNs are available Start database after all Analytics Database VMs are available
Unplanned Storage LUN Failure/Corruption (LUN RAID failure) Database Business Continuity up to date (Back, Fallback) Based on the number and location of the missing LUNs database may remain available on Fallback Database recovery through Fallback or BC Recovery
Loss of Storage Array Redundancy (one controller offline/ controller reboot) No action Expect loss of performance while controller offline Database performance returns to normal once storage performance restored
Loss of Storage Drive Redundancy (Drive removal/failure) No action Expect loss of performance while raid degraded Database performance returns to normal once storage performance restored
Loss of Network Redundancy (One switch reboot, power off, replace) No action Performance and resiliency impacted while network degraded Database performance returns to normal once network performance restored
Loss of Network Node-Switch Connectivity (1 cable failure/replace) No action Possible performance impact for impacted node No additional action required
Loss of Network Storage-Switch Connectivity (cable failure/replace) No action Performance and resiliency impacted while network degraded No additional action required

Loss of Network Switch-Switch Connectivity (cable failure/replace)

No action Performance and resiliency impacted while network degraded No additional action required
Management Cluster Node outage (1 node) Recommend moving VMs for planned outages No impact. May experience temporary loss of BYNET (perf) No additional action required
Management Cluster Node outage/failure (>1 node) If sufficient resources are available after node outage to maintain management services, event can be handed like “1 node” failure else database must be taken offline Database needs to stay offline until all Management Cluster Applications have restarted. Restart management Cluster services then restart the database
Management Cluster VSAN offline/failure Database offline Database needs to stay offline until all Management Cluster Applications have restarted Assuming no loss of data restart management Cluster then restart the database. If data loss occurs, recovery is to redeploy apps as required.