Taking a break from the daily grind
There are some things a Teradata DBA never has to do. Can you guess what they are?
by Roger Mann
Prospective Teradata clients frequently ask, "Since my database administrators already know (insert the name of your favorite database here), how long will it take for them to learn Teradata?"
Even though Teradata is a structured query language (SQL)-based relational database management system (RDBMS) and shares many similarities with other RDBMSs, its underlying architecture is very different. Some of those differences surround database administration. Thus, the time that DBAs are required to spend setting up and administering the data warehouse is significantly less with Teradata than with other platforms.
RDBMS was originally envisioned as an environment that could perform both transactional and decision support requirements equally. The early users quickly discovered that scanning and joining large tables yielded excessive response times that were, in some cases, never ending. This resulted in vendors directing development resources at the online transaction processing (OLTP) market, where the consumers were demanding databases that had consistent, rapid response times, bunker-hardened reliability and the capacity to serve many concurrent users.
The wide variety of customers, each with very different requirements, caused vendors such as Oracle, Informix, Sybase and IBM to develop many custom parameters and tuning options that allowed users to tailor these systems to meet their individual needs.
Successful DBAs were required to understand each of the parameters, settings, operating systems and hardware platforms. OLTP queries were known and programmed ahead of time and needed to be highly tuned. A significant part of
a DBA's job was to become educated on the impact each setting had on system performance. In essence, DBAs had to become experts on system monitoring, tuning and query optimization.
Business analysts wanted reports that mandated scanning and joining data from large, historical archives. Teradata was built to address this emerging market, which required the database to answer any question asked of it, even questions it was never asked before. The nature of these queries does not afford the opportunity to modify SQL, add hints or tune system parameters prior to execution.
Teradata, however, was engineered with these automatic and self-tuning features in mind. Consequently, many of the challenges and details that plague other DBAs don't concern Teradata DBAs. As the marketplace grew substantially, all vendors continued to update, improve and add features to their products to address this market.
Teradata's underlying "shared-nothing" parallel architecture continues to provide greater flexibility in addressing those decision-support types of questions without the addition of more parameters and tuning "knobs."
While some of the items listed here may not be applicable to every RDBMS, attention to these details becomes mandatory as data warehouses grow into and expand beyond the size of a terabyte. But thanks to Teradata's self-management features, Teradata DBAs are not required to:
> Install the database
Teradata completes the engineering integration process on all components before shipping the system to the customers, including installing the operating system and the database. Teradata is delivered as a fully integrated and balanced parallel processing platform with system management and high availability integrated into the hardware and database software.
> Understand, monitor and tune extensive operating system parameters
The only job the operating system has in a Teradata environment is to run the internal Teradata parallel processing modules and keep the platform stable.
The Teradata database controls all I/O, task selection and kernel activity.
> Understand, monitor and
tune extensive database parameters
Teradata has very few system-initialization parameters. DBAs who have worked with other databases will find that many of the parameters that required tuning on those platforms do not even exist within Teradata. The parameters that do exist are set at installation for optimal system performance and rarely, if ever, need to be modified.
> Determine the size and
physical location and/or space allocations of tables and index partitions
Teradata treats the entire system as one large data repository. A quota system controls space. However, the DBA can place limits on the maximum amount of space that any table, database or user can consume. Teradata is responsible for all data and index placements. Databases and tables are added without consideration of physical data placement, tablespaces or file structures. There is absolutely no difference between a CREATE TABLE statement used for a table that will hold 1,000 rows and one used for a table that will hold 10 billion rows.
> Perform periodic table and index reorganizations
The Teradata file system is fundamentally different from the file systems upon which other database management system (DBMS) products are built. Data rows and index structures are not maintained in sequence based on the data or index value. Massive insert, update and delete data maintenance operations do not adversely affect file system performance. A DBA never has to unload and reload data tables to place the file structures back into sequence to regain lost performance.
Teradata's file system stores data in variable-length rows within variable-length blocks. The file system will automatically grow, shrink or split these blocks as necessary. Teradata maintains these rows in a row-hash sequence. A background process, which uses spare cycles to ensure minimal impact to system performance, handles any fragmentation that may occur due to system processing.
> Manually restart the load process when failure occurs
Teradata utilities automatically load data in parallel, perform data conversions and provide error recovery with checkpoint-restart capability.
> Schedule downtime for routine data maintenance
Teradata does not require the query workload to be stopped when processing data maintenance on the entire table. Many Teradata clients simultaneously process data maintenance and queries, on the same tables, 24-7.
> Sort data in preparation for loading
Teradata uses a hashing algorithm for data distribution. It is a waste of time and external CPU cycles to sort the data prior to loading because there is no inherent order of data stored in Teradata.
> Calculate and configure fail-over plans (e.g.
high-availability clustered multiprocessing)
High availability through automatic fail-over and automatic system rebalancing is built into the Teradata DBMS. No optional products, coding and debugging of parameters or procedures are required to effect a multi-node system recovery, regardless of size.
> Tune queries
The Teradata optimizer was built to run complex queries efficiently. Users often run queries that contain 16–20 or more table joins in a single SQL statement. DBAs no longer have to analyze such complex queries and manually break them into multiple query steps with intermediate result sets to achieve satisfactory complex query performance.
> Spend a lot of time expanding the system
Hardware and software modules used to expand Teradata systems arrive pre-configured from the factory. The data is redistributed by a "push button" utility that moves data only to the new units. When completed, the utility will have redistributed and rebalanced every database, table, index and other entity in the entire system without the need for the DBA to intervene.
There's still work to do
Of course, there is still plenty to keep a Teradata DBA busy, and skill sets acquired administrating other databases will not be lost on Teradata. However, DBAs will soon discover that, with Teradata, time spent in the trenches setting up databases, loading data, tuning queries and monitoring performance is a fraction of the time spent with other platforms.
This allows the Teradata DBA time to help business people solve business problems. In addition, the DBA can rest easy, knowing he or she won't have to spend weekends and holidays reorganizing database tables and indexes.
Any DBA proficient with a competitive database product will find learning Teradata a snap. The real challenge for them is forgetting all those parameters and details they spent so much time learning. In other words, Teradata is DBA-friendly, and that's enough to make everyone smile.
Roger Mann, a Teradata Certified Professional, is a senior consulting engineer with Teradata. E-mail him at roger.mann@teradata-ncr.com.
© Teradata Magazine-June 2004
 RELATED ARTICLES: |
|
|
|
|
|
Printable version
Send to a colleague
