method-r.com

This paper is an introduction to several concepts used in the manufacturing industry to improve efficiency. Some of these concepts will be compared to existing, well known methods in database management to demonstrate commonality between the disciplines. Other concepts will be explored to determine if there is a potential to develop new tools for database management. This paper discusses variation and why variation should be minimized where practical. The potential use of variation as a tool in performance measurement will be explored.

(This is the original document published August 21, 1996, brought to you here with the kind permission of Oracle Corporation.) This paper will help the reader configure a very large Oracle Server database (VLDB) for high performance and high availability with low maintenance. It describes decisions about database block size, RAID technology and raw devices, redo log files, tablespace partitioning, storage parameters, and rollback segments. This paper explores the technologies and trade-off constraints associated with these issues and presents technically detailed methods for optimizing a configuration within these trade-offs.

(This is the original document published January 3, 1996, brought to you here with the kind permission of Oracle Corporation.) The technical architect of an application system is responsible for building a system that meets the goals of the end users. To succeed, this person must combine the right hardware components with suitable application architectures, always obeying complex functional, operational, and economic constraints. This job is complicated. A noticeable lack of good tools, methods, and experience have made it all the more difficult. Yet an inadequate technical architecture will doom an application. Oracle’s success in the mainframe downsizing market has begun to produce tools, methods, and experience that tremendously reduce technical architecture risk. This paper will identify factors critical to the success of a technical architecture design project. We will discuss successful methods used at the most demanding relational database projects in the world, and we will tell you how to use those methods to make your application succeed.

To many application developers, a database is just a “data store” with an API that they call when they need to persist an object. It’s an abstraction that makes sense from one perspective: in a world where you’re expected to write dozens of new features every day in Java, PHP, or C#, who has the time or the inclination to dive into what’s going on deep inside the Oracle Database? As a result of this abstraction, though, developers sometimes inflict unintended performance horrors upon their customers. The good news is that you can avoid most of these horrors simply by better understanding a bit more about what’s going on inside the Oracle kernel. The trick is knowing which details you need to study, and which you can safely learn later. This presentation describes, from a developer’s perspective, some of the most important code paths inside the Oracle kernel that can make the difference between an application that breaks down under load and one that can scale to thousands of users.

This two-page quick reference card written by Cary Millsap sums up computer software performance the Method R way. The first page lists definitions of the terms you need to know: efficiency, knee, load, response time, and so on. The second page lists ten principles that are vital to your ability to think clearly about software performance. This document contains meaningful insight in a format that's compact enough to hang on your wall.

Half the battle of writing good SQL is in understanding how the Oracle query optimizer analyzes your code and applies statistics in order to derive the “best” execution plan. The other half of the battle is successfully applying that knowledge to the databases that you manage. The optimizer uses statistics as input to develop query execution plans, and so these statistics are the foundation of good plans. If the statistics supplied aren’t representative of your actual data, you can expect bad plans. However, if the statistics are representative of your data, then the optimizer will probably choose an optimal plan.

“Measure Twice, Cut Once” is a reminder that careful planning yields better gratification than going too quickly into operations that can’t be undone. Sometimes, however, it’s better to Measure Once, Cut Twice. It’s one of the secrets behind how carpenters hang square cabinets in not-so-square kitchens. And it’s one of the secrets behind how developers write applications that are easy to fix when they cause performance problems in production use. The key is to know which details you can plan for directly, and which details you simply can’t know and therefore have to defend yourself against.

(This is the original document published September 24, 1995, brought to you here with the kind permission of Oracle Corporation.) The OFA Standard is a set of configuration guidelines that will give you faster, more reliable Oracle databases that require less work to maintain. The OFA Standard is written by the founder of the Oracle team responsible for installing, tuning, and upgrading several hundreds of sites worldwide since 1990—this paper is based on the best practices of those hundreds of sites. Today the "Optimal Flexible Architecture" described in the OFA Standard is built into the Oracle configuration tools and documentation on all open systems ports. This paper formally defines the OFA Standard for configuring complex Oracle systems at sites demanding high performance with low maintenance under continually evolving requirements. It also details how the OFA is derived from requirements essential to successful implementation of complicated software on any system. Along with the definition of the OFA, this paper will also reveal the strategy and analysis that motivate the individual recommendations of Oracle Services’ Optimal Flexible Architecture. By reading this paper, you will more fully understand the challenges that confront the Oracle Server configuration planner.

(This is the original document published June 28, 1999, brought to you here with the kind permission of Oracle Corporation.) Performance management consists of problem diagnosis and repair, resource management, application optimization, and capacity planning. In constructing a reliable performance management method for hundreds of Oracle database sites, my colleagues and I have encountered bits of interesting folklore that, ironically, block progress toward the ultimate goal of lasting system performance satisfaction. In this paper, I will take a fun look at the dangers of several popular but bad guidelines, and I will offer alternative advice that helps you avoid the risk of costly performance management mistakes while not losing sight of the friendly goals: fast, easy, and cheap.

(This is the original document published May 18, 1998, brought to you here with the kind permission of Oracle Corporation.) The enormous variety of technology options available in today’s open systems environment makes the role of system architect more critical than ever on both large and small projects. More component options have led to greater flexibility and lower component prices, but also to greater complexity and, in turn, to greater risk of implementation project failure or delay due to technical miscalculations or inappropriate assumptions. System architecture is the discipline that addresses the difficult technical issues inherent in a complex software system implementation. In spite of the importance of system architecture design, many information systems practitioners lack adequate understanding of this subject area, resulting in many costly mistakes throughout information technology organizations worldwide. This paper explains the types of technical challenges the system architect must address. It illustrates the role of the system architect, the type of person required to fill that role, and the types of authority and information access that this person needs to perform effectively in the role. Finally, it describes procedures and an approach that a good system architect uses to reduce the technology risk in a software application implementation project.

Oracle continues to add more and more automated features and advisors to assist with diagnosing and fixing problems. Given all this automation and advice Oracle is providing, a question to ask is whether or not all this advice is "dumbing us down" or "smartening us up". This paper explores this question and asks you to consider "Are you a monkey or an astronaut"?

Creating high-performance as an attribute of complex software is extremely difficult business for developers, technology administrators, architects, system analysts, and project managers. However, by understanding some fundamental principles, performance problem solving and prevention can be made far simpler and more reliable. This paper describes those principles, linking them together in a coherent journey covering the goals, the terms, the tools, and the decisions that you need to maximize your application’s chance of having a long, productive, high-performance life. Examples in this paper touch upon Oracle experiences, but the scope of the paper is not restricted to Oracle products.