give you the “Part of Tens” detailing benefits you will experi-ence by implementing Oracle Exadata in your organization.
Icons Used in This Book
Throughout this book, we occasionally use icons to call attention to important information that is particularly worth noting. Here’s what to expect.
If you see an icon that says remember, you may want to, uh, remember the information. We won’t have deep meaning-of-life stuff, but it may be good to know for later.
Sometimes you just have to know a term or technical details to understand a larger topic. Or, it could just be that we want to throw in cool terms to try to impress people. Either way, this icon identifies techie stuff.
This icon usually denotes something the author wishes some-one had told him before he learned it the hard way! Keep these items in mind to make life easier.
Where to Go from Here
Hey, it’s your book so feel free to jump around wherever you’d like, or simply turn the page and just start reading.
Today’s Database Challenges
In This Chapter
▶ Modeling current database architectures
▶ Identifying database challenges
▶ Finding a better solution
T
oday’s business challenges dictate fast, agile, and reli-able IT solutions, but those solutions must be secure and within the budget. At the core of any IT solution is the data, and that data is stored within the database. It stands to reason, therefore, that the database is the most important part of any IT solution.Database technology has evolved over several generations of architectures due to both technological advancements (hard-ware and soft(hard-ware) and business drivers. Today, it is often the needs of business that determine the direction of database technology and architecture to meet those needs.
In this chapter, we examine today’s database architectures and the challenges they face.
Current Database Architecture
To understand the role of a database and what the key factors for a successful database are, you need to understand the role of the database in an IT system. Essentially, a computer appli-cation provides a user with the ability to perform some task
(such as ordering a product or service). All the data used to support that task is stored in the database.
A modern IT system is generally composed of the following components:
✓ User. Very often a human sitting in front of a keyboard interface using a computer system. That user may be a customer or an employee. The interface may be a client side program or it may be a web browser, but that isn’t always the case with the growth of smartphone technol-ogy and similar devices.
Increasingly, however, the “user” is another computer system interfacing with the application. It is not uncom-mon to have automated system-to-system interfaces such as web services.
✓ Application. The program or “application” that executes logic to present the data to the user and implements the business logic to manipulate that data. The application can execute on the client’s workstation or device, on a dedicated application or web application server, or on the database server.
Often the application is distributed between components with a visual component at the user interface level, busi-ness processing on the application server, and heavy data-manipulation functions at the database server level.
✓ Database. The software component that stores and manages the system’s data. Data is organized in logical containers called tables. Each table is mapped to a physi-cal storage device, which is often a disk. User accounts are created with security and business rule logic imple-mented to dictate what data a user can see and how that data is created, updated, and deleted.
Database processing is often very intensive because enormous amounts of data are processed as part of each application request. Because of this, database software itself is often a specialized component that exists on one or more dedicated database servers.
✓ Storage. Data physically stored on a storage device and accessed by the database. The storage device itself is often disk, but it can also be a solid state flash drive for fast access or tape storage for archival access.
Storage devices are frequently attached to the database server over a network rather than being an internal disk within a server. This is because storage requirements exceed what a single server can hold internally, or the storage is shared to support multiple database servers.
Storage devices themselves are often “smart devices” that have their own memory components, management tools, and processors to assist in performance and reliability.
✓ Network. Communication between the user and appli-cation server is the first network component. Within the system itself, there are many network connections between components. Between the application server and the database server is another connection. From the database server to the disk storage array is another network connection. Other connections between compo-nents and subsystems are common.
The technical details for a network connection depend on which components are communicating. For example, the connection between a client’s web browser to the web application server is different than between a data-base server to its disk storage. However, common net-work requirements exist regardless of the netnet-work type;
the network needs to be fast, secure, and reliable.
“In the Cloud”
A recent architecture gaining vis-ibility is cloud computing. Cloud computing is an approach in which instead of the client accessing a specific set of servers to perform a specific application function, that function is accessed as a service on the Internet or intranet. The
“cloud” is the network to which the user sends an application request and from which the user receives a response.
Cloud computing is an advanced architecture that promises to lower costs and improve service because the same application is shared by everyone in the “cloud”; software becomes a shared service. Oracle is highly interested in cloud comput-ing, and in later chapters we discuss how Oracle’s products support this architecture.
Database systems fall into three general categories: OLTP, data warehousing, and hybrids.
On Line Transaction Processing
On Line Transaction Processing (OLTP) systems are used to process transactions and perform work in a real-time, online manner. These are the most common database systems and are what often do the “work” for a business. OLTP means thousands of users simultaneously executing small, quick transactions.
A prime example of an OLTP system is a call center applica-tion where customers call or order online a company’s prod-uct or service. This system may entail order entry, billing, customer data, shipping, and inventory components.
Characteristics important to an OLTP system include ✓ Availability. If the system isn’t available, the company
won’t generate revenue and will lose customers. System uptime is very important to OLTP systems; every minute of downtime has a dollar value of lost revenue associ-ated with it. Architectures that allow the OLTP system to remain available even during computer failures are highly desirable.
✓ Performance. If customers have to wait excessively for processing to occur or if their process fails due to a time-out error, they’ll go to a competitor. At a minimum, fewer customer orders will be processed in a given time period.
Poor performance leads to frustrated customers and as a result, high throughput performance and low latency is critical for OLTP systems.
✓ Agility. New business opportunities or regulatory requirements must be met in a rapid manner. Failure to anticipate and react to changing needs can be disastrous.
A computer system must be able to be modified to meet changing requirements in an agile manner.
✓ Security. OLTP systems are prime targets for thieves and competitors due to the nature of the data they contain.
Security breaches are costly beyond just what is stolen;
loss of customers, damaged public image, fines, and legal action are likely.
OLTP systems are the focal point for IT organizations because they are critical to the success of the business. The system availability, performance, agility, and security are key char-acteristics to be considered when designing and evaluating OLTP database systems.
Data warehousing
While OLTP systems deal in real-time, active data, data ware-houses store archival data to be used in data mining, trend analysis, and meeting audit and regulatory requirements. As data in OLTP systems grows older, it is used less often. That older data is often moved into a data warehouse where spe-cialized processing that requires a history of data occurs.
Data warehouses are commonly used to ask business-related questions, the answers to which require the ability to collect years of data. A business analyst may ask, “How many cases of product X are sold on Super Bowl Sunday and can you deter-mine the growth rate over the last 10 years?” — both of which are the types of questions reserved for data warehouses.
Characteristics important to a data warehouse include ✓ Storage. The size of data warehouses is huge! Terabytes
of data are common, and specialized processing and stor-age techniques to optimize performance are required.
Rather than using high performance disk, data warehouses use capacity disk or tape storage because it would be cost prohibitive to store all data on high performance storage devices.
✓ Processing capability. OLTP systems support thousands of users running small quick transactions, but data ware-houses support a handful of users executing very long running queries. It is possible for a data warehouse query to run many hours or even days to get an answer.
Business Intelligence (BI) tools allow management and data analysts to perform “what-if” scenarios against historical data.
This allows business trends to be identified and complex relationships between data to be seen that otherwise may go unnoticed. This technology has occurred in situations ranging from increasing company profits to catching criminals and scientific research.
Data warehouses are fewer than OLTP systems, but by their very nature, they are much longer. Their design characteristics are different than OLTP systems as well, because they process long running queries rather than multiple fast queries.
Hybrid systems
The hybrid is a combination of OLTP and data warehousing systems. Often, hybrid systems start as OLTP systems, which over time introduce data warehousing requirements.
The ideal design characteristics of OLTP versus data ware-houses are often at odds for each other. For example, an OLTP system is optimized for fast data access by multiple users whereas data warehouses are optimized for fewer users with long running queries. Different database design consider-ations and parameters — which are often mutually exclusive — are used for both systems.
One compromise is to run a hybrid database in OLTP mode during the day and data warehousing mode at night. However, as systems are increasingly used at all hours, that compro-mise becomes less effective. Be sure to evaluate your capabil-ity to support both OLTP and warehousing requirements.
IT System Challenges
Regardless of industry, IT organizations face similar chal-lenges. Supporting complex systems with increasing require-ments is at odds with never having enough time or resources.
The following sections discuss common issues faced by IT management.
High availability
Few systems are only open during business hours; most need to be available 24x7. Given that any component itself will eventually fail, a system needs to be engineered to support fault tolerance and eliminate single points of failure.
Fault tolerance is the ability of a system to suffer a component failure, yet still continue processing and remain available for the users. Any individual component will eventually fail, but the overall system must continue to function. Designing a system to have redundant servers so when one fails the other servers will continue processing is an example of fault toler-ant design.
Having only a single component (which will eventually fail) to perform a function is referred to as a single point of failure, which is something to avoid. If your system has a single point of failure, it’s simply a matter of when, not if, it will fail.
Figure 1-1 shows how multiple database servers provide both increased processing capabilities and fault tolerance. If one server fails, processing continues on the remaining server.
You also see how the single web application server is a single point of failure, making the web application server the most likely weak link in this system.
Be sure to identify the fault tolerant components and single points of failure in any system or product you are evaluating.
Security
Security is not a just a product you buy once or something that is added at the end of program development. Security needs to be an attitude and mindset that occurs at all levels of IT and management from the beginning of a project until a project is finally decommissioned. Products and techniques used to implement security are merely means to an end.
Unfortunately, security is often poorly implemented and man-aged and is deemed a burden to IT systems. Managing con-figuration settings, access controls, and monitoring audit logs does require resources. Testing and applying security patches also require staff time and is usually after hours.
Keeping a handle on security issues and coordinating with management, customers, and technical folks is a never-ending process, but it is a critical process.
Network Cloud
Web Application Server
Customer Database Database Server Customer Database
Database Server
Web Browser Web Browser Web Browser
Storage Area Network Disk Storage Array DiskDisk DiskDisk Disk Storage Array DiskDisk DiskDisk
Figure 1-1: Fault tolerance and single point of failure.
Increasing storage requirements
An undeniable direction in IT is the requirement to store more and more data, often growing at an accelerated rate. Business requirements force the storage of more data to support cus-tomers or develop data warehouses. Changing technology or social media storing images, maps, and audio/video also
increase storage requirements. Finally, government or legal data retention requirements force data to be stored for years.
Many choices regarding storage are available:
✓ Internal or attached storage
✓ Storage Area Network (SAN) or Network Attached Storage (NAS)
✓ Media options such as flash, performance disk, capacity disk, and tape
✓ Unified or tiered storage
✓ Redundant Array of Inexpensive Disks (RAID) levels and replication
Despite improvements in storage technology, effectively man-aging storage is often a full-time job for one or more trained professionals.
Multiple, complex subsystems
A real-world IT system is a complex environment composed of multiple subsystems or components. User management, application servers, web servers, database servers, network-ing, and storage are just some common components with spe-cialized needs.
Within each subsystem, further components exist. For exam-ple, the application itself may have credit card billing, inven-tory control, and auditing functions. Each of these functions has dependencies and subcomponents with further compo-nents as you drill down into the details.
Managing these varied components is a challenge. In large systems, just being aware of where the vital subsystems exist is often difficult. Interoperability with these subsystems needs to be established and maintained.
Multiple vendors
With every hardware device in a system, every software prod-uct installed, and every service or interface partner, there is another vendor or group to work with. Over time, the list of
vendors to evaluate, purchase support and license agreements with, and work patch and upgrade issues with is daunting.
Best of breed is an approach in which you purchase the very best technology product. It allows you to have the industry-leading product for a specific hardware or software compo-nent, which is sometimes a great benefit. The downside is having more vendors to manage and interoperability between components is often an issue as well. In a worst-case scenario, a customer is caught between two vendors who will not work together to solve a customer’s problem; finger-pointing then becomes a frustrating problem.
Single source is an alternative approach in which all products for a system or subsystem are purchased by a single vendor.
You may not have the “best” individual product, but you gain not having to manage interoperability issues between components because your vendor has already done that.
Issues with patches and upgrades between subcomponents are already identified and resolved before they go to the cus-tomer. Finally, although you may not have the best individual components, the components you do have are optimized to work together in a more efficient manner than a series of best-of-breed components operating inefficiently.
Server consolidation
Every time a new database server or storage server is added, the cost for hardware, software, licensing, and administra-tive support increases. While a large server room is visually impressive, it is also excessively expensive!
Where possible, IT organizations are consolidating as many components to as few servers as possible in an effort to reduce costs. For example, simply combining development and test applications onto one server is server consolidation.
Reducing from several test and development servers into a larger single server is a great way to reduce costs.
Technology such as virtualization is a great tool in the server consolidation initiative. Virtualization allows a single server to be partitioned or subdivided into smaller servers that appear as one server to the user. Placing systems into shared envi-ronments, but appearing to be on a dedicated, self-contained environment is the goal of virtualization. Adding resources on
demand as systems grow with minimal downtime is an addi-tional benefit. As you review hardware and software, be sure to determine their support for virtualization.
Sustaining growth
Sooner or later, if a system is growing, the existing server will need more processing capabilities to handle the increased workload. Few things are worse than having a server too small to support your customers. Often, either CPU or memory needs to be increased to support the processing demands of the application. A server can grow up (vertical) or it can grow out (horizontal) to increase processing capability.
Vertical scaling is making an existing server “bigger” so that it can support increased processing requirements. Starting with a smaller, expandable server and adding more CPUs, memory, and storage as needed is a common, economical practice.
One potential issue with vertical scaling is whether you need downtime to add more resources. An even larger issue is that eventually your server will hit its maximum number of CPUs and memory; vertical scaling does have an upper limit for how large a server can grow.
Horizontal scaling is adding more servers to a computing environment to increase processing capability. Adding more servers to support increased workload is a common solution;
it improves fault tolerance and is theoretically unlimited in the number you can add. The downside is that you have more servers to manage, which adds to hardware costs, software and licensing costs, and administrative overhead.
Time constraints
Because business requirements move fast, so must support structures such as IT. Seemingly, there is never enough time
Because business requirements move fast, so must support structures such as IT. Seemingly, there is never enough time