CaseStudy

ACNielsen: Building a Data Factory

with Oracle
At ACNielsen, information—and lots of it—truly is their data warehouse, but our core business,”
explains Jean-Paul. “That’s why we call it
business. As the world's leading marketing information a factory, only what we manufacture and
deliver to our clients is information.”
provider, ACNielsen provides measurement and analysis of ACNielsen had been relying on its IBM
mainframe database legacy systems built in
marketplace dynamics and consumer attitudes and behavior the 1980s to process this huge amount of
retail POS data. However, to keep process-
ing costs low for ACNielsen, the main-
to clients in more than 100 countries. ACNielsen’s products
frame system was designed to process only
a small sample of stores. While the sam-
and services include a wide range of market research and ples, designed by ACNielsen statisticians,
delivered high reliability, clients were not
analytical tools that retailers and manufacturers use to fully satisfied. “Our clients and the com-
petition are pushing us to be able to process
understand competitive performance, uncover new all stores,” explains Jean-Paul.
To meet client requirements and com-
business opportunities, and to raise the profitability of their bat competitive pressures, ACNielsen has
begun replacing their legacy mainframe
marketing and sales campaigns. environment with IBM AIX-based servers
that run Oracle databases. The new archi-
tecture consists of an AIX server with 24
CPUs that houses the data and metadata

P
roviding these types of analytics to its ner is so critical to ACNielsen’s business that and seven AIX servers with eight CPUs
large customer base requires Jean-Paul Moron, New Factory Application each that handle data aggregation. On the
ACNielsen to capture retail point of Management Director for Europe, calls the front-end are an additional seven servers
sale (POS) data such as detailed retail meas-
urement and consumer purchasing infor-
mation. Each week as many as 100 mil-
lion rows of data are added to the compa-
“Oracle is very committed to this project. Since
ny’s backend database, a number which this project is so large, we’ve had lots of support
will grow as the company expands this
project to additional countries across from the Oracle technology lab to ensure that
Europe.
we’re optimizing the technology.”
Data Drives the Factory
Being able to deliver an analysis of this technology infrastructure that manages this with 16 CPUs each that host data marts
information to its clients in a timely man- data a “factory.” “This is not a traditional and provide client access.

1
 CaseStudy
Across Europe
Currently ACNielsen is processing data
for clients in five European countries. Each
week the company receives POS data into
a backend server which stores approximate-
ly seven terabytes of data.
The company supports an incredible
4,200 data marts, each holding on average
about five gigabytes of data. All told,
ACNielsen stores and processes approxi-
mately 25 terabytes of information.
In order to meet their clients’ informa-
tion requirements, ACNielsen needs to be
able to process data for half of the 4,200
data marts within a 72-hour window. “We
require extremely fast processing,” explains
Jean-Paul. “We need to generate 13 ter-
abytes of data in less than 72 hours. There
is no way our legacy environment would
be able to handle that amount of data in
that short a period of time.”
ACNielsen will soon expand this tech-
nology infrastructure to support all of the
European countries it does business in.
“We need to generate 13 terabytes of data in
less than 72 hours. There is no way our legacy
environment would be able to handle that
amount of data in that short a period of time.”
Once complete, the infrastructure will store
and process an enormous 120 terabytes of
data. Scalability was critical to support this
growth. In fact, when they started the proj-
ect ACNielsen had only three aggregation
servers and two data mart servers and has
2
been able to increase the number of servers
without changing the underlying business
applications. “We designed the infrastruc-
ture to support growth,” says Jean-Paul.
Database maintenance is made easier
using Oracle Partitioning, which allows
ACNielsen to split up their databases into
smaller, more manageable components, says
Jean-Paul. He explains that they use parti-
tioning extensively on the backend data
warehouse, partitioning the data both by
time and by country.
Partnership is Critical to Success
ACNielsen not only selected the Oracle
database to power these applications, but
partnered with Oracle to do the actual
development. “Oracle is very committed to
this project. Since this project is so large,
we’ve had lots of support from the Oracle
technology lab to ensure that we’re optimiz-
ing the technology,” says Jean-Paul. “We felt
that Oracle was the only database compa-
ny that could provide this level of sup-
port,” he adds.
The project is coming in on time and
on budget. The Oracle team has been able
to complete 17,000 man-days of work
within the projected 18 month timeframe.
ACNielsen is pleased with Oracle’s abil-
ity to provide the manageability, perform-
ance, and availability of their very large
databases that ACNielsen counts on to pro-
vide its clients with the information they
need to run their businesses. ■
Lessons Learned from Large Databases how cutting-edge
organizations are exploiting database partitioning in order to
reap big rewards
by Michele Hope

Agility. Quickness. Responsiveness to subtle (and not-so-subtle) changes in the market. All are
characteristics usually found in abundance within today’s cutting-edge organizations. These are companies
that have managed to wrestle a leadership position from competitors despite the odds, and have since been
able to maintain that position through continued innovation and careful investment in the resources that
have gotten them there.
A look “under the hood” of such organizations often reveals a humming IT environment that reflects
many of the same characteristics of the larger whole. Typically, what you’ll find upon closer inspection is a
rich and complex database environment as the primary engine that propels many of the company’s strategic
and day-to-day decisions.
Yet, as database sizes continue to mushroom from gigabytes into multiple terabytes, it has become
increasingly important to look at how well the database “engine” is designed to withstand sudden shifts in
business focus, expansive growth and the ongoing strain of user demands put upon it. Economics often
enters into the picture, as IT teams struggle to balance the value of making database environments faster,
more available and more easy to manage, and scale against the economic reality of having to “make do”
with existing resources.
As part of this balancing act, database teams have had to grapple with a number of issues, including how
best to make the database design aid — not hinder — the work of multiple concurrent users submitting
transactions or querying the system. Service-level agreements (SLA) often prompt database support teams
to achieve strict, time-based criteria surrounding database system availability, performance and
manageability. In their efforts to use costly data storage systems most efficiently, many database
environments also have begun trying to define a larger information life cycle management (ILM) strategy
to help them assign the most critical and frequently accessed data to the best-performing storage resources,
while older, less critical data is shifted to more cost-effective “nearline” and “archive” storage systems.
Lessons can be learned and applied here from the common practices of large database environments.
This special report evaluates the benefits of one such practice: the use of a somewhat little-known database
feature called database partitioning that Amazon.com Data Warehouse Manager Mark Dunlap once
described as the “‘secret sauce’ that makes the system work.” Database partitioning allows a large, logical
database to be divided into distinct, independent parts. This functionality, when implemented correctly,
allows IT organizations to see large gains in system manageability, availability and performance.

About the Author

Michele Hope is an independent writer based in Miami. She covers enterprise IT and storage topics for a
variety of private clients and IT publications, including Network World and InfoStor magazines. She can be
reached at mhope@thestoragewriter.com.

Why Talk About Database Partitioning?

In the world of DBAs and software developers, much has already been written about the technical steps
involved in partitioning large database tables and indices into smaller, more manageable subsets. After all,
the act of partitioning databases is not new. Time-based (or “range”) partitioning functionality actually has
been available for more than 10 years from established enterprise database vendors.
Examples also abound of SQL code used to build or query such tables and partitions, based on various
partitioning methods. These types of partitioning exercises can be found readily in everything from books
on database fundamentals to database vendor documentation, such as the Oracle Data Warehousing Guide
or an IBM Redbook on database strategies for DB2 UDB.
Yet, while these resources readily address the mechanics of database partitioning, they often spend less
time exploring the often-instant benefits to be gained in today’s real-world environments through the
effective use of this feature.
Jonathan Lewis, a recognized Oracle specialist, director of the Oracle U.K. user group and author of the
book Cost-Based Oracle — Fundamentals, has spent a lot of time looking at how organizations can make

3
their database operations more effective. He readily offers his own caveats on the use of database
partitioning in this context.
“With partitioning, you have to know what you’re doing and why you’re doing it,” he says, making a
point to reiterate one fundamental of good database design: understanding the data and the users’
requirements for visiting it. “If you get it right, database partitioning can mean the difference between the
system taking all day to get a job done or half an hour. It can mean the difference between supporting 10
users without partitioning or 100 users with partitioning. It’s that kind of degree of difference we are
talking about.”
Lewis has hit upon one of the most commonly known benefits of proper database partitioning: dramatic
performance gains in database query processing times. Often, other database performance enhancement
techniques work well in conjunction with database partitioning as well, such as parallel processing and, in
the case of an Oracle system, the use of materialized views.
Lewis puts it this way: “If you find out the way customers are asking queries, and you make sure you
slice the data up into partitions to match those types of queries, you’ll get a win. You’ll get a certain ‘cost-
nothing, free-of-charge’ performance improvement for running queries.”
Noel Yuhanna, senior analyst at Forrester Research, reiterates this point. “Instead of running a
COMPASS (Context-Oriented Multi-Format Portal-Aware Search System) query in an hour, partitioning
can bring this type of query down to minutes,” he says.
However, beyond obvious performance gains database partitioning also can bring some other,
unexpected benefits to large database environments:

ƒ Improved manageability for behind-the-scenes database operations (backups, optimized load

processes for “rolling windows” in data warehouse environments, etc.). In some vendor
implementations of database partitioning, data management procedures can be performed on an
isolated partition basis, while other partitions remain available and online for production use. Data
partitions also can be more easily migrated or copied to other locations.

ƒ Improved data availability. With partitioned tables, scheduled downtime can be performed in
isolation, only on specific partitions, without requiring a whole table to be put out of commission.
Also, by splitting partitions onto separate physical tablespaces, it limits the impact of a storage
hardware or disk failure to just individual partitions, as opposed to a wider effect to a large table
whose entire data might suddenly become unavailable.

ƒ A working foundation for data life cycle management. Organizations concerned with
maximizing the invest-ment in their current data storage infrastructure can use database partitions
to identify and easily migrate less frequently accessed or historic data from high-performing
storage “tiers” to lower-cost or near-line disk storage, all transparently to the host application.
Database Partitioning: The Basics
Historically, those who have found the most benefit from database partitioning have had one or more of
the following characteristics present in their environment:

ƒ Database systems supporting mission-critical

applications.

ƒ Systems characterized by high-volume OLTP

workloads.

ƒ Database systems supporting OLAP, DSS, data

warehousing or data mining activities.

Some proponents of database partitioning see an even broader application for its use. “In large enterprise
environments, as soon as you have single objects getting larger than 1 to 10GB, partitioning can make
sense,” says Hermann Baer, a principal product manager for data warehousing at Oracle. Baer notes
occasions where customers have been able to use partitioning to break up data in an important table and
thus isolate risk that the overall table will become unavailable. Such an approach, he says, also allows for
more rapid recovery of isolated partitions from various types of disruption.

4
 Forrester’s Yuhanna has seen partitioning used most of the time in data warehousing environments,
where the motivation for use is fairly straightforward. “If you have a large database, you want to manage it
in chunks to perform better data management. The major focus of database partitioning over the last decade
has been on data warehouses and data marts, where you break down those queries into smaller units so they
can run in parallel on different partitions,” he says.
“It’s divide and conquer. You divide the data and conquer. If you have large amounts of data running on
a single processor, that query can be decomposed into smaller units that run concurrently with multiple
processors, where each processor goes after a single partition of data,” Yuhanna says.
Database vendors have different ways of implementing database partitioning, with some offering more
ways to slice and dice the data than others. The most common database partition-ing method is to split up a
larger, time-based table — like a table containing sales data — into individual partitions by week, month,
quarter or year. This is known as range partitioning because it allows a range of dates or numbers to be
represented in the partition, with obvious start and end points for the range. The accompanying figure
shows a typical sales table partitioned by month.
Once the partitions have been defined in a table, queries that run against the table typically are
optimized to automatically “prune” unnecessary partitions out of the query process before running the
query. For example, if you want to analyze all of the sales made for the last two weeks of April, your query
would go to the sales table and automatically process data from just the “April” partition of the table,
versus data from all 12 partitions. Users don’t need to know about the partitioning structure, either. Queries
use the same language, whether the table is partitioned or not. What’s different is the underlying efficiency
partitioning now builds into the process.
This process can result in significant reductions in processing time. Baer explains it like this: “In the
most simple example of a time-based partitioning strategy partitioned by month, you might only want to
look at the last month (or one-twelfth) of data in a table. That means the resources to satisfy the business
request are also one-twelfth. Staying with this simplistic example, you could then theoretically run 12 times
the number of users on that same hardware or make queries run 12 times faster.”
One user who presented at Oracle OpenWorld put the use of partitioning in a data warehouse into more
practical, real-world perspective. When asked what Oracle database features had been most beneficial for
his data warehousing needs, Jay Parmar, the head of data at U.K.-based financial services provider Egg,
responded as follows: “From a data warehouse perspective for Egg, parallel queries, materialized views and
partitioning have been incredibly useful because we’ve been able to drive perfor-mance from our
warehouse and provide the speed of information that my customers are asking for.” Egg moved from
outsourced data warehousing services with six week latencies to a near real-time, internal data warehousing
service with less than 24 hours of latency. “My internal users want data even quicker and faster than ever,”
he said.
According to Baer, many organizations begin simply with range partitioning as their most common
partitioning technique. This technique alone quickly yields them large gains in performance and database
operations.

5
Sample of range partitioning in a “Sales” table that is separated into individual, monthly partitions.
Source: Oracle Database 10g A Beginner’s Guide by Ian Abramson et Al (McGraw-Hill/Osborne 2004)

Going Beyond the Basics

As database environments grow and adapt to meet the changing needs of the business, they often are
faced with situations where other partitioning methods may prove useful as well. Beyond range
partitioning, other partitioning methods also are supported to varying degrees by database vendors as well
(see figures below).
These include:

ƒ List partitioning. This method allows you to assign a list of named values to each partition. For
example, some database tables might be able to be partitioned based on geographical lines, such as
region, state, unique retail store identifier, etc. In this case, you could all sales data for the Canton,
Ohio, store in one partition
and sales data for the Poughkeepsie, N.Y., store in another partition. Likewise, you could partition
by region.

ƒ Hash partitioning. This method is often used to perform a more specific load balancing or data
clustering function that evenly distributes the data in a large table into any number of partitions.
Contents of each partition are not always as easy to correlate to their related business context
because the partitions are not usually identified with an obvious range or list moniker, such as
Sales_West or Last_Month_Sales.

ƒ Composite partitioning. This method allows two partitioning methods — such as Range/Hash or
Range/List — to be combined within a given table. In these scenarios, a higher-level range
partition usually is established with a series of subpartitions beneath it. This type of combined
partitioning functionality might be used in situations where data might need to be searched by time
and region simultaneously, for example.

6
7
 Experts maintain that the more flexible options you offer
customers when it comes to partitioning, the more likely they will be able to mix and match functionality to
meet the business needs of their environment. They offer a few other partitioning scenarios to consider
when exploring the various vendor implementations of database partitioning.

Scenario #1: Queries by Time and Geography

Both report queries and common database maintenance functions often can be geographically driven as
well as time-driven, especially in larger environments. These might lend themselves to some type of
composite partitioning strategy that combines range with list partitioning.
“Larger enterprises might not only have time as a common criteria, but also region. The usage pattern
for working on Europe’s data or America’s data, doing things like loading or accessing data, may be
different as well. When we are asleep, the guys in Asia are hopefully busy,” Baer of Oracle says.
Lewis, the Oracle specialist, also notes this benefit of regionally separated partitions. “Let’s say you

8
have a sales table, partitioned by time and region [or list] into two to three regions like Europe, America,
etc. If I run a query comparing Europe to America, I can just run it against the specific partitions in the
table to which it applies. Then, when everyone goes to sleep in Europe at 9:00 p.m. our time, that’s just
when America is getting active,” he says. “So, at that time, you can do maintenance on the European
partitions while those in America aren’t ever touched. It allows you to act as if you’ve got each region in its
own separate table for maintenance purposes.”

Scenario #2: Ease of Adding, Moving, Deleting Partitions

Many data warehousing and maintenance operations may deal with specific portions of a table.
According to Baer, these tend to naturally lend themselves to the use of partitioning, which allows
operations to be performed on an isolated partition-by-partition basis, without affecting user access to the
rest of the table.
Partitioning has been used in this case to support what’s commonly known as a “rolling window” in data
ware-house environments, where new data needs to be added on a consistent basis, often via some type of
ETL process, and old data simultaneously is moved off the system.
In this situation, it pays to check with your database vendor to see how easy it might be to support
wholesale moves, deletes or additions of partitioned data from one tablespace or location to another. This
functionality also makes it easy to move into a smarter way of utilizing expensive storage assets, by
partitioning more frequently accessed partitions and pairing them with high-performance storage, while
less-frequently accessed systems might be moved to larger but slower storage devices.
Lewis describes this process as follows: “For data changing very rapidly, you might decide to partition it
and put that onto four times as many disk spindles and stripe the data to get the best possible performance.
Then, as time passes and the data becomes older and no longer critically high or active data, you might
decide to copy it down from one place to another to get to the slower disk. How do you actually say,
‘Here’s this 30GB chunk of data, now going from high-speed, busy and active to the lower- speed, less-
interested bit?’ How do you move that? You want the chance to rearrange it. That’s where partitioning
helps.”
Because your mileage may vary in these wider applications of partitioning, depending on the database
vendor package you are using, it pays to check first with the vendor about how far it may go in supporting
some of these more advanced partitioning scenarios.

When Smaller is Better

The concept of database partitioning is not accompanied by much sizzle or flash, but is something savvy
environments readily embrace as a critical design component for growth management and streamlining
even the most critical and intensive database operations.
Despite its effectiveness in high-end settings, the current use of this functionality presents a strange
conundrum. Those “in the know” take it for granted as a sound design practice they would not think to
exclude when building or supporting data warehouse and decision support environments. The Data
Warehousing Information Center, supported by Larry Greenfield of LGI Systems, lists partitioning as
“probably the second most common method of speeding up queries.” The center also goes on to suggest
that anyone wanting to learn about data warehousing should take care to start learning about some
“fundamental technical topics” that include “how database partitioning can be used in conjunction with
logical structures.”
Likewise, author Scott Ambler of Ambysoft, in his book Agile Database Techniques, published by John
Wiley and Sons, recommends table partitioning as one design strategy to help support more “performance-
friendly” reporting.
Customers that have cut their teeth on the process and seen its results are quick to note the dramatic
changes it’s made in their own operations. Brian Kalmar, a solution architect at national food retailer Giant
Eagle, noted recently in an interview at Oracle OpenWorld that database partitioning had been one of two
essentials to achieving the levels of performance required from the company’s four Oracle-based data
warehouses.
“We run our machines very hard. We throw a large number of parallel processes at the machines and
we try to get our data back as quickly as possible because it’s critical for our business decisions,” Kalmar
says. “Partitioning and parallelism are the keys to data warehouse performance. Breaking out a table that’s
billions and billions of rows into smaller chunks allows us to get at the data quickly. Parallelism, throwing
a number of child worker processes at a SQL query or DML statement, allows us to get the data much

9
quicker also.”
Yet, despite such widespread support for partitioning, Yuhanna estimates that only 10% of companies
currently use it. Why? Is it because its benefits are often carefully buried in the depths of operating manuals
and SQL code snippets? Or, because companies simply don’t realize this type of functionality is already
available to varying degrees within most database vendors’ enterprise-level offerings?
More likely, one culprit behind its slow adoption is the fact that most organizations simply do not have
the luxury of looking “under the hood” of high-end database environmentsto see what really makes them
tick. This report offers a high-level glimpse into the benefits such environments have achieved through the
simple application of one operational feature like database partitioning. The ability to support more users,
more processing and more back-end operations without a perfor-mance hit is almost always the end result
of their efforts.

Conclusion
With the number of multi-terabyte installations expected to double in the next few years, and annual
data growth approach-ing somewhere between 30% and 100%, partitioning the data-base to “divide and
conquer” is a process many of today’s cutting-edge organizations already have accepted without question.
“There is not a single large customer we speak with who is not using partitioning for data warehousing,”
Baer says. “Their automatic assumption is, ‘If I have large objects, I’ll need partitioning.’”
The performance benefits and effectiveness in scaling such partition-minded systems are probably the
biggest reasons organizations tend to purchase this functionality, he says. Baer also says it’s only a matter
of time before other enterprise organizations also will be attracted to this unsung feature for many of the
same reasons.
Whichever way you approach the equation, the end result of effective partitioning boils down to one simple
truth: To make something big (and getting bigger) act as if it were small. That seems as good a building
block as any toward achieving a more agile, adaptive IT environment.

Partitioning in Action at Amazon.com

A few years back, the WinterCorp, a large database consulting and market research
firm, produced a report, “Field Experience with Large-Scale Data Warehousing on
Oracle,” that outlined the experiences of several large-scale Oracle data warehousing
customers.
One company it profiled was Amazon.com, which even then was heralded as one of
the largest and fastest- growing businesses on the Web. At the time, the company’s
online inventory of books and other products already amounted to millions of items,
being purchased by millions of customers in more than 200 countries around the
world.
Even then, Amazon’s large data warehouse environment already had mounted to
10TB of user data and was growing at a phenomenal rate of 100% each year. Average
user load was somewhere between 55 and 60 concurrent users, while peak query load
reached somewhere in the range of 4,300 queries per day. The largest of 600 Oracle
tables at the time contained more than 10 billion rows of Web click stream data. (The
most recent VLDB Survey from WinterCorp showed that Amazon’s data warehouse
had since grown to 25TB by 2005.)
As part of their initial research, WinterCorp Founder and President Richard Winter
joined with WinterCorp Vice President of Engineering Rick Burns to interview
Amazon Data Warehouse Program Manager Mark Dunlap. During the interview, they
asked how he had been able to support the needs of such a high-performance Oracle
system. Following is an excerpt of some of their findings.$
“Mr. Dunlap identified Oracle’s ability to support a high level of concurrency as a
key to the success of the Amazon warehouse. Amazon also relies extensively on
Oracle partitioning, external tables, the SQL MERGE statement, and Oracle’s
analytical and windowing functions. . .The warehouse environment is supported by
fewer than two DBA full-time equivalents.” The report goes on to note the following
regarding Amazon’s use of database partitioning:

10
 “Mr. Dunlap also credits Oracle composite partitioning with contributing in a major
way to performance. First, the many subpartitions enable highly parallel query.
Second, the time-based major partitions create a ‘free’ index. The Oracle optimizer
uses the information in the partition key to avoid accessing partitions that cannot
contain data relevant to a given query. Since many queries pertain to the most recent
month, week or day of data, the partition elimination is a powerful optimization. Mr.
Dunlap views partitioning as the ‘secret sauce’ that makes the system work.”
Interestingly enough, Amazon also credited partitioning with allowing a more
trouble-free migration of its large data warehouse from one physical data center and
hardware platform to another. This involved moving the database across country to
another Oracle instance running on a different hardware platform. The WinterCorp
report stated the following about this experience:
“The data was actually exported from the existing Oracle system, transferred via
high-speed network to the new data center, and imported into the new Oracle system
without ever writing it into a flat file. This was possible because of partitioning
features of Oracle, in which partitions of the database can be independently moved
from one system to another. About five partitions were moved in each export
operation. The migration occurred with essentially no disruption of user activities and
was virtually transparent to end-users.”
Amazon presents a good case of demanding customer needs that resoundingly met
their match with the proper use of database partitioning.

Source: WinterCorp.

© 2006 Network World, Inc. All rights reserved.

Migrating from Teradata to Oracle

Three Customer Case Studies
Introduction
Enterprises using NCR’s Teradata data warehouse platform can find themselves facing several ongoing
challenges. These challenges include the high costs of Teradata proprietary software and hardware
upgrades, a restricted selection of technology partners and third-party tools, and a limited pool of
individuals with Teradata skill sets and expertise who command premium rates. Many organizations have
discovered a more cost-effective alternative — migrating from their proprietary Teradata system to an open
Oracle business intelligence and data warehousing platform. They made the switch without significant
disruption to their core business activities and have realized considerable return on investment. This study
briefly enumerates the multiple advantages an Oracle platform has over Teradata, and describes how three
actual businesses have seized these advantages by migrating from Teradata to Oracle.

The Business Case for Oracle over Teradata

Advancements in technology coupled with the need for business change causes many enterprises to
reconsider data warehousing strategies that are based on proprietary data warehouse technologies such as
NCR’s Teradata. Data centers face rapidly changing business requirements and a demand for increased
productivity and efficiency, along with constant pressure to reduce expenses. Many are now taking a much
closer look at the cost of data center solutions and are evaluating the viability of Off-the-Shelf (OTS) and
commoditized hardware as part of the infrastructure, an infrastructure that Oracle can fully leverage.

Comparative Costs
A system using OTS hardware offers far more pricing choice over one using proprietary hardware.
Commodity hardware is subject to market competition that drives down prices. The use of OTS hardware
also leads to greater flexibility in tailoring purchases to company requirements, rather than having those
decisions driven by the vendor.
Teradata will most commonly position very expensive high-end servers for potential growth far in

11
excess of a customer’s real needs. By contrast, where customers’ expanding requirements demand
additional growth, Oracle’s scalable alternatives enable those customers to buy what they need when they
need it at current price points, which results in lower costs than a Teradata system entails. In some cases the
cost of merely upgrading a Teradata system is nearly as expensive as purchasing an entirely new one and
deploying Oracle on a commodity platform.
Oracle offers lower total costs for software, as well. Since Oracle is the data warehouse market leader, 1
widespread support exists among third-party software vendors. This not only reduces integration challenges
in a given enterprise, but also drives down costs through the same competitive market principles that apply
to OTS hardware.
Finally, the consolidated architecture of Oracle’s solution reduces costs. Oracle’s database comprises
ETL, OLAP, and data mining, eliminating the need for multiple specialized business intelligence servers.

Cost of Administration and Deployment Skills

Oracle’s integrated solution dramatically cuts the ongoing expense of licensing, training, and
administration compared to multiple specialized intelligence solutions. A single-vendor, integrated solution
for data warehousing and business intelligence also reduces the risks and costs involved in integrating
disparate products. Since Oracle Database 10g is completely integrated with Oracle development and
business intelligence tools, organizations can rapidly develop efficient business intelligence applications,
further expediting ROI.
Oracle has a much larger installed base than Teradata, so Oracle expertise is much more readily
available among data warehousing administrators, consultants, and designers. A recent search of Oracle
skills on the Monster.com jobs portal revealed over 5,000 entrants listing Oracle skills, compared to only
85 listing Teradata knowledge. Teradata experts are typically more difficult to find and retain, and often
command premium salaries.

Better Performance
Hundreds of Oracle’s customers have successfully deployed multi-terabyte data warehouses on a variety
of 64-bit SMP and NUMA platforms and on RAC Linux clusters using commodity platforms. Oracle
Consulting Services and Oracle’s partners have built thousands of Oracle data warehouse solutions,
including data marts and enterprise data warehouses well into the tens of terabytes. Because they deploy
OTS mid-range servers, these solutions are much more cost-effectively scaled to keep pace with a data
center’s growth.
Oracle’s consolidated server and storage model simplifies the enterprise data infrastructure, reducing
administrative complexity and increasing the productivity of an organization’s staff. This superior
architecture can result in a host of performance related benefits, including:

ƒ Better data access and improved query performance.

ƒ Extraction times reduced by as much as 50 percent.
ƒ The ability to quickly produce canned reports.
ƒ Native connectivity and extended support through a variety of Oracle BI tools and partner
products.
ƒ Tight integration of analytics and data mining in a single database engine, enabling high-
performance analysis without introducing the need for costly time delays associated with moving
data into data marts.

Emerging Trends
Oracle’s technology is designed with an eye on the future. It accommodates next generation
warehousing, which require a scalable database that can handle high concurrency and updates (that is,
OLTP characteristics of near real-time data warehousing). Oracle Database 10g includes key features such
as built-in queuing, replication, and fast copy capabilities (Oracle Streams, Transportable Table spaces),
built-in XML capabilities for handling multiple document types and metadata, and built-in ANSI standard
SQL Analytic Functions and OLAP for sophisticated analysis in the database.
Oracle’s open standards approach and widespread ongoing support among third-party vendors gives
companies numerous options for designing best-of-breed business intelligence solutions tailored to provide
optimal performance. Oracle’s dominance in the market ensures that these partners will continue to develop
around emerging Oracle features well into the future.

12
 The following sections describe how actual companies have successfully migrated their data warehouse
solution from Teradata to Oracle, and how they have benefited as a result.

Case Study 1 – Tele2UTA Austria

When Tele2UTA acquired Netway, one of Austria’s most successful Internet providers, Tele2UTA
faced a decision. It had grown to become Austria’s leading provider of telecommunication services,
delivering phone services to 520,000 customers and Internet connectivity to 28 million customers in 24
countries. The company’s success relies heavily on the strategic use of business intelligence mined from its
1.5 terabyte data warehouse, which contains approximately 1.8 billion Call Detail Records (CDRs) and
grows by two to three million CDRs per day. The data consolidation required by the Netway merger could
not leverage Tele2UTA’s existing Teradata data warehouse, since Tele2UTA could not justify the price of
the needed Teradata upgrade. Upon investigation, Tele2UTA found that deploying an entirely new Oracle-
based solution would cost less than the Teradata upgrade alone.
“The high cost of upgrading the existing Teradata system prompted us to opt for an Oracle
infrastructure, instead,” says Kurt P. Buchleitner, Tele2UTA Austria’s Business Intelligence and Data
Warehouse Manager. “It now appears that our return on investment will be realized a year earlier because
we switched.”
In all, the system cost savings realized by moving to Oracle rather than upgrading the Teradata platform
amounted to 50 percent. Tele2UTA was able to move from high-end proprietary hardware to a fully
scalable Sun V880 midrange server with a much better cost-performance ratio.
“Why would we need such a large machine if we can get the same power with an Oracle database and
much smaller hardware?” asks Mr. Buchleitner in reference to the Teradata hardware proposal. In fact,
Tele2UTA was able to double the number of CPUs and increase memory (because the Oracle-based open
solution can support more memory). Mr. Buchleitner emphasizes that “this approach was still more cost-
effective than the Teradata approach of going to disk.”
The data migration went quickly, required minimal code modifications, and was completed in a little
over six months by Oracle Consulting. Most importantly, the migration caused no interruption in the
company’s core business operations.
“Personally, I did not notice there was a migration going on,” reports Rainer Roesner, Tele2UTA’s chief
controller. “There was virtually no disruption of our usual processes.”
Mr. Buchleitner reports that Teradata cast doubt on Tele2UTA’s ability to load the Oracle warehouse
successfully. However, the company not only accomplished it, they also improved query performance and
reduced extraction time by 50 percent — eliminating ongoing complaints regarding lengthy data upload
times. Mr. Roesner agrees, adding: “I think the most positive change was that before migration we
regularly received e-mails from the business intelligence team complaining that uploads had not been
successful and data was not up to date. Those e-mails have stopped altogether.”
A large part of the rapid ROI Tele2UTA realized is due to time saved in setting up and maintaining the
data warehouse system, time now spent on strategic development for their business users.
“We are able to implement our users’ requirements much faster than before,” Mr. Buchleitner says.
“Our development production has increased roughly 300 percent without any added expense.”
Contributing to these impressive results is Tele2UTA’s ability to leverage widely available in-house and
external Oracle expertise, coupled with Oracle’s lower learning curve. Teradata administrators, by contrast,
were always difficult to locate and commanded as much as three times the salary.
One of the most important benefits gained by the switch is the ability to create and deliver reports with
integration to an enterprise portal within a matter of minutes — an efficiency-boosting feat entirely
impossible with the Teradata system.
“Our data warehouse went from an analytic island to a fully integrated open system,” Mr. Buchleitner
explains.
The migration has ushered in a new era for Tele2UTA’s business intelligence. It has given Tele2UTA
virtually unlimited information access. Data sources previously difficult to reach using the Teradata system
can now be accessed quickly. End users can retrieve information quickly and easily using tools of their own
choice. For example, Oracle Reports, Oracle Discoverer, or JavaServer pages are now all made accessible
through a portal built with Oracle Application Server Portal.
“Users are happy, because information can be retrieved easily, analysis is consistent and comprehensive,
and there is high performance in response time," Buchleitner says in summation. "Our financial managers,

13
controllers, and board members are also pleased that the new system has reduced total cost of ownership. In
just a short time, our decision to migrate to Oracle has been fully validated in many ways.”
Case Study 2 – Saudi National Commercial Bank

National Commercial Bank (NCB), based in Saudi Arabia with branches worldwide, is the largest bank
in the Middle East in terms of capital. Serving over one million clients as of year-end 2005, the bank
operated 261 branches throughout the Saudi Kingdom. The bank also operates a comprehensive array of
alternative channels for services delivery, including Telephone Banking, Mobile Banking, Online Banking,
Trade, International Brokerage, and an innovative SMS Service, which provides its customers with easy
and secure contact with their NCB accounts via mobile telephones. With over 80 percent of customer
transactions executed through alternative delivery channels across multiple lines of business during fiscal
year 2005 alone, NCB requires an effective way of creating a single view of its customers as a basis for
delivering personalized service and innovative products.
The NCB data warehouse, with more than a terabyte of rapidly growing data, is key to its ability to
provide unparalleled customer service and to target its customers with personalized services.
Faced with the need to upgrade NCB’s Teradata Warehouse in order to meet performance requirements
on its expanding data, the decision to migrate from Teradata to Oracle was first and foremost based on the
significant incremental savings NCB would realize by migrating its data warehouse from Teradata to
Oracle instead of upgrading its proprietary Teradata platform.
“When we wanted to upgrade, we were limited by Teradata to NCR hardware and Teradata’s own flavor
of the UNIX operating system, which is very expensive,” reports Mr. Nadim Qurashi, NCB’s Decision
Support Systems Manager. “With Oracle we had a choice of hardware, which saved us a significant amount
of money. In fact, moving to Oracle resulting in a 50 percent savings on an ongoing basis when considering
the support contracts.”
NCB’s savings from migrating to Oracle extends beyond hardware and support. NCB is now able to
take advantage of significant savings from the high availability of Oracle DBA resources.
“We employ two full-time and one part-time DBAs to support our data warehouse,” explains Mr.
Qurashi. “While we required the same number of FTEs to manage our Teradata data warehouse, Teradata
skills are much more expensive, at least 50 percent more expensive, and difficult to find. Oracle is
becoming a standard; even graduates know Oracle better than any other database.”
By migrating to Oracle from Teradata, NCB is able to do significantly more with much less computing
resources, which results in substantially improved performance per unit of cost.
“The upgrade reduced our load time and increased performance for our two key applications, reporting
and billing,” notes Mr. Qurashi. “We were able to achieve our goals for 400 percent better performance
with less cost by moving to Oracle. If we used equivalent hardware to achieve the same performance
results on the Teradata, it would cost three or four times the price than what we paid to migrate to Oracle.”
NCB is an up-and-coming bank that must rapidly respond to changes and opportunities to retain and
grow its customer base and to deliver innovative products and services. Therefore, the ability to rapidly
build new applications to meet customer needs is a paramount requirement. According to Mr. Qurashi,
Oracle is more open and integrated with third-party tools via native support and has its own OLAP
capabilities within the database, both of which allows his developers to more rapidly build new applications
to meet customer needs. Teradata does not have its own OLAP product and supports third-party tools only
via ODBC, rather than via native support. This makes it more difficult and time consuming to build and
maintain new applications on Teradata.
NCB was initially concerned about the time, cost, and potential disruption from migrating the existing
Teradata warehouse to Oracle. With the help of skilled consultants at Oracle, plus internal expertise, the
migration went quickly and smoothly without disruption to the business.
“Oracle consulting helped NCB complete the proof of concept, but we were able to complete the
migration internally with our existing Oracle skills, says Mr. Qurashi. “Migration went very smoothly,
requiring around five months from start to finish, including all the loading scripts and conversions from
Teradata and loading of the data.”
The decision to move from Teradata to Oracle came down to hard dollars and cents per unit of
performance.
“Business users are much happier because their reports are taking less time than before,” Mr. Qurashi
reports. “IT is happy because our cost per unit of performance is much more favorable with Oracle.”

14
Case Study 3 – A Global Semiconductor Company

For this leading international semiconductor manufacturer specializing in producing chips and software
for all types of technology — including cell phones, PCs, PDAs, hard drives, and gaming devices — the
decision to migrate from Teradata to Oracle came down to dollars and cents. The company attributes a
terabyte-sized data warehouse as a key ingredient to its success in serving its customers.
The company realized significant incremental savings by migrating its data warehouse from Teradata to
Oracle. Eliminating the incremental Teradata support costs and the additional Teradata specialists needed
to maintain the Teradata warehouse netted over one million dollars in hard dollar savings. In addition,
eliminating the depreciation of Teradata’s expensive, proprietary hardware resulted in over two million
dollars savings directly to the P&L.
“We have a group of Oracle DBAs who could not be leveraged to support our Teradata warehouse,” the
company’s Director of Data Warehousing reports. “With the migration to an Oracle data warehouse, our
staff can be much more efficient as hard-to-find Teradata specialists are no longer an ongoing additional
cost and risk.”
The Director adds that, prior to the conversion the company needed the working equivalent of 1.5
Teradata specialists to maintain its Teradata warehouse, saying: “with the Oracle data warehouse, we don’t
need a dedicated DBA — one of our existing Oracle DBAs maintains the Oracle warehouse with less than
one half an FTE. We saved real hard cash by making the switch to Oracle”
The company is also an Oracle E-Business Suite customer and evolved its data warehouse strategy in
the middle of an Oracle E-Business Suite 11i upgrade.
“Eventually, we’ll embed our data warehouse in our application database, which would not be possible
using a Teradata system,” says the Data Warehouse Director. The company currently uses Cognos
PowerPlay in conjunction with its data warehouse, and the switch from Teradata to Oracle was transparent
to users. “We plan to take advantage of Oracle Business Intelligence 10g’s integration with the Oracle
database and its productivity and ease-of-use features, down the road,” the Director adds. “Getting the
warehouse in Oracle was the first step.”
The actual conversion took place over a long weekend without any glitches or disruptions to normal
operations. After conversion, a handful of issues arose, but those were quickly remedied with tuning, and
the same level of functionality and performance was achieved at 50 percent of the cost — the company’s
primary goal. Total time to full production of the Oracle data warehouse was nine months, which included
building the business case, getting the necessary buy-in, and migration.
The company’s key decision driver was to take dollars out of the budget. According to the Director of
Data Warehousing, “now we can leverage Oracle’s openness and flexibility… Upgrading is much easier,
and we can now fully leverage Oracle’s integrated tools.”

Conclusions
As amply demonstrated by the case studies presented in this report, businesses can realize numerous
cost-saving and productivity-enhancing benefits by migrating their enterprise data warehouse systems from
a proprietary Teradata platform to a platform based on Oracle technology.

Key benefits include:

ƒ System Costs — Teradata relies on high-end, proprietary servers and surplus resources to
accommodate future demand, while Oracle incorporates much more cost-effective midrange
servers that are scalable to meet increased system demand as needed. Upgrading a Teradata
system can cost more than deploying a new Oracle solution.
ƒ Cost of Ownership — Oracle’s database has built-in business intelligence functionality and also —
being the data warehouse market leader and embracing open standards — interoperates with many
widely-used third-party software products. Oracle’s integrated development tools expedite the
creation of customized business intelligence functionality, as well.
ƒ Enhanced Performance — Users in the companies described here have experienced greatly
enhanced performance in migrating from Teradata to Oracle. Business line executives also
reported no noticeable disruption to data service operations.

Perhaps most invaluable from the long-term perspective is Oracle’s ability to offer a data warehouse
solution designed with the future in mind. Easy scalability, interoperability with third-party software, the

15
ability to implement the latest in technology advances — these characteristics are required in today’s
rapidly changing business environment. Oracle offers the assurance that an enterprise’s data warehouse
capabilities will keep pace with any change the future may bring.

Printed in the United States of America.

Copyright © 2006 The Edison Group, Inc. New York. Prepared for Oracle. The Edison Group offers no
warranty either expressed or implied on the information contained herein and shall be held harmless for
errors resulting from its use. Oracle is distributing this document and offers no warranty either expressed
or implied on the information contained herein and shall be held harmless for errors resulting from its use.

All products are trademarks of their respective owners.

First Publication: March, 2006
Produced by: Craig Norris; Analyst / Writer; Barry Cohen, Editor

16