Oracle databases on the Web 9781576100998, 1576100995

Citation preview

---

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Introduction -----------

What's on the CD-ROM Dedication CHAPTER 1—Evolution Of The Internet, The World Wide Web, And Databases Internet Basics Connection Costs Internet Protocols Domains And Location Transparency Internet Applications The World Wide Web Fundamentals Of The World Wide Web World Wide Web Components Accessing The Internet And The World Wide Web What Does The Future Hold? Objects And The Internet The Oracle Approach To Object-Orientation Abstract Data Typing (ADTs) Definition Of Aggregate Objects Abstraction Inheritance Polymorphism

Encapsulation Extensibility New Database Design—The ISA Construct Summary

CHAPTER 2—Oracle WebServer Architecture Basic WebServer Architecture The Components Of Oracle’s WebServer Oracle WebServer 1 Architecture Oracle WebServer 2 Architecture Oracle WebServer 3 Architecture Summary

CHAPTER 3—Developing Web Pages Using HTML What Is A Web Page, Anyway? How Are Web Pages Created? The Basics Of Hypertext Markup Language Formatting The Page Background Headers Page Formatting With HTML Lists In HTML HTML Text Styles Special Characters In HTML Link References Linking Images HTML Forms—Soliciting Screen Input Viewing Web Source Code Accessing An HTML File Using WebServer And Netscape Summary HTML References

CHAPTER 4—Installing And Configuring Oracle WebServer Preinstallation Tasks Running The Oracle WebServer Installer

Starting The WebServer Installer Installing WebServer Version 1 With Oracle 7.3.2.1 Oracle WebServer 1 Components Installer Prompts Installing WebServer Version 2 Initial Preinstall Tasks Installer Prompts Configuring Oracle WebServer 1 Configuring Oracle WebServer 2 Populating The Oracle Dictionary Installing The Train Demo Testing Your Install WebServer Configuration Issues Handling WebServer Requests Through CGI Or WRB Configuring The Web Listener For CGI Configuring The Web Request Broker For Processing Requests Getting Technical Support Summary

CHAPTER 5—Designing WebServer Applications The Importance Of Web-Based Design Dealing With The Limitations Of The Web Line Speed Client Platform Considerations Designing For Web Access Web Page Scroll Bars Browser Display Web Frames Web Tables Hyperlinks Dynamic Page Generation Clickable Images And Image Maps WebServer Analysis And Design Designing The Application Framework Systems Analysis For WebServer Pages

Systems Design For Oracle WebServer Using Audit Logs With Oracle WebServer WebServer 3.0 Log Features Summary

CHAPTER 6—Oracle’s Common Gateway Interface Origins Of CGI Components Of CGI Programming Languages Programs And Scripts Environment Variables Client Documents Image Maps And Forms CGI And Oracle’s Web Request Broker The Webmaster Summary

CHAPTER 7—WebServer’s HTP Utilities HTP/HTF Functional Groupings Print Procedures Structure Procedures Head Procedures Body Procedures Frame Procedures List Procedures Character Format Procedures Physical Format Procedures Form Procedures Table Procedures HTP/HTF Parameters Summary

CHAPTER 8—WebServer’s OWA Utilities Parameter Data Types ProcessedBy OWA Utilities OWA Cookie Procedures And Functions

OWA Image Package OWA Init Package OWA Parms Procedures And Functions OWA Pattern Procedures And Functions OWA Text Procedures And Functions OWA Util Procedures Summary

CHAPTER 9—Oracle WebServer And PL/SQL PL/SQL Syntax Structures Declare Section The Begin Section Looping In PL/SQL PL/SQL And Stored Procedures PL/SQL Stored Procedures And Packages Tuning PL/SQL Passing Parameters To Oracle Stored Procedures From The Web Passing Parameters Between PL/SQL Stored Procedures Managing Oracle I/O Using PL/SQL And WebServer Returning A Single Row From An Oracle Database Into A Web Page Returning Lists Of Values From Oracle To A Web Page Exception Handling In WebServer Summary

CHAPTER 10—Managing WebServer Forms And Security Basic Form Functions Data Input Fields Multiple Data Input Fields Checkboxes Radio Buttons Pop-Up Lists Menu Screens Updating The Oracle Database From A Web Page

Updating A Single Row Updating Multiple Rows Security And WebServer Forms Oracle Security Oracle Privileges Functions, Stored Procedures, And Packages Assigning Privileges grant Statements Roles Row-Level And Column-Level Security Table Synonyms Session-Level Security Grants And Distributed Oracle Databases Implementing Role-Based Security Creating Key Developer Roles An Implementation Plan For WebServer Security Role Allocation Strategy For WebServer Data-Specific Vs. Application-Specific Security Automatic Conversion To Role-Based Security Auditing Security In A Distributed Oracle Environment Auditing Oracle Role-Based Security Propagating Security Privileges To Many Distributed Oracle Databases The Ten Commandments For Oracle Security Summary

CHAPTER 11—WebServer Navigation And Concurrency Management Interscreen Transfer Interform Communication Database Locking And Concurrency Management WebServer Updates And Concurrency Oracle Database Locking And Granularity Alternative Integrity Mechanisms For WebServer Add A Date-Time Stamp To Each Row WebServer Distributed Database Concurrency

Summary

CHAPTER 12—Using Java And LiveHTML With Oracle WebServer Java Development Of Java Java And Portability Object Orientation Of Java Security Of Java Performance Of Java Fundamentals Of Java Code Oracle WebServer’s Java Implementation Running Java On The Client Or Server Using PL/SQL With Java Oracle WebServer’s Java Interpreter Accessing Oracle Databases From Java Using PL/SQL Package Wrappers Oracle Database Retrieval By Java Dynamic HTML Generation By WebServer Java Java HTML Examples LiveHTML LiveHTML Syntax Examples Of LiveHTML Summary

CHAPTER 13—Using SQL*Net For WebServer Communication Location Transparency And WebServer Connectivity Oracle Database Domains Intersystem Connectivity With WebServer Internals Of Oracle’s SQL*Net Application Connection With SQL*Net Understanding The SQL*Net Listener Managing SQL*Net Connections Managing Oracle’s Multithreaded Server

Managing The Listener Processes Managing Two-Phase Commits (2PCs) Viewing SQL*Net Sessions Summary

CHAPTER 14—Logical Design For WebServer Applications Normalization And Modeling Theory For Oracle Redundancy And Database Design One-To-Many Data Relationships Many-To-Many Data Relationships Recursive Data Relationships Using STAR Schema Design With WebServer Summary

CHAPTER 15—Physical Oracle Design Replication With Oracle Snapshots How To Create Oracle Snapshots Using Triggers To Update Snapshots Using Snapshots To Propagate Subsets Of Master Tables Using Referential Integrity With Oracle Indexes And Oracle Performance Tuning Queries With Indexes Concatenated Indexes Oracle Locking Oracle Constraints And Indexes Using Multicolumn Indexes With Oracle How Oracle Chooses Indexes Parallelism And Client/Server Multitasking And Multithreading WebServer Processes SMP Vs. MPP Processing Using Oracle’s Parallel Query Summary

CHAPTER 16—Database Performance And Tuning WebServer Performance Issues The Web Request Broker The PL/SQL Agent Oracle Stored Procedures Pinning WebServer Packages In The SGA Oracle Triggers Deciding When To Use A Trigger Oracle Hashing Oracle Clusters Oracle Parallel Query Summary

CHAPTER 17—Tuning Oracle SQL Tuning Oracle SQL Syntax General Tips For Efficient SQL Using Oracle’s Explain Plan Facility Using Temporary Tables Tuning With The Rule-Based Optimizer Using Hints With The Cost-Based Optimizer Tuning PL/SQL Summary

CHAPTER 18—The Future Of Database Management Oracle Version 8 Oracle Sedona Oracle ConText Oracle Express SQL For Object-Orientation The ISA Relationship The ODMG Object Model The Future Of Hypermedia In Database Management A Return To Centralized Data Experiential Databases

Voice Recognition Database Access Summary

Index Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Table of Contents

-----------

Introduction For the past several years, the Oracle database management system has enjoyed dominance in the worldwide information systems marketplace. Oracle’s excellent reputation has been based on the stability of its Oracle7 Server. In our many years of database and application experience, the Oracle DBMS stands out as being highly reliable and recoverable, two of the main features that information professionals depend on daily. However, until recently, it has been very difficult to get information out of an Oracle database and onto the World Wide Web. Now that you can use Oracle’s WebServer to create Web page front-ends for Oracle databases, developers everywhere are struggling to learn all the facets of WebServer to integrate their databases with the Web. As is the case with any nascent technology, the pragmatic use of Oracle’s WebServer is not yet clear to Oracle developers. In the meantime, we have written Oracle Databases on the Web to simplify the process of using Oracle’s WebServer and explain the development of Web-based Oracle applications in easy-to-understand terms. Interfacing a complex and robust database such as Oracle with the World Wide Web is not a simple task, and there are many hidden pitfalls that must be addressed before it you can easily interface Oracle with Web pages. This book hopes to point out those pitfalls, and the paths you can take to get around them. Oracle Databases on the Web introduces the basic concepts of creating a Web page and interfacing that page to the Oracle database management system. We use Oracle’s WebServer product to illustrate all the examples in the book, but the focus will be on generic techniques that can be used to interface any Web page with any Unix-based database, using proven Web interface techniques. The most valuable component of this book is a comprehensive set of working

examples that can be customized to implement database interfaces to Web pages. You’ll also find techniques in this book for transporting data from the Web page to the PC and from the PC to the Web page. We also explain how LiveHTML can be used to interface with the operating system environment. This book begins by discussing the basics of the World Wide Web and WebServer’s architecture, including a detailed chapter on the installation of WebServer. It then goes on to discuss how to manage WebServer applications, and contains separate detailed chapters on various Oracle utilities that you will need to know about. The book also contains chapters on how to tune Web databases and Web-based SQL. Basically, we’ve tried to include everything you might need to know about WebServer and developing Web-based databases in this book. The Oracle WebServer will become a very hot topic as mainstream IS shops begin to enter the World Wide Web to better service their customers. Oracle Databases on the Web will help to reduce their fear of this technology, and aid Oracle developers in their task of creating robust and functional Web pages that interface with Oracle. The authors welcome feedback and comments. Please address email to: Don Burleson: Bob Papaj:

[email protected] [email protected]

Table of Contents

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Table of Contents

-----------

What’s on the CD-ROM The companion CD-ROM for Oracle Databases on the Web includes: • A fully functional copy of Oracle WebServer version 2.1! • Complete source code to all examples in the book. • RevealNet’s Oracle Administration Knowledge Base. See the readme files in each folder for acknowledgments, descriptions, copyrights, installation instructions, limitations, and other important information. Requirements Software: Oracle7 Hardware: Platform: Pentium Operating System: Windows NT RAM: 32 MB

Table of Contents

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Table of Contents

-----------

Dedication We dedicate this book to our loving families, and to all our friends who helped support us through the trials and tribulations of writing this tome. Bob Papaj Don Burleson

Table of Contents

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

CHAPTER 1 Evolution Of The Internet, The World Wide Web, And Databases The Information Superhighway began with the development of a wide-area network (WAN) that eventually became the Internet. In its most basic form, the Internet is a world-wide network of subnetworks; it is the backbone for the global transportation of data. The predecessor of the Internet was a Department of Defense project called ARPANET (Advanced Research Projects Administration Network). ARPANET was developed in the early 1970s to assist researchers working in the United States defense industry, as well as a few associates in other countries. ARPANET grew from a network of a few computers in 1971 to over 1,000 by 1984. In 1986, the U.S. National Science Foundation established NSFNET to provide network connections for research institutions. Soon, NSFNET became the new backbone for the Internet. By 1990, ARPANET had dissolved, but the Internet continued to grow via NSFNET. Today, commercial networks run the Internet and have expanded the Internet to provide millions of instantaneously accessible locations to surfers from around the globe.

Internet Basics Despite its overall complexity, the Internet has just a few major components: the physical network, communication protocols, and Internet applications. The physical network of the Internet is comprised of a number of computers linked by routers and cables, working together as if they were a single processor. In this type of wide-area network, communications among the computers is facilitated through Internet languages called protocols. Protocols manage all of

the internal transformations that a data file goes through when data is being shipped between processors. Processors use a variety of Internet applications to exchange data. Table 1.1 shows some commonly used Internet applications. Application

Table 1.1 Common uses of the Internet. Description

Email World Wide Web List Servers Newsgroups File Transfer Protocol (FTP) Wide-Area Information Servers (WAIS)

Enables the sending and receiving of text messages. Displays Windows-style pages over the Internet. Broadcast email messages to list subscribers. Provide forums for posting subject-oriented email messages. Copies files between sites. Provide more than 500 databases of mainly text-based documents on numerous topics.

Note: While the Internet is very established throughout the Americas and Europe, expansion of the Internet into the remotest parts of the world is constrained by the lack of high-speed phone lines. These high-speed long-distance lines are different from the phone lines we deal with on a daily basis. High-speed phone lines are point-to-point lines where the circuit can be open continuously between connections. Point-to-point lines also have a much greater capacity for carrying data than basic phone lines. The demand for higher capacity lines, similar to those used in WANs, resulted in the production of high-speed, high-volume lines called T1 and T3 service lines. The T3 line is the faster of the two and is used throughout the North American Internet backbone.

Connection Costs Despite the critical nature of the Internet, it’s not totally clear who is responsible for costs associated with installing and maintaining connections among local networks. The cost of connecting a local network to the Internet is commonly paid for by the owner of the local network. The local network owner negotiates a connection with a site already connected to the Internet and pays for a dedicated line that connects the local network to the Internet site. Thanks to the NSFNET project, the National Science Foundation paid for the T3 network backbone in North America. Internet Protocols There are three levels of protocols used by computers to communicate with each other: network, transport, and application. Network protocols coordinate the transmission of information, transport protocols manage the integrity of the data, and application protocols format the data for transmission. The network protocol used by the Internet to get information from one computer to another is called Internet Protocol (IP). Messages delivered by the IP are called packets. The Internet has two transport protocols for coordinating the integrity of network transmissions: TCP (Transmission Control Protocol) and UDP

(User Datagram Protocol). Transport protocols determine whether packets have arrived at their destination, and if so, the protocol assembles the packets in the proper order. As you saw in Table 1.1, there are many applications on the Internet—each of which has their own application protocol. On the Internet, the TCP and IP protocols are often paired together in their usage and jointly referred to as TCP/IP. For the IP to do its job, it needs to identify sites for data transmissions. Under IP, each network and each computer attached to the network has a fixed address. The Internet address is a 32-bit address, partitioned by four 8-bit numbers that identify the computer and its local network. The four bytes (each byte represented by 8 bits) of the address are separated by periods (e.g., 155.222.8.19) and identify either a network number or a host number, depending on the value of the first byte. The first byte (in this case ‘155’) falls within a standardized range of values that will determine the composition of the IP address. In this example, bytes one and two represent the network, and bytes three and four represent the host. The network component is assigned when the local network registers for an Internet connection with the Internet Network Information Center (InterNIC or NIC). NIC gives a range of Internet addresses to the local network’s administrator, who then assigns the numbers to host computers on the local network.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Domains And Location Transparency Many sites recognize the need to track the locations of remote databases and systems on the Internet while providing “location transparency” to their users and programmers. Location transparency refers to a condition whereby the application requests data as if it were local, yet the data may reside thousands of miles away. Domains are especially important in situations of horizontal partitioning, where data tables with identical names are kept at numerous locations. Domains establish a logical hierarchy of physical locations for any distributed enterprise on the Internet, as shown in Figure 1.1.

Figure 1.1 IP addresses and domain names. The real power of the Internet comes into play when Domain Name Services are used to replace the IP address number with a meaningful mnemonic. For example, the IP address 223.222.45.76 could be given the alias “litterbox,” and Internet users could then Telnet to litterbox without knowing the IP address. Internet Applications Once a backbone had been created for the Internet, software applications were created to allow easy use of the Internet. Some of these applications on the Internet are very common (email, Telnet, and FTP, for example) because they are bundled with the network portion of the Unix operating system—the most common Internet operating system. Other Internet applications (such as Gopher, WAIS, WWW, and Archie) are not a part of the operating system and function as standalone applications. Unfortunately, standalone applications are

not always good for sharing data between multiple users because there is no common repository for the data. In order to properly share data with a standalone application, users would have to execute the application on the machine with the data or the data would have to be replicated on many computers. Fortunately, the client/server architecture can help in the goal of data sharing. Network applications work on the client/server model, which distributes the work of one application across two programs, a client and a server. Usually, data is accessed anonymously because it is not necessary to know someone or be known by someone to access data on the Internet. An application is started on the client side that collects details about what is needed by the user, and the client program then proceeds to connect over the network to a server program that controls the information requested. This dialogue between a client and a server is accomplished through application protocol interfaces, which are commonly called APIs. The client-side software formats user requests using the same API as the server. It then dispatches the request by a program that formats the message and transmits it across the network to the server. The server receives the client request, finds the information resource, formats the results in an application protocol, and passes the response to a protocol handler to transmit the requested information back to the client. On the client side, client programs are always ad hoc because a client process is started by a user request. Of course, the server must be ready at all times to respond to a client request, and server programs run continuously, listening for the client requests on their assigned port numbers. Please note that the client/server architecture does not require that the client and the server run on different platforms. Client/server programs can run on the same machine or can run on different machines with heterogeneous operating systems. They can also be defined to support multiple network protocols. Each client program provides a user interface, which may be a character-based interface supporting text only, or a graphical user interface (GUI) supporting text and images like MS Windows. Client programs must execute on an Internet-attached server to access the data repositories connected to the Internet.

The World Wide Web The World Wide Web and the Internet are occasionally interpreted as being one and the same, but they are not. However, the Internet and the Web have been integrated into a powerful behemoth networking system providing links between text, images, and audio information. As we learned earlier, the Internet is nothing more than the physical network of computer hosts. The World Wide Web, on the other hand, is a collection of protocols and standards used to access the vast array of information across the Internet. The World Wide Web uses special applications to retrieve the data on the Internet and can be thought of as residing on top of the basic Internet foundation. The World Wide Web is a very new phenomenon. Since the Web sprang up from its infancy just a few short years ago, it has become the major driving force in worldwide computing. The most fundamental aspect of the World Wide Web is the hypertext link, the procedure for connecting information

repositories across the Internet. The hypertext concept, which allows users to access information in a nonlinear fashion, is not new and was developed in the 1940s by an engineer named Vannevar Bush. He visualized users following trails of information in multiple directions and felt this was essential to accommodate the large amounts of data being generated at that time. The actual term hypertext was coined by Ted Nelson in a book he published called Literary Machines (South Bend, Ind., 1981). In this book, Nelson outlined a system called Xanadu, which made use of hypertext links. While Nelson is credited with the original definition, the person most credited with refining hypertext links is Tim Berners-Lee, who in the 1980s was employed at the European Particle Physics Institute (CERN) in Geneva, Switzerland. It was there that Berners-Lee developed a hypertext system used in the physics community to share information. Berners-Lee called the system Enquire-Within-Upon-Everything. This system provided hypertext links consisting of titles, text, and lists of bidirectional-text links.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Building on their success, Berners-Lee and his associate Robert Caillian compiled the original design documents for a hypertext system as a way to link and access information of various kinds on a web of nodes. The network of links was called the World Wide Web. Contrary to the existing Internet hierarchical systems, which had a rigid path structure for accessing information, the World Wide Web could be accessed without hierarchical access paths. In addition, the design document specified several principles of the Web such as: • Allowing links across multiple machines. • Searching by indexes. • Using a simple protocol to transfer hypertext documents. Hypertext Transfer Protocol (HTTP) later fulfilled this principle. • Using a universal protocol for developing documents. Hypertext Markup Language (HTML) met this specification. • Having the capability to view documents through browser programs. Berners-Lee developed the original hypertext project on a NeXT workstation, and the first hypertext prototype was operational in late 1990. A scientist named Nick Pellow also participated in the project and developed the world’s first Web browser. In May 1991, the project came together and the World Wide Web became readily available to the general public. The Web was greatly assisted in its development by the many discussions that transpired on existing Internet newsgroups, such as alt.hypertext and comp.infosystems.www. An early application of hypertext released in 1987 was HyperCard for the Macintosh. HyperCard enabled users to peruse databases in non linear tracks, very similar to hypertext browsing techniques. As an application, HyperCard grew rapidly in use because it was provided at no charge and was bundled with the Macintosh operating system. HyperCard combined embedded text links with images and sounds, and provided a dazzling display platform for

nontextual information. This concept of merging hypertext with multimedia objects became known as hypermedia.

Fundamentals Of The World Wide Web The World Wide Web is best described as a Windows-style data transmission tool that enables a collection of multimedia documents to be connected by hyperlinks. Web technology enables users to click on words and images in a document to access other documents, such as text, images, sounds, and movies. Web applications can be restricted to internal LANs (intranets), or they can be set up to access the full Internet. Most Web development is currently taking place within corporate boundaries on intranets. An intranet is basically a Web application that is only available to users of a closed, subnet of nodes. Many companies remain wary of security issues outside of their protective firewalls (firewalls often act as LAN gateways to the Internet). Intranets can be used for sending and receiving email, distributing and retrieving information, and coordinating departmental and interdepartmental projects. Initially, the Web was designed to transmit text documents, but it became multimedia-based with the development of Web browsers. A Web browser provides a GUI front end to the multimedia resources available on the Web. The first Web page accessed on a Web server is called the home page, which generally describes and provides links to all the information retrievable on that server. Clicking on a highlighted box or underlined text opens a link to other Web pages containing additional information. Links can take users to information residing on the same server or on another Internet server located anywhere in the world. World Wide Web Components There are primarily three standard elements that comprise the Web: URLs (Uniform Resource Locators), HTTP (Hypertext Transfer Protocol), and HTML (Hypertext Markup Language). URLs are the Internet addresses that we commonly see (such as http://www.coriolis.com). URLs help to locate data on the Internet by addressing resources across multiple protocols. URLs can identify documents through HTTP, specify email addresses, transfer files through FTP, and access Gopher menus. The format of a URL changes based on the protocol being used. A URL can be broken down into three components: the protocol to be used, the server where the connection will be made, and the path for the file to be accessed. In general, but not universally, the format of the URL is: protocol://servername:port/path Usually the “:port” section is omitted, and the URL will use a default port for that protocol. The port number is an identifier that is assigned to software programs that communicate between networked computers. The server name may be specified in either upper- or lowercase. Also, it can be represented as an IP address or hostname. The IP address is a series of numbers that identify

the host and the network location of the host. The hostname is usually synonymous with the domain name. Let’s try an example: spartan.spearsinc.com The domain name in this example is broken down as follows, reading from right to left. The rightmost part of the domain name is referred to as the zone, in this case “com,” which categorizes this as a commercial organization. Table 1.2 shows a list of valid three-character zone names that are commonly used on the Web. There are also two-character zone names that are infrequently used and are geographic identifiers (such as .uk for United Kingdom and .it for Italy). Moving to the left is the string “spearsinc,” which identifies the particular company or organization. Finally, furthest to the left, the hostname “spartan” specifies the lowest-level name of the server. Often, on the Web, you’ll see the hostname specified as “www.” Zone

Table 1.2 A list of valid three-character zone names. What It Identifies

edu

Educational institutions

com

Commercial organizations

net gov

Networked organizations Government organizations

int

International organizations

mil

Military installations

org

Just about any other group Note: URLs are almost always case-sensitive. Be sure to enter them exactly as you see them written in the address.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

In general, the World Wide Web transfers information across the Internet using the HTTP protocol. In order for HTTP to get information from a server to a client, three steps occur: 1. The client connects to the server. 2. The client sends a request to the server for a specific document. 3. The server responds to the request with a status code, information about the object being sent, and the object itself. The status code usually indicates that the request was successful, but other codes may be returned indicating various errors in transmission. The object information fields can specify an enormous amount of information, including: • File content type (for example, executable, graphic, or HTML file) • Last modification date of the file • Document language coding • Expiration dates for the validity of the document The client browser can use the content-type field when determining how to process what was retrieved (for example, a graphic image, a sound, and so on). In addition, browsers can use the last-modified field to reduce repetitive transfers of large images and bitmaps. The most recent transfers are cached within the browser and will not be transferred again when requested unless the last modified field has changed.

HTTP HTTP has been defined as a “stateless” protocol used to increase data transfer rates. But what does “stateless protocol” mean? It means that HTTP is not required to remember any information about a connection from one request to another. The state of the protocol does not have to be defined internally and can be set within the URL.

HTTP can have only one request per connection, which also makes it a “connectionless” protocol. The client-to-server connection is severed after each request is resolved. A new connection must be established to the server for every client request. Retrievals of Web pages that contain many graphic images can take considerable time to complete because a connection must be established for each image. Some browsers, like Netscape and Microsoft Internet Explorer, will transfer multiple documents simultaneously by opening multiple connections; many other browsers transfer documents more slowly, because they are restricted to one open connection at a time, per request. The third leg of the World Wide Web is Hypertext Markup Language (HTML), which is an outgrowth of Standard Generalized Markup Language (SGML). Other markup languages include LaTeX, RTF, and Frame. The markup languages define areas of text by “tagging” them with a specific format for a specific use. Hypertext links can be created between documents with HTML to provide the transport mechanism. This is accomplished by marking documents with code associated with other documents to crisscross the Internet, forming the Web. Accessing The Internet And The World Wide Web In order to access the Internet and the World Wide Web, a computer called a network host must exist and be connected to the Internet. Local area networks (LANs) must connect to one of these network hosts. The local network’s connection point to the Internet is called a router, which is a special computer bridging the LAN to the Internet. A series of dedicated phone lines creates the long-distance part of the Internet’s physical network. Remote computers use dedicated phone lines to connect to LANs that are connected to the Internet.

What Does The Future Hold? Today, the Internet has over 30 million users with thousands of new users being added every day. Ninety-five countries have access to the Internet, and more than 145 countries have access to email. Regulators predict at least a 100 percent rate of growth each year for the Internet. Internet-based systems developed in the 1990s may seem revolutionary, but they are no less revolutionary than the demise of punched cards brought on by the introduction of GUI interfaces in the 1970s and 1980s. A careful study of the evolution of Internet-based online systems establishes a trend line that can give us some insight into the future of distributed Internet systems. While the World Wide Web has added a glossy front-end package to information systems, the internal information architecture has changed very little in the past decade. In fact, the state of online systems has changed relatively little since the 1960s. Online transaction systems continue to process record-oriented information, and if we factor out the convenience of a GUI and a mouse, the core nature of these systems has remained unchanged. However, this does not imply that Internet-based client/server and distributed databases are only a facade. As processors continue to increase in speed and decrease in cost, the next

revolution will exploit the inherent power of client/server systems and change the way information systems function, not just how they appear. For example, imagine high-speed processors on everyone’s desk, with each machine having the power of an IBM 3090 mainframe. The client/server component would then become more of a data server than a shared processor, and corporate information could be extracted and manipulated freely within the information domain. The greatest challenges over the next decade will be the management of distributed data. Centralized corporate servers must be built and managed so that a user, regardless of geographical location or computer platform, can instantly access and manipulate data. These new servers will open up new career fields and new jobs, such as the Object Administrator. The widespread acceptance of object technology will dramatically change the complexion of information systems programming. The role of the programmer will change from a craftsman who carefully creates unique programs to that of a program assembler who constructs systems from predefined and pretested code modules. Just as Eli Whitney’s idea of interchangeable parts changed the way that rifles were assembled in the 1700s, object technology will forever change the way computer systems are constructed. Rather than being craftsmen who create a unique work, object-oriented programmers will take on the role of code assemblers, choosing among prewritten and tested code functions and combining them in unique ways.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

However, it is interesting to note that object-oriented languages do not follow the pattern that we have seen in previous programming languages. If we take a look at people costs versus CPU costs, we find that the procedural language of the day was suited to the economic situation at the time. Figure 1.2 shows that the early second-generation languages are designed to be high in people resources, but very efficient in CPU consumption. This is to be expected because, in the early 1960s, people costs were relatively less expensive than CPU cycles. Programming competitions in the 1960s judged the contestants by how efficiently they could write a program, not by how fast they could write a program. Processor cycles were precious, and the programmers were taught to carefully hand-execute each line of code before submitting it to the compiler.

Figure 1.2 People costs versus processor costs. As time passed, people costs remained constant while the costs of CPU time began to drop dramatically. Here we see the introduction of the third-generation languages, such as COBOL and Fortran. These languages recognized the falling costs of CPU cycles relative to people costs, and they were designed to allow programmers to become more productive, even if it meant requiring more processing time to compile their programs. We still see carryovers from the earlier days, in features such as 66-level entries in COBOL that serve only to save a small amount of memory during execution time, but there is a clear trend to make procedural language programming more productive for the programmer. As processing costs fell by a factor of 100, the fourth-generation languages

gave even more recognition to the new economic reality. By fourth-generation languages, programmer costs amounted to the majority of managers’ budgets, and the marketplace was demanding languages that could make their programmers more productive. Figure 1.3 shows the introduction of high-level languages such as SAS, Focus, and “Wizard-based” environments, such as Microsoft Visual Basic and Microsoft Access.

Figure 1.3 Language evolution. However, one must note that the fall in processor costs cannot continue forever. As we maximize the potential of silicon technology, we see that each marginal improvement in speed and power is becoming more expensive. We have already maximized the potential of silicon technology, as seen in the flattening of the CPU curve in Figure 1.2. When a new technology arrives, say Gallium Arsenide, we may see another surge in declining processor costs. It is also interesting to note that computer programmers are worse off today than they were in the 1960s (in net-present value dollars). While programming skills have commanded high salaries, the programming profession has fallen victim to the friendliness of the procedural languages. Today, a 10-year-old can create and manipulate a database by using friendly tools with Wizards, and it is no longer necessary to have a master’s degree in computer science to program a computer. Consequently, we see a trend away from the high salaries of the 1960s, when programming was a skill reserved for those who could afford the cost of many years of expensive training. Given these trends, we might expect to see the next generation of languages become even friendlier, allowing automatic code generation with a minimum of technical expertise. Here is the rub: Instead of seeing a new generation of languages that are even friendlier for the programmer, we are seeing the age of object-oriented programming. Object-oriented languages such as C++ and Smalltalk, are a far cry from the expectations of the programming community for a high-level, friendly language. With regard to databases, we see a similar backward trend. The first commercial databases, such as IBM’s IMS database, were very difficult to navigate, and it took programmers months of training to begin to use these complex database engines. Then, the advent of the CODASYL network model provided a standard Data Manipulation Language (DML), but database access was still achieved by carefully navigating pointer lists. The introduction of the relational model and Structured Query Language (SQL) made database access easier than ever. SQL became so popular that even end users could retrieve data from their own tables without any intervention from the programming staff. When object-oriented databases started to become popular, we saw a trend away from the simple SQL database access. Figure 1.4 shows this evolution of database technology.

Figure 1.4 The evolution of database management.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Objects And The Internet The next progression of database architecture is toward object-oriented databases. In the same manner that early file managers stored data, network databases stored data and relationships. Today, object-oriented databases store data, data relationships, and the behaviors of the data. The object-oriented approach borrows heavily from the concepts of “intelligent databases” and “knowledge bases.” Both of these database approaches advocate storing behaviors within the database, so that data and business rules share a common repository. Instead of the data residing alone in the database, while the business rules reside in external programs, the data and the rules reside together within the database (see Figure 1.5).

Figure 1.5 The evolution of database architectures. With the properties of encapsulation, abstraction, and polymorphism, object-technology systems are moving toward a unified data model, which models the real world far more effectively than previous modeling techniques. Furthermore, a properly designed object-oriented model promises to be maintenance-free, because all changes to data attributes and behaviors become a database task and not a programming task. Let’s take a look at a human analogy to the object-oriented approach. It is very natural for humans to recognize objects and to associate objects with their classes. It is also a very natural concept to associate an object with its expected behaviors.

Even as very young children, we learned to associate objects and behaviors with certain characteristics of objects. For example, it is not uncommon to visit the zoo and hear a three-year-old call all four-legged animals “doggies.” The child has learned to associate an object class (dog) with a data at tribute (four legs). Later, a child will refine her object-oriented paradigm and associate other data attributes with animal objects. A child also learns to associate behaviors (such as playing, having fun, or pain) with different visual and auditory stimuli. Adults develop the same associations between objects and behaviors. There have been hundreds of psychological studies that prove that expectations, or the association of behaviors to attributes, affect interactions among people. Humans are also familiar with the concept of abstraction. Intangible objects, such as time, are easily understood. The distinguishing characteristic of the object-oriented database is its ability to store data behavior. How is the behavior of the data incorporated into the database? At first glance, this may seem to be a method for moving application code from a program into a database. While it is true that an object-oriented database stores behaviors, these databases must also have the ability to manage many different objects, each with different data items.

The Oracle Approach To Object-Orientation Rather than rebuild the Oracle engine as an object-oriented architecture, Oracle has decided to keep the base relational engine and add object functionality on top of the standard relational architecture. While claiming to be an active member in the Object Management Group (OMG), Oracle has departed from the OMG’s standard for “pure” object databases as defined by the Object Data Management Group (ODMG). Oracle’s intent is to provide a generic relational database while extending the architecture to allow for objects, such as: • Abstract data typing (ADTs) • Defined aggregate objects • Coupling of data and behavior • Abstraction • Inheritance • Polymorphism • Encapsulation • Extensibility Let’s discuss each of these features. Abstract Data Typing (ADTs) Rather than being constrained to the basic relational data types of INT, VARCHAR, and FLOAT, future versions of Oracle may allow the definition of data types that may be composed of many subtypes. For example, the following data definition could be implemented as an ADDRESS data type:

03 ADDRESS. 05 STREET-ADDRESS 05 CITY-ADDRESS 05 ZIP-CODE

VARCHAR(30). VARCHAR(30). NUMBER(5).

In this manner, aggregate data types can be defined and addressed in a table definition just like any other relational data type. In the following example, we see the phone_nbr and address data types being used in a table definition: create table CUSTOMER ( cust_name VARCHAR(40), cust_phone phone_nbr, cust_address address); Here we see that a single data field in a table may be a range of values or an entire table. This concept is called complex, or unstructured, data typing. With this approach, the domain of values for a specific field in a relational database may be defined. This ability to nest data tables allows for relationship data to be incorporated directly into the table structure.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Definition Of Aggregate Objects Aggregate objects can be defined and optionally preassembled. For example, a report_card object may be defined for a university database. The report_card object may be defined such that it is assembled at runtime from its atomic components (similar to an Oracle view), or the report_card may be preassembled and stored in the data base. These aggregate objects may have methods (i.e., stored procedures) attached to them, in which case an Oracle object couples the data and behavior together.

Coupling Of Data And Behavior The engine allow for the direct coupling of a database entity (such as a table or object) with a set of predefined behaviors. In this fashion, calls to Oracle will be made by specifying an object name and the method that is associated with the object. For example: CUSTOMER.add_new("Jones", 123, "other parms"); This call tells Oracle to invoke the add_new procedure that is attached to the CUSTOMER object using the supplied parameters. As you might expect, this new way of invoking database calls has important ramifications for the developers and Database Administration (DBA) staff. For developers, applications will become SQL-less and will consist of calls to stored procedures. Of course, this has the important benefit of making applications portable across platforms, while also making it very easy to find and reuse code. In addition, because each method is encapsulated and tested independently, the pretested methods can be assembled with other methods without the worry of unintended side effects. The introduction of methods will dramatically change the way DBAs function.

Instead of only managing data and tables, the DBA will also be responsible for managing objects and the methods associated with each object. These new “object administrator” functions will need to be defined so that developers know the functions and parameters of each method. Abstraction Abstraction will be defined as the conceptual (not concrete) existence of classes within the database (see Figure 1.6). For example, a database may have a class hierarchy that includes classes that do not have any objects. Let’s consider a military database as an example. A military database may contain the conceptual entities of division, battalion, squadron, and platoon. Further, assume that the function of the database is to track only the platoons; therefore, the entity classes of division, battalion, and squadron may not have any associated objects.

Figure 1.6 An example of abstraction. However, this is not to say that there is no purpose for abstract classes. When a class is defined, it is associated with behaviors, and these behaviors will be inherited by a class containing an object, such as the platoon class in our example. From a database perspective, there will be no instances of any objects in our example except in the platoon class, but higher levels in the class hierarchy contain behaviors that the platoon objects inherit. Inheritance Inheritance is defined as the ability of a lower-level object to inherit, or access, the data structures and behaviors associated with all classes that are above it in the class hierarchy. Multiple inheritance refers to the ability of an object to inherit data structures and behaviors from more than one superclass. To illustrate, let’s look at an application of this system for a vehicle dealership (see Figure 1.7). Occurrences of item entities to a dealership are found in the vehicle class. Beneath the vehicle class, we may find the subclasses car and boat. Within car, the classes may be further partitioned into classes for truck, van, and sedan. The vehicle class would contain the data items that are unique to each vehicle, including the vehicle ID and the year of manufacture. The car class, because it is a subclass of vehicle, would inherit the data items of the vehicle class. The car class might contain data items such as the number of axles and the gross weight of the vehicle. Because the van class is a subclass of car, which in turn is a subclass of vehicle, objects of the van class will inherit all data structures and behaviors relating to the car and vehicle classes.

Figure 1.7 An example of object class hierarchy. It is critical to the understanding of inheritance to note that inheritance happens at different times during the life of an object. Inheritance most often occurs during object creation and runtime: • Object Creation Inheritance (Data Structures)—At object-creation time, inheritance is the mechanism whereby the initial data structure for the object is created. Only data structures are inherited—never data. It is a common misconception that data is inherited, such that an order may inherit the data items for the customer that placed the order. We must understand that inheritance is only used to create the initial, empty data structures for the object. In our example, all vehicle objects would inherit data definitions from the vehicle class definition, while an object of a lower-level class, such as the sailboat class, would inherit data structures that only apply to that class—in our case, the sailboat objects would inherit a data item such as sail_size. • Runtime Inheritance (Methods)—Inheritance also happens at runtime when a call to a method (stored procedure) is made. For example, assume that the following call is made to a sailboat object: sailboat.compute_rental_charges();

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

The database will first search for the compute_rental_charges in the sailboat class, and if it isn’t found, the database will search up the class hierarchy until compute_rental_charges is found. Of course, not all classes within a generalization hierarchy will have objects associated with them. The object-oriented paradigm allows for abstraction, which means that a class may exist only for the purpose of passing inherited data and behaviors. The classes vehicle and car would probably not have any concrete objects, while objects within the van class would inherit from the abstract vehicle and car classes. Multiple inheritance is also demonstrated by the amphibian_car class. Any instances of this class will inherit data and behaviors from both the car and the boat classes. It is important to note that there is a very big difference between one-to-many relationships and one-to-one relationships. In the above example, the entire class hierarchy describes vehicle objects, which are associated with the item entity in the overall database. Keep in mind that class hierarchies do not imply data relationships between classes: While one customer object may relate to many order data structures, it is not true that one car object may have many sedan data structures. Polymorphism Polymorphism is the ability of different objects to receive the same message and behave in different ways. This concept has many parallels in the real world. For example, an event such as a volcanic eruption may have many different effects on the living things in the area. The poisonous gasses could kill air-breathing animals while at the same time nourish small marine organisms nearby. The single behavior eruption has different effects on objects within the animal class. Another analogy can be found in the business world. For a personnel manager, a promotion event will cause different behaviors depending on the employee class affected by the promotion event.

Management objects will receive stock options and country club memberships, neither of which are offered to part-time objects. Ronald Popeil was a master of polymorphism. Many folks may remember the heyday of Popeil and his company called “Ronco.” In the 1970s, Popeil spent tens of millions of dollars on television advertising, and created ads where the polymorphic nature of his products were demonstrated. Consider the statement, “It’s a hair cream AND a floor wax!” If that statement were true, the method spread_it_on would invoke very different processes depending upon whether we are applying the cream to a floor or a person’s head. The concept of polymorphism originally came from the programming concept of overloading. Overloading refers to the ability of a programming function to perform more than one type of operation depending on the context in which the function is used. For example, consider the following Basic program: REM

Sample Basic program to show polymorphism

REM

Increment the counter

COUNTER = COUNTER + 1 REM

Concatenate the string

N$ = "Mr. Burleson" S$ = "Hello there, " + N$ END In this example, the + operator is used to indicate addition in one context and concatenation in another. But what determines which way the operator will function? Clearly, the Basic compiler knows that the + operator means addition when it is used in the context where a number is passed as an argument, and it knows that concatenation is required when character strings are passed as an argument to the operator. The implications of polymorphism are that a standard interface may be created for a related group of objects. The specific action performed by the object will depend upon the message that is passed to the interface. Because the programmer is no longer concerned with the internal constructs of the object, extremely complex programs can be created. The programmer only needs to understand the interface to use the object. In the real world, polymorphism can be described by looking at standard interfaces. In most PC-based software, the F1 key has a special meaning. Pressing F1 will invoke a context-sensitive Help function and explain the function to the user. These Help functions have vastly different methods and data storage techniques, but the standard interface, F1, is polymorphic and invokes different internal mechanisms depending upon the software. Another example of polymorphism is the set of controls on an automobile. While the internal workings of automobiles are vastly different, steering

wheels are always round, and the gas pedal is always to the right of the brake. These polymorphic interfaces make it possible for any person to drive a car without being concerned with the underlying structure of the vehicle. Now, let’s apply polymorphism to the database scenario. All communication between database objects and their behaviors is accomplished by using messages. A message is normally the name of a behavior that is tightly coupled to an object type, such as the messages customer.display_ address(“Sam Jones”) and order.display_details(“123”). For example, consider two objects, rush_order and cod_order, that belong to the order class. When a message such as prepare_invoice is called, it may contain subbehaviors, such as prepare_invoice and compute_charges (see Figure 1.8). The message prepare_invoice directs the system to compute the shipping charges. The message will cause different procedures to be invoked depending upon whether the receiving object is a rush_order object or a cod_order object, even though they are both objects within the order class. A rush_order would include overnight mail calculations, and the cod_order would contain additional computations for the total amount due. This is what an object-oriented call would look like PLACE_ORDER(PREPARE_INVOICE(COMPUTE_CHARGES)) and this is its procedural language equivalent: IF (RUSH_ORDER) COMPUTE SHIPPING = TOT_AMNT * .25 ELSE COMPUTE SHIPPING = TOT_AMNT * .10 IF (COD_ORDER) COMPUTE TOT_DUE = TOT_AMNT + SHIPPING ELSE COMPUTE TOT_DUE = 0

Figure 1.8 An example of polymorphism.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Encapsulation Encapsulation means that each object within the system has a well-defined interface with distinct borders. In plain English, encapsulation refers to the localized variables that may be used within an object behavior and cannot be referenced outside of that behavior. This closely parallels the concept of information hiding. Encapsulation also ensures that all updates to the database are performed using the behaviors associated with the database objects. Code and data can be enclosed together into a “black box,” and these boxes may then function independently of all other objects within the system. From a programming perspective, an object is an encapsulated routine of data and behaviors. Objects may contain public variables, which are used to handle the interfaces to the object, and private variables, which are known only to the object. Once created, an object is treated as a variable of its own type. For example, an object of class car is created as a routine with a data type called car and is treated as a compound variable by the program. Encapsulation is used in nondatabase object-oriented applications to ensure that all operations are performed through the programmer-defined interface and that data will never be modified outside of the application shell. But what about ad hoc query and update? It appears that any declarative database language that allows external retrieval and update, such as SQL, does not follow the dictates of encapsulation, and is, therefore, inconsistent with object-oriented database management. This is, in fact, true. For example, a relational database could be defined to have a behavior called add_line_item that serves to check inventory levels for an item and add items to an order only if sufficient stock is available. This behavior ensures that orders are not entered for out-of-stock items. With a language such as SQL, the object-oriented behavior could be bypassed, and line_item records could be added without regard for inventory levels.

Because encapsulation and SQL are clearly incompatible, the only conclusion that can be reached is that encapsulation may be violated in Oracle8 by using ad hoc tools such as SQL*Plus. Extensibility Extensibility is the ability of the Oracle8 engine to add new behaviors to an existing application without affecting the existing application’s shell. This is an especially powerful feature because it allows Oracle8 to extend existing classes and to ensure that there are no unintended side effects from the introduction of a new object class. For example, consider a company that provides payroll services for businesses in many states. Some payroll computations are global (e.g., Gross_pay = hours_worked * payrate), while others are specific to a municipality or state (such as computing state taxes). Using Oracle8, an existing object class definition can be extended such that the new object behaves exactly like its superclass definition, with whatever exceptions are specified. For example, if New York City instituted a new payroll rule for New York City residents, then the general definition for New York payroll customers could be extended with a new class definition for New York City payroll customers. The only method that would be attached to this class definition would be the code that is specific to New York City; all other methods would be inherited from the existing superclasses. New Database Design—The ISA Construct Oracle is planning to introduce an extension to their Designer/2000 product to allow for the modeling of class hierarchies. This new extension, tentatively dubbed Designer/2001, should allow for object-oriented constructs to be described and modeled. Here is a vision of how it might work. After establishing a class hierarchy with the Entity/Relation model, the principle of generalization is used to identify the class hierarchy and the level of abstraction associated with each class. Generalization implies a successive refinement of the class, allowing the superclasses of objects to inherit the data attributes and behaviors that apply to the lower levels of the class. Generalization establishes taxonomy hierarchies, which organize the classes according to their characteristics, usually in increasing levels of detail. Generalization begins at a very general level and proceeds to a specific level, with each sublevel having its own unique data attributes and behaviors. Essentially, this hierarchy implies successive levels of detail, such as “a sedan ISA car, which ISA wheeled_vehicle, which ISA vehicle”. In Figure 1.9, the ISA relationship is used to create a hierarchy within the object class, and all of the lower-level classes will inherit the object class’s behaviors. The ISA relationship is used to model the hierarchy that is created as the class entity is decomposed into its logical subcomponents. As you can see in Figure 1.9, customers may be preferred_customers or new_customers, and orders may be cod_orders or prepaid_orders, each with its own data items and behaviors.

Figure 1.9 The ISA data relationship.

Summary While this chapter has discussed three different topics, the intent was for the reader to develop an appreciation about how the Internet, the World Wide Web, and the development of objects within Oracle will influence the future of database-enabled Web pages. It’s very clear from an evolutionary perspective that the Internet will bring older technology to the forefront, while at the same time provide a vehicle for newer technologies. Hopefully, future releases of Oracle, as well as WebServer, will marry the Internet with object databases, so that access to database information will not require complicated explanations.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

CHAPTER 2 Oracle WebServer Architecture The Oracle WebServer is the first Oracle product that allows application developers to create Web-based interactive applications that work closely with the Oracle database. At first glance, the architecture of WebServer may seem confusing. Since the Oracle WebServer is a very powerful product, there are a plethora of ways in which the tool can be configured and used. However, there are some analogies to existing Oracle products that may help in conceptualizing the WebServer architecture. For instance, it is very similar to the architecture of Oracle’s SQL*Net product. A Web listener runs on the WebServer host, polling for incoming URL requests. As each request is received, the WebServer directs the request to Oracle, extracting the required data and preparing an HTML document for transmission to the requesting browser. Let’s take a look at some of the many ways that WebServer can be implemented.

Basic WebServer Architecture In its most basic form, a Web server acts as a simple request dispatcher that takes a URL request (such as http://myhost.domainname:port/ows-bin/owa/stored_procedure_name) and returns an HTML document to the requester. WebServer supports this basic task with the added benefit of being able to dynamically create Web pages from Oracle database information. The primary purpose of Oracle’s WebServer is to create HTML documents, complete with HTML tags, that contain literal values extracted from Oracle databases. Using this technology,

WebServer can create customized responses to user requests. When WebServer receives a request, a Web listener initiates the process by contacting the Oracle database. From there, the requested procedure is called, translated into an HTML document, and then returned to the Web browser. While this is a very simplistic overview, it serves to demonstrate the basic functionality of a WebServer. Figure 2.1 displays a high-level view of the WebServer’s basic architecture.

Figure 2.1 The basic WebServer architecture.

The Components Of Oracle’s WebServer Oracle’s WebServer is composed of many components that work together to provide a complete application environment. Which components are included in WebServer depends on which version you install. In this chapter, the interaction of these components will be described in terms of the architecture for Oracle WebServer versions 1, 2, and 3. Here are the basic WebServer components: • Web Listener • Common Gateway Interface (CGI) • Web Request Broker (WRB) • PL/SQL Agent and WebToolkit • Java Cartridge • LiveHTML Cartridge Let’s take a look at how each of these components work and interact with each other to provide an Oracle WebServer environment. Oracle WebServer 1 Architecture Figure 2.2 displays the architecture for Oracle WebServer 1 as it relates to generating dynamic Web pages via Oracle PL/SQL stored procedures. As you can see, we begin with a Web browser that is used to specify the URL that identifies the stored executable procedure. This URL is passed to the Oracle Web Listener, which determines whether it is a static or dynamic request for a Web page. If the URL specifies accessing a flat HTML file on a file system, then the Web Listener would retrieve this file and return it to the browser as a static Web page. In this scenario, since a PL/SQL procedure was specified in the URL, the Web Listener recognizes this as a request for a dynamic document and passes the request through the CGI to the Oracle Web Agent. The Web Agent processes the PL/SQL stored procedure, which is stored in the Oracle7 database, and generates HTML with dynamic data from the database. This HTML gets picked up by the Web Listener, which sends it back to the Web browser as a Web page.

Figure 2.2 A diagram of the Oracle WebServer 1 architecture.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Oracle WebServer 2 Architecture The main difference between versions 1 and 2 of Oracle WebServer is the addition of the Web Request Broker. In Figure 2.3 you can see the process for dynamic Web page generation, but this time within the framework of the Oracle WebServer 2 architecture. Just as before, the URL is entered by a user through a Web browser and is sent to the Oracle Web Listener. Again, static document requests would be processed by retrieving HTML from your file system and sending it back to the browser, where it would be displayed as a static document. For dynamic generation of Web pages initiated by a request, the user specifies the module to be executed in the URL. The Oracle WebServer 2 implementation of the Web Request Broker provides several options for generating dynamic documents, including the PL/SQL Agent (formerly the Oracle Web Agent), Java, LiveHTML, and custom-built modules. You’ll notice in Figure 2.3 that in addition to processing a dynamic request through the WRB, it is also possible to execute the request through CGI. Whether a dynamic request is processed through the WRB or CGI depends on the virtual directory specified in the URL.

Figure 2.3 A diagram of the Oracle WebServer 2 architecture. Note: Please refer to Chapter 4, “Installing And Configuring Oracle WebServer” for details on configuring the virtual directory mappings for access via WRB and CGI.

If the user specified the request to be executed through the CGI, then the PL/SQL Agent would execute the stored procedure and the dynamic HTML

generated would be returned to the browser via the Web Listener. If the URL specified that the WRB be used as the dynamic interface, then the WRB Dispatcher within the WRB would spawn a WRBX process to direct the request to the proper cartridge. (In Web terminology, the term cartridge refers to an additional feature, usually a procedural language module, that can be plugged into the WebServer architecture. WebServer published the specifications for their plug-ins so that third-party vendors can create new cartridges to access Oracle WebServer.) The dynamic content would be retrieved from the database and sent back to the browser by the Web Listener. The use of the WRB, instead of the CGI, as the dynamic page generation interface is highly recommended, since WRB is the better performer due to the establishment of persistent database connections.

Web Listener The Web Listener is an HTTP engine on the Oracle host that manages incoming requests for services. The Web Listener submits incoming requests to the Web Request Broker for processing. After the HTML page has been built, it is handed back to the Web Listener. The Web Listener then sends the completed HTML document back to the originating requester. Each host may have many listener processes running, depending on the processing needs of the Oracle WebServer. At a minimum, it is best to have one Listener for DBA tasks, and another for developers to build the applications and users to access those applications.

The Common Gateway Interface (CGI) The Common Gateway Interface (CGI) enables external applications, such as clickable image maps and fill-in forms, to interface with information servers. These information servers (such as Web servers) include Oracle WebServer, NCSA’s HTTPd, and Netscape’s Communications server. A CGI program is executed in realtime to output dynamic documents that are flexible in meeting the changing needs of users. This is a carryover from WebServer 1 technology and is maintained as an alternative for dynamic page generation to allow compatibility with CGI scripts that were executed in previous applications. CGI is still a highly utilized interface throughout the Web and will be around for a long time to come.

The Web Request Broker (WRB) The Web Request Broker (WRB) is defined by Oracle as “an asynchronous request handler with an application program interface (API) that enables it to interface dynamically and seamlessly to various back-end technologies.” In plain English, the WRB acts as a handler for Web requests made to Oracle databases. Internally, the WRB consists of a dispatcher that maintains communications with a pool of processes called WRB executable engines. These engines, in turn, interface with various WRB cartridges. It is important to understand the relationships between the WRB dispatcher, executable engines, cartridges, and APIs. The marriage of a WRB API and a cartridge is called a WRB executable engine (WRBX), which is actually a

process that handles HTTP requests sent from the WRB dispatcher. These requests are then processed against one of the cartridges, depending on which virtual directory is specified in the URL. A WRBX, which uses the PL/SQL Agent, will immediately initiate a persistent connection to the database when it is spawned and wait for requests to arrive. The WRB dispatcher adjusts the request load based on parameters set in the WRB configuration file for the minimum and maximum number of allowable engines that the dispatcher may create. Internally, an engine is similar to a Unix pipe that allows single-threaded communication between the dispatcher and the operating system. The WRB technology is Oracle’s proprietary foray into a new and improved HTTP request-handling process which, based on the results to date, bodes well for the future of this critical aspect of WebServer architecture.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

PL/SQL Agent And WebToolkit The PL/SQL Agent is a cartridge that allows the Oracle WebServer to execute PL/SQL that resides in Oracle packages and stored procedures. In addition to executing standard PL/SQL, the PL/SQL Agent can carry calls to WebServer utilities and HTML functions. For example, we might see the following calls in a PL/SQL stored procedure: htp.FormOpen(owa_util.get_owa_service_path || 's10'); This code is calling a procedure in the Oracle WebToolkit called htp.FormOpen, where htp is the name of an Oracle package, and FormOpen is the name of a stored procedure in the htp package. Within this call, we see a call to the owa_util package, calling a stored procedure named get_owa_service_path. Note: The htp package is loaded as part of the WebServer install, and the source code can be viewed by looking at $ORACLE_HOME/ows2/admin/privhl.sql. This can give you additional insight into how WebServer translates htp package calls into HTML documents. The OWA utilities package (owa_util) source code can be found in $ORACLE_HOME/ows2/admin/privutil.sql.

The htp and owa_util packages are an integral part of WebServer, and additional explanation for these packages can be found later in this book in Chapters 7 and 8. Let’s walk through a PL/SQL Agent process by starting at the beginning of a WebServer transaction. First, the URL (for example, http://myhost.domainname:port/ows-bin/owa/stored_procedure_name) calls an Oracle PL/SQL stored procedure, which is loaded and interpreted at runtime. Any calls to htp and owa packages are also resolved, and a static HTML document is created with Oracle data hard-coded into the body of the document. The WebServer PL/SQL Agent’s role in this process is as follows: • Logs-in and invokes PL/SQL procedures • Executes stored procedures to generate HTML documents • Passes the HTML document to the Web Listener At this point, you might be curious as to how WebServer can create a standard Web page using Oracle database information. As you may know, official HTML standards require that all HTML documents follow a basic format and use accepted tags (more information on HTML can be found in Chapter 3). Let’s use a simple example to illustrate this concept. Assume that you have a Web page that accepts a customer name and then displays the details for that customer from your Oracle data base. Listing 2.1 shows what the Oracle code would look like. Listing 2.1 Sample of WebServer Oracle database retrieval.

create or replace procedure s10(host_name_in in varchar2) as host_name ip_address cust_name os_type os_version oracle_csi_nbr dba_pager_nbr

varchar2(20); varchar2(20); varchar2(20); varchar2(20); varchar2(20); varchar2(20); varchar2(20);

cursor c1 is select host_name, ip_address, cust_name, os_type, os_version, oracle_csi_nbr, dba_pager_nbr from host where host_name = rtrim(host_name_in); host_rec c1%ROWTYPE; BEGIN htp.bodyOpen; htp.FormOpen(owa_util.get_owa_service_path || 's10'); htp.htmlOpen; htp.headOpen; htp.title('s10'); htp.header(1,'Oracle information database'); htp.header(1,'Host Display','C'); htp.headClose; open c1; loop fetch c1 into host_rec; EXIT WHEN c1%NOTFOUND; htp.print('Host Name: '); htp.FormText(host_name,10,50,host_rec.host_name); htp.print('IP address: '); htp.FormText(ip_address,20,50,host_rec.ip_address); htp.print('Customer_name: '); htp.FormText(cust_name,10,50,host_rec.cust_name); htp.print('Operating System: '); htp.FormText(os_type,10,50,host_rec.os_type); htp.print('Operating System version: '); htp.FormText(os_version,10,50,host_rec.os_version); htp.print('Oracle CSI Number: '); htp.FormText(oracle_csi_nbr,10,50,host_rec.oracle_csi_nbr);

htp.print('DBA pager number: '); htp.FormText(dba_pager_nbr,10,50,host_rec.dba_pager_nbr); htp.nl; end loop; close c1; htp.FormClose; htp.bodyClose; htp.htmlClose; end; / This Oracle code accepts a host_name_in parameter and will create the HTML source code shown in Listing 2.2. Listing 2.2 Sample of HTML source code created by WebServer using Oracle data.

s10 Oracle information database Host Display

Host Name:

Note that the htp.form functions have been replaced with literals that contain the actual values from the Oracle database. For example htp.FormText(dba_pager_nbr,10,50,host_rec.dba_pager_nbr); has been replaced with

where dba_pager_nbr is the value from the Oracle database. After WebServer creates a Web page, it routes the page to the requester and then displays the page just like any other HTML document. Figure 2.4 displays a Web page created using WebServer.

Figure 2.4 A sample Web page created using WebServer and Oracle data. The real benefit of the Oracle WebServer should now be very clear. Rather than the traditional method of sending static Web pages, the Oracle WebServer allows developers to dynamically create Web pages based on data from their Oracle databases. Depending on the values entered by a user of a Web page, WebServer can access Oracle tables and copy the contents of the data columns into HTML documents for display in Web browsers. It is important to note that there are other ways to run WebServer besides using PL/SQL. For example, next we’ll take a brief look at the popular Java language and see how it is used with Oracle’s WebServer.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Java Interpreter Cartridge Just like PL/SQL stored procedures, the Java language can be used to access Oracle and create HTML documents. Java is an interpreted, object-oriented language that has become very popular as a tool for mapping databases to Web pages. Created by Sun Microsystems, Java has become immensely popular because of the methods it uses to manage Web data. Modules of Java code are known as applets. These applets can be downloaded from the Internet and executed locally on the Web browser, thereby relieving the server of some of its Web processing burden. Oracle recommends that you use the Java Interpreter when you want to handle multimedia operations, interface with “objects” on the Internet, or interact with an OS file system. For database retrieval, Oracle suggests that the PL/SQL Agent should be used since it is faster. Consequently, the Java Interpreter should be used for special tasks, such as spooling reports to a printer or consolidating online images. In Java, class definitions are created, and these definitions are mated with methods, or behaviors. Java objects are declared according to their class definitions, and Java objects are aware of the methods associated with each class definition. In addition, Java objects are aware of other methods in all class definitions above them in the class hierarchy (this is called inheritance). In short, Java is a robust, C++-style, object-oriented language that provides all of the power of object-orientation programming. However, unlike C++, Java does not support pointers, and you cannot create linked memory structures like you can in C and C++. Nonetheless, Java remains a very low-level language, with the natural consequence of being very difficult to read and write. Some of the major benefits of using Java within the context of the Oracle WebServer include: • Reduced maintenance costs—Behaviors are stored within the Java

class definitions and are isolated from the application. Because each method is encapsulated, building blocks are created that may be recombined to easily create new Java behaviors. • Improved flexibility—Because Java objects can be dynamically called and accessed, new Java objects may be created at any time. The new objects may inherit data attributes from one or many other objects. Behaviors may be inherited from superclasses, and novel behaviors may be added without affecting existing Java functions. • Portability—Like its cousin C, Java is extremely portable between hardware platforms. When Java is compiled, the executable is called bytecode. This bytecode is useable by any browser that contains a Java plug-in. Java plug-ins are available from hundreds of sources on the Internet, and it is very simple to Java-enable a Web browser. It is the Java compiler that receives the Java bytecode and translates it into the native code for the machine running the Web browser. Having a Java-enabled browser is said to turn the Web browser into a Java Virtual Machine, meaning that the client can accept Java bytecode and execute the code locally. On the surface, it may appear that Java is intended to run only on the client side. However, Java applets are used heavily on the server side, as well. This is the case with WebServer applets. To execute Java on the Oracle server, the WRB can be used to invoke the Java Interpreter, which dynamically compiles and executes the Java applet, returning the requested information back through the WRB to the Web Listener. Each PL/SQL package that is to be executed through the Java Interpreter must have a package wrapper, which is a Java class containing methods to call the procedures and functions in that package. Oracle WebServer also provides a Java Web Toolkit, which is a collection of packages and procedures that aid in the creation of Java applets for Oracle. Note: Chapter 12 presents an in-depth discussion on Java and the Oracle WebServer.

LiveHTML Cartridge The LiveHTML cartridge is used to include dynamic content within static WebServer Web pages. This content may include static Web pages, other LiveHTML Web pages, system variables, or scripts to be executed on the server that output HTML. LiveHTML is also frequently referred to as Server Side Includes (SSI). Whereas a normal Web page is simply delivered to the Web browser, a LiveHTML page is parsed by the WebServer. In order to execute a LiveHTML call on your Oracle server, it is necessary to configure an Oracle Web Listener (through WebServer Manager) to parse files for LiveHTML. Parsing is a process whereby incoming files are interrogated, or broken down, to see if they contain LiveHTML code. Just like the Java Interpreter, the LiveHTML cartridge can execute PL/SQL packages through the PL/SQL Agent. This added dimension provides more flexible options for building the best applications to meet your functional needs.

Oracle WebServer 3 Architecture The architecture for Oracle WebServer 3 is basically the same as WebServer 2. However, you will gain some additional functionality that will add tremendously to the robustness of Oracle WebServer. The biggest enhancement available is the new Web Transaction Manager, which is based within the Oracle7 database. This tool allows transactions to span multiple HTTP requests (such as insert, update, delete, commit, or rollback), improving the overall performance of your Web system. The Transaction Manager also enables distributed transactions to process against Oracle and non-Oracle databases with extremely high reliability. As was the case with Oracle WebServer 2, the Web Request Broker continues to be a key player in facilitating the advancement of new Web technologies.

Summary Now that we’ve taken a look at the high-level architecture of the Oracle WebServer let’s move on to Chapter 3, which describes the basics of how HTML is used to build Web pages. Then we’ll move on to Chapter 4, where we’ll take a more detailed look at the installation process and the functions of each of the WebServer components, explaining the components, what they do, and how they are installed and utilized. After we have covered the installation and configuration, we’ll take a look at actual examples of how Web applications are designed and implemented.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

CHAPTER 3 Developing Web Pages Using HTML While knowledge of HTML is not a prerequisite for using the Oracle WebServer, the ability to understand how Oracle converts your htp commands into HTML will make the entire scope of the Oracle WebServer very clear. In addition, Oracle WebServer provides a “back door” for the developer to enhance the HTML commands that are generated by WebServer. These back doors are called “cattributes,” and allow the Oracle developer to add additional parameters to the default HTML that is generated by Oracle WebServer. The details for cattributes are listed in the chapter on procedures and functions in Oracle WebServer’s manual. In any case, a good working knowledge of HTML will assist the Oracle developer in creating exciting Oracle-based Web pages. This chapter explores the basics of HTML; it does not pretend to be an exhaustive coverage of this topic. Rather, this chapter is intended to give the Oracle professional a high-level understanding of the conceptual foundations of HTML, so that the nature of the Oracle WebServer will become apparent. For a complete text on HTML development, see the referenced books at the end of this chapter.

What Is A Web Page, Anyway? In general terms, a Web page is an online Windows screen. Just like a local Windows screen, a Web page may contain buttons, scroll bars, and many other Windows “widgets.” In addition, however, by using Hypertext Markup Language (HTML), Web pages can display links, or pointers, to other documents or document areas. In general, a Web page may contain any of the following constructs:

• Text—Plain text, which can appear as basic body text or headings, and can contain a number of font formatting features. • Hyperlinks—Linked text or graphics, which when clicked on by the viewer transfers the user to another section of the current document or to another document on the Internet. • Pictures—Images that are displayed on the Web page. Often, pictures on Web pages are also hyperlinks. • Video—Movie clips, which are appearing on Web pages more and more often as digital video technology evolves. • Audio—Sound clips and background music. • Oracle database data—Data imported from Oracle databases. The basic HTML from this chapter will be extended in later chapters to show how Oracle WebServer is used to attach databases to Web pages.

How Are Web Pages Created? Web pages are created by embedding HTML tags into text documents. Fortunately, the extreme popularity of HTML has led to the creation of tools that automatically generate HTML documents. These tools include Adobe PageMill and Claris. Before you use an HTML editor, it is a good idea to get a handle on the workings of HTML. HTML is easy to use and understand, so in this chapter we will discuss the manual method for creating HTML documents.

The Basics Of Hypertext Markup Language The HTML language is essentially a tagging language. Tagging languages consist of directives that are embedded within text to tell the print/layout software what the text should look like when it is displayed. HTML was preceded by Standard Generalized Markup Language (SGML), which remains very popular today for large printing operations. SGML allows the user to define the structure of the document using tags that must conform to designated standards, or the incoming text will be rejected. HTML inherited the design framework from SGML and, along with it, an existing user base. Just as SGML provides a standard markup language for hard copy text, HTML offers a standard method for tagging text that will be displayed on a Web page. As mentioned earlier, the HTML language consists primarily of tags, or directive statements, that are embedded within a document. All tags are enclosed in angle brackets, and they are not case-sensitive. For example, the following HTML tags are equivalent in function:

In this book, all HTML tags will be displayed in uppercase for ease of reference. In HTML, most tag commands become “turned on” when an opening tag is read in the document and remains turned on until an HTML closing tag terminates the command. It is a good programming practice with

HTML to set a tag to “turned off” when it is no longer needed. Usually, this is done by adding a slash (/) character immediately before the tag name, and placing the closing tag at the end of the formatted section. To illustrate, consider the following example: Using the Oracle WebServer Here we see the tag being turned on, then the title text for the document, and finally, the closing tag indicating the end of the title text. But how do these tags make their way into a document? In practice, there are many tagging tools that can be used to take unformatted text and add the HTML tags so that the document can be displayed on a Web page. Oracle WebServer is one of these products, but WebServer has the enhanced capability of taking data from an Oracle database, tagging the data, and displaying it on your Web page. Alternatively, you could simply type the HTML tags manually into a text or HTML editor. We must note that HTML, like its cousin SGML, has some basic rules that must be followed for a document to conform to the HTML rules: • Begins with and ends with • Usually uses a title tag and a closing title tag • Uses a header tag followed by header data, and a closing header tag • Begins the body of the document with the tag and ends the document • Must reside in a text file suffixed with .html on Unix and Windows 95 and .htm for Windows 3.1. Listing 3.1 illustrates a sample of HTML source code, and Figure 3.1 displays how the source code displays in a browser. Listing 3.1 A sample of HTML.

This makes a red background Using the Oracle WebServer This is a really big header

Now, here is the body of the text

Figure 3.1 Standard HTML tags. Here we see that immediately before the tag we see a tag. The tag says that the following part of the HTML is in the head of the document.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

Formatting The Page Background In addition to text, HTML provides formatting tags for changing background colors and adding background images. Listing 3.1 displays the use of the background color tag. To add background colors and images, use the tags shown in Table 3.1. Table 3.1 Tags for adding a background in an HTML document. Tag

Use

This tag is used to display Web page background colors, where n stands for a hexadecimal color setting or a recognized color name. This tag tiles a background image on a Web page, where n displays as a path to a graphic stored on the server.

Headers Headers are used to separate sections of text on a page. You can control the relative font size of header text, but all header text is formatted by the browser and appears on its own line. Listing 3.2 shows HTML source code used to create the headings displayed in Figure 3.2. Listing 3.2 Sample of HTML for creating headers.

This is the document title

This is a really big header This is a somewhat big header This is a sorta big header

This is an average header This is a tiny header This is a really tiny header

Figure 3.2 Example HTML headers. Figure 3.2 shows the relative sizes and positions of HTML headers, as they appear in Netscape. Page Formatting With HTML Page formatting allows the designer to control the physical layout of the Web page. Page formatting tags include the tags shown in Table 3.2. Table 3.2 Page formatting tags. Tag

Use

Paragraph marker Line break

Horizontal rule line (this tag accepts size, width, and alignment attributes)

Listing 3.3 illustrates the use of these tags, and the results are shown in Figure 3.3. Listing 3.3 Sample of HTML source code using page formatting tags.

This is the document title

This is the page formatting tags Here comes a paragraph mark

This is the beginning of a paragraph Here is a line break
Here is plain horizontal rule (line)

Here is a fat (size=10) horizontal rule

Here is a centered, short (size=10), fat (width=50) horizontal rule

Here is a centered, short (size=50), fat (width=10) horizontal rule

Here is the end

Figure 3.3 Example of horizontal rules for Web page formatting. Other basic formatting tags include the Comment and Preformat tags, shown in Table 3.3. Table 3.3 More formatting tags. Tag

Use Retains the text format appearing in the document (this is handy when displaying short, formatted lists).

The commands and their arguments are explained as follows: • config—This command defines how the LiveHTML code will be parsed. The arguments related to this command include: • errmsg—This argument allows for the specification of an error message encountered during parsing. • sizefmt—When displaying a file size, this argument will determine the format that will be used. The options include abbrev, which presents the size in kilobytes or megabytes, and bytes, which obviously presents the size in bytes. • timefmt—If any dates are displayed on a LiveHTML document, this argument defines their formatting, based on the strftime library calls of Unix. • cmdech—Passing the value ON through this argument will include output from a non-CGI script into an HTML page. Passing the value OFF (which is the default) will not incorporate the output into the document. • cmdprefix—This argument passes text that is attached to the front of all lines of output. • cmdpostfix—The text passed through this argument is attached to the end of every output line. • include—This command allows for a file containing information to be

embedded into a Web page. These files can be of different varieties, including normal HTML files, other LiveHTML files, and ASCII files. The arguments related to this command include: • file—This argument specifies the directory name for the file location, relative to the current directory. • virtual—The virtual directory location of the file to be sourced can be specified with this argument. The mapping of virtual directories within Oracle WebServer is accomplished through the WebServer Manager, as discussed in detail in Chapter 4, Installing And Configuring Oracle WebServer. • echo—This command returns the contents of any environmental variables that may be LiveHTML extensions (Server Side Include variables) or CGI environmental variables. From previous chapters, you know that CGI variables are passed between Oracle WebServer and the browser through environmental variables, regardless of whether the gateway interface used is the CGI or Web Request Broker. The argument related to this command is: • 22 var—This argument is required for the echo command and may contain one of the following LiveHTML variables: • Last_Modified—The date (formatted by the config timefmt command) that the file was last updated. • Document_Name—The name of the file currently in process. • Document_URL—The location of the file to be sourced, as specified through a virtual directory. • Date_GMT—The current date and local time zone in Greenwich mean time. GMT is the default time zone for the processing of cookies by Oracle WebServer and can be adjusted within the WebServer applications through the owa_init package discussed in Chapter 8, WebServer’s OWA Utilities. • Date_Local—The current date and local time zone, defined by the most recent config timefmt command. • Query_String_Unescaped—This environment variable contains the string sent by a client in unescaped format, but with special characters escaped with a ‘\’ (backslash). • fsize—This command produces the file size as indicated by the last processed config sizefmt command. The same arguments apply as for the include command. • flastmod—This command produces the date that the file was last updated as formatted by the config timefmt command most recently processed. The arguments for this command are the same as those for the include command. • exec—This command executes a script on the server file system, which may or may not be a CGI script. The arguments related to this command include: • cmd—This argument enables the execution of a non-CGI script

on the server by specifying the full directory-path location of the script and possibly using the variables specified by the echo command. The config cmdecho command most recently processed determines whether the output from the non-CGI script will be posted to the Web page. • cgi—This argument enables the specification of the virtual directory for a CGI script to be processed on the server. CGI scripts are widely used throughout the Web, but product extensions within Oracle WebServer like LiveHTML are replacing the previously standard processes with improved functionality.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Examples Of LiveHTML In order to appreciate the power of LiveHTML, let’s take a look at an Oracle application that actually uses LiveHTML. In our example, we start by displaying a Web page that can be used to interrogate Unix environmental information. (See Figure 12.6). Here, we see that the Web page displays a series of hypertext links to perform different functions on the host server. This would be a very common application of LiveHTML because the goal of this application is to issue a Unix host command, capture the output of the command in a Unix flat file, and then display the contents of the flat file on the Web page.

Figure 12.6 A sample Web page using LiveHTML. As you can see in Figure 12.6, the Web page allows an Oracle developer to access information about specific characteristics of the Unix server. The Oracle developer can press any of the hypertext links to invoke the LiveHTML embedded in the hypertext links. Listing 12.22 shows the Oracle stored procedure code that generated the Web page in Figure 12.6. Listing 12.22 The Oracle stored procedure for the Unix environment query Web page. create or replace procedure s99 as host_name_in varchar2(20); cursor c1 is select host_name from host order by host_name; host_rec c1%ROWTYPE; BEGIN htp.htmlOpen; htp.headOpen; htp.title('s00'); htp.preOpen;

htp.header(1,' htp.header(1,' htp.headClose; htp.preClose;

Oracle Information Database'); Online Oracle Report Menu','C');

htp.bodyOpen; htp.formOpen(owa_util.get_owa_service_path || 's99'); htp.FormHidden('host_name_in', host_name_in); htp.FormSelectOpen('host_name_in','Choose the Host:'); open c1; loop fetch c1 into host_rec; EXIT WHEN c1%NOTFOUND; htp.formSelectOption(host_rec.host_name); end loop; close c1; htp.formSelectClose; htp.header(2,'Unix Environmental Reports','C'); htp.anchor('http://hostname.com:8888/ssi/tnsnames.html', 'tnsnames.ora file.'); htp.anchor('http://hostname.com:8888/ssi/df.html', 'File system information. (df -k)'); htp.FormClose; htp.bodyClose; htp.htmlClose; end; / show errors Now, let’s take a closer look at how this Web page functions. The first option is designed to take a look at the Unix file system on the Unix server and then display the tnsnames.ora file information on the Web page. The second option issues a Unix df -k command and pipes the output into a flat file. What’s happening to cause this listing? Let’s begin by examining the following hypertext link: htp.anchor('http://hostname.com:8888/ssi/tnsnames.html', 'tnsnames.ora file.'); This hypertext link specifies that WebServer is to execute a procedure called tnsnames.html, located in the ssi directory, as specified in the WebServer directory mapping administration page. Listing 12.23 shows the contents of the tnsnames.html HTML document. Listing 12.23 An HTML document with LiveHTML.

LiveHTML (Server Side Includes) Example

This will take the listing and format it into a Web page for display on your browser. Figure 12.7 shows the output of this procedure.

Figure 12.7 Sample output listing with LiveHTML. To complete the picture, let’s take a look at Listing 12.25, which shows the HTML code generated to display the contents of the tnsnames.ora file. Listing 12.26 shows the actual contents of this file. Listing 12.25 HTML code for displaying a file on the host.

LiveHTML (Server Side Includes) Example

Listing 12.26 Contents of tnsnames.ora file. Wed Dec 11 10:29:23 EST 1996 ################ # Filename......: tnsnames.ora # Node..........: joey.world # Date..........: 26-Aug-96 01:00:24 ################ howard = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = TCPCOMM) (PROTOCOL = TCP) (Host = sandbox) (Port = 1600) ) ) (CONNECT_DATA = (SID = DBAP) ) ) william = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = TCPCOMM) (PROTOCOL = TCP) (Host = sandbox) (Port = 1600) ) ) Here, you can see that the spooled output listing from the C shell script has been tagged for HTML display. This should complete the picture of how LiveHTML can be used to include Unix files and execute Unix scripts on a server.

Summary Now that we have looked at the usage for Java and LiveHTML in a WebServer environment, we can move on to the performance and tuning of the Oracle server. Regardless of how well you have tuned your WebServer engine, the bulk of the application work will still be done within the Oracle database. With the Oracle database becoming your weakest link, the following chapters are dedicated to improving the performance of the Oracle engine with an eye toward creating fast and efficient WebServer applications.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

CHAPTER 13 Using SQL*Net For WebServer Communication In a WebServer application, it is unusual for all of the databases to be on the same host as the WebServer engine. Rather, we expect to see Oracle databases distributed onto other host computers and Oracle’s SQL*Net used as the backbone for communications. Distributed Oracle systems enable load-balancing of the subsets of an application, giving each subset of data its own dedicated CPU. In a fully distributed Oracle environment, the WebServer exists as a standalone application on one server while the Oracle databases exist on remote servers. Whenever you have this type of distributed Oracle architecture, you must carefully examine the connectivity issues, so WebServer developers will be able to process data from all of the Oracle servers, regardless of their physical location. This requires a good understanding of SQL*Net, database links, table replication techniques, and distributed Oracle design. This chapter should give you a conceptual understanding of the role of SQL*Net and how it fits into the overall WebServer architecture.

Location Transparency And WebServer Connectivity Location transparency refers to the ability of a distributed database to function as a unified whole, appearing to developers as a single, unified Oracle database. Where the database resides, what type of database is used, or the required database access methods are all unimportant to end users, and a good design can greatly enhance the creation of WebServer applications. To understand location transparency, let’s assume that we have a parts inventory system with separate databases in San Francisco, New York, and Chicago. Let’s also

assume that this is a horizontally partitioned database with inventory tables at each location. (A horizontal partition is a very large table that is split into smaller tables, each with the remote site’s data.) Because of this partitioning of the INVENTORY table, it is impossible to directly issue a single SQL command to get the contents from the INVENTORY table at all three locations. However, through the magic of SQL*Net, it’s possible to make remote tables appear as single unified tables. So, if a manager wishes to know the number of widgets on hand in all locations, she could issue the following SQL command to the distributed database manager: select count(*) from INVENTORY where partname = 'widget'; Because we have implemented data location transparency with SQL*Net, the end user does not know or care what databases are interrogated to satisfy his request. In the previous example of count(*) with location transparency, the end user has no interest in any individual databases when servicing the request, defining it as a global transaction. The transaction manager has the responsibility to query all of the distributed INVENTORY tables and collect the counts from each table, merging them into a single result set. In Oracle with SQL*Net, creating database links to the remote database and assigning a global synonym to the remote tables achieves location transparency. At the lowest level, computers are identified by an Internet Protocol (IP) address, which gives the computer a distinct number. An example would be 222.223.90.27. The IP address is associated with a server name using a Unix file called hosts. Table 13.1 shows how these items are associated within an Oracle environment. Item

Table 13.1 Associating database names and Unix addresses. Unix Location Example Definition

Telnet

/etc/hosts

jason

Database TNS Service

/etc/oratab /etc/tnsnames.ora

custserv custserv

Associates IP addresses with Telnet names Lists the Oracle system IDs Defines a protocol, server, and database

The three files—hosts, oratab, and tnsnames.ora—provide Oracle with the necessary information to uniquely identify each distributed database. In databases such as Oracle with SQL*Net, transparency is achieved by creating database links to remote databases and then assigning a global synonym to the fully qualified table name. Database links are created in Oracle by specifying three items: name of the database link, transparent network substrate (TNS) service name for the remote database (as defined in the SQL*Net tnsnames.ora file), and name of the Oracle user ID initiating the transaction on the remote server. Transparent network substrate is a fancy term for a single, common interface to all protocols that enables end users to connect to databases in physically separate networks. At the lowest level, TNS communicates to other databases with message-level send/receive commands. In the following example, omaha.com is the database link, and it connects to the omaha_server TNS service using the oracle_user_profile user ID: create public database link omaha.com

connect to omaha_server using oracle_user_profile; Now that we have defined the location name, we can include tables from any of the omaha sites by qualifying the remote site name in the SQL query. In the following example, we join the EMPLOYEE table in omaha with our local SKILLS table: select

EMPLOYEE.employee_name, SKILLS.skills_date from [email protected], SKILLS where EMPLOYEE.emp_number = SKILLS.employee_number order by skills_date

;

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

But how do we hide the fact that the EMPLOYEE table resides in omaha? To make the location of this table transparent to the developer, the DBA may assign synonyms for the EMPLOYEE table in omaha that would make the query appear to be a local table: create synonym EMPLOYEE for EMPLOYEE@omaha; The query can now be run with full location transparency: select from

EMPLOYEE.employee_name, SKILLS.skills_date EMPLOYEE, SKILLS

where EMPLOYEE.emp_number = SKILLS.employee_number order by skills_date ; Note: It is important to understand which Oracle instances are servicing this request. Obviously, the omaha instance is responsible for retrieving the EMPLOYEE rows, but it is not so apparent that it’s the initiating instance’s job to perform the merge sort for the join. The local instance will also be the server that will sort the result set by skills_date. Therefore, if you are issuing this type of distributed request from a WebServer host, you need to ensure that your local WebServer database has enough space in the temporary tablespace and that the sort_area_size init.ora parameter is large enough to handle the sorting operations.

Oracle stored procedures can also be defined to allow for location transparency. Because the exact table name and TNS location is hidden inside the stored procedure, the developer who calls the routine can access the remote table without any reference to its physical location. For example, the following procedure could be defined to allow updates to the EMPLOYEE table in omaha: create procedure add_employee (emp_name char(8)) as begin insert into EMPLOYEE@omaha. values (emp_name); end; This procedure could be called with a single statement:

add_employee("Rick Tytler"); Location transparency can be very useful for hiding the complexity of a distributed Oracle system, but there is much more to the story. Oracle Database Domains Most WebServer developers recognize the need to organize and manage remote locations of databases while providing location transparency to key developers. To Oracle, the term domain is used to define each remote database. Domains are especially important in situations of horizontal partitioning. Horizontal partitioning occurs when tables with identical names are kept in numerous locations. Domains can be used within Oracle to establish a logical hierarchy of physical locations for all of the databases that participate in the WebServer application. The sample database shown in Figure 13.1 establishes a domain hierarchy for remote databases.

Figure 13.1 Example of a WebServer TNS domain model. Each node in the network shown in Figure 13.1 assigns synonyms for all unique tables within the distributed network. For duplicate table structures existing at many locations, abbreviated domains can be created. Assume that both Japan and Ohio have an EMPLOYEE table, identical in structure but containing different rows. We could assign Oracle synonyms as follows: create synonym japan_employee for create synonym ohio_employee for

[email protected]; [email protected];

Intersystem Connectivity With WebServer SQL*Net makes it easy to allow cross-database access, so the issue of intersystem connectivity must be understood. In a distributed Oracle system, you may see any of the following types of table partitioning: • Table Replication—Tables are copied to remote locations using Oracle’s snapshot facility. • Vertical Partitioning—Tables are sliced vertically, placing different columns of the same logical table in remote locations. • Horizontal Partitioning—Tables are sliced by row, placing logically related rows in different physical locations. • Functional Partitioning—Different functional tables exist in different remote locations. One very common method of Oracle database distribution is to use horizontal partitioning, where different rows exist at remote locations and SQL*Net makes the remote tables appear as a single table. For example, employee service organizations commonly allow their remote sites to maintain employee information and maintain a location-transparent access mode to every employee, regardless of their physical location. Horizontal partitioning is achieved by taking a subset of each remote site’s EMPLOYEE table and populating a master lookup table that is accessible from any node in the distributed system (see Figure 13.2).

Figure 13.2 Horizontal data partitioning of a master lookup table for a distributed WebServer application. In a WebServer system, the Unix cron utility can be used to schedule a periodic refresh of the master table. cron is short for chronological, and it’s the name of the Unix utility used to schedule jobs. As such, cron is a time-dependent task activation utility that starts tasks at predetermined dates and times. An SQL script would automatically extract employee_name from the remote site and repopulate the master EMPLOYEE table, leaving the employee details at the remote site. The Oracle SQL might look like this: /*

Delete remote rows in the master table... */

delete from employee@master where location = :our_site; /*

Repopulate the master table...

*/

select employee_name, ":our_site" from employee@:OUR_SITE as insert into employee@master values employee_name, site_name; Once populated, the master lookup table can be accessed by any node and used to redirect the database query to the appropriate remote database for employee detail (see Figure 13.3).

Figure 13.3 Example of location transparency for a distributed WebServer application. Because of dynamic substitution in SQL, a common application can be made to access any employee in the federation, regardless of the location and without any coding changes. For a complete description of these techniques, refer to the text Managing Distributed Databases by Donald K. Burleson, published by Wiley-QED Publishing. Now that we understand how to make each location transparent to the WebServer application, let’s explore the internals of Oracle’s SQL*Net. SQL*Net is a powerful tool that allows many different configurations. A good knowledge of SQL*Net and all of its possible configurations will greatly aid WebServer administrators in providing fast and seamless inter-database communications.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Internals Of Oracle’s SQL*Net In its most basic form, SQL*Net is a software tool that enables a network of Oracle clients and servers to communicate transparently on top of any underlying network topology or protocol using SQL. Although SQL*Net is a robust and sophisticated tool, you must appreciate the inherent complexity that goes along with the flexibility of SQL*Net. Due to the sophisticated architecture of SQL*Net, it’s not trivial to install SQL*Net on the WebServer or any of the remote servers. Because we are dealing with a WebServer front end, it’s important to note that the WebServer host will be the client, while the remote Oracle databases will be the servers. For a general overview of the SQL*Net architecture, let’s begin by looking at the control files for SQL*Net. In Unix systems, the following four files are necessary to operate SQL*Net 2.0: • tnsnames.ora—Used for outgoing database requests, this file contains all of the database system identifiers (SIDs) running on the processor, as well as the domain name, protocol, host, and port information. When a new database is added to a server, you must update this file (changes to tnsnames.ora become effective instantly). Note that the SQL*Net version 1.0 equivalent to Oracle’s tnsnames.ora file is the /etc/oratab file. • listener.ora—This file contains a list of local databases for use by incoming connections. When you add a new destination database to a Unix host, you must also add it to this file. • hosts—This file lists all of your network addresses. • services—This file lists all of the SQL*Net services. On some flavors of Unix, such as HP-UX, these files are located in the /etc directory. For Solaris Unix, the .ora files are located in the /var/opt/ oracle directory.

In SQL*Net version 2.0, Oracle has added several important enhancements. Aside from the badly needed bug fixes, SQL*Net now allows access to multiple communities. A community is a group of computers that share a common communications protocol (such as TCP/IP to LU6.2). In addition, the Oracle7 database engine now allows for the creation of a multithreaded server (MTS) for servicing incoming data requests. In an MTS, all communication to databases is handled through a single dispatcher, rather than a separate process being spawned for each incoming database connection, as is the case with SQL*Net version 1.0. When upgrading from SQL*Net 1.0 to SQL*Net 2.0, you should be aware of subtle differences between how the two versions handle communications. (See Figure 13.4.) SQL*Net version 1.0 uses an orasrv component on the destination database to listen for incoming requests, while SQL*Net 2.0 uses a process called tnslsnr (TNS listener). In addition, SQL*Net 1.0 cannot use an MTS.

Figure 13.4 A comparison of the two versions of SQL*Net. When a connection is made to SQL*Net, it passes the request to its underlying layer—the TNS—where the request is transmitted to the appropriate server. At the server, SQL*Net receives the request from the TNS and passes the SQL to the database. On the client side, the User Programmatic Interface (UPI) converts SQL to associated parse, execute, and fetch statements. The UPI parses the SQL, opens the SQL cursor, binds the client application, describes the contents of returned data fields, executes the SQL, fetches the rows, and closes the cursor. Oracle attempts to minimize messages to the server by combining UPI calls whenever possible. On the server side, the Oracle Programmatic Interface (OPI) responds to all possible messages from the UPI and returns requests. All of this work is done after the request has been spawned through the Web Listener and the Web Request Broker. Hence, there are many intermediate steps that a WebServer request must perform before actually retrieving the Oracle data. To further complicate matters, no UPI exists for server-to-server communication. Instead, a Network Programmatic Interface (NPI) resides at the initiating server, and the responding server uses its OPI for the request. SQL*Net supports network transparency so that the network structure may be changed without affecting the SQL*Net application. Location transparency is achieved with database links and synonyms. Let’s trace a sample WebServer data request through SQL*Net. The following steps are performed: 1. A request is intercepted by the Web Listener, which spawns a process connection to the Web host processor.

2. The request is then passed to the Web Request Broker (WRB), or the Common Gateway Interface (CGI) for WebServer version 1.0. 3. The request is then directed to the SQL*Net listener on the WebServer host. For PL/SQL requests, the stored procedure is then extracted from the WebServer’s local Oracle database. 4. The stored procedure is then interpreted, and all references to remote Oracle databases are resolved. Requests are sent to each of the remote databases, where their SQL*Net listeners intercept and service the requests. 5. The Oracle transaction manager then receives the data from each of the remote requests and performs all necessary sort and merge operations, delivering a single solution set for the SQL request. 6. The solution set is then passed back to the Web Request Broker (or CGI), which, in turn, passes the data back through the Web Listener to the requesting WebServer client. But wait, it gets even more complex. As each data request is processed by the WebServer host, SQL*Net looks for the link name in the database link table (DBA_DB_LINKS) and extracts the service name. The service name is then located in the tnsnames.ora file, and the host name is extracted. Once again, we have a three-stage process beginning with the link name referencing the service name, and then the service name referencing the host name.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

In Unix environments, the host name is usually found in a host file (/etc/hosts), and the Internal Protocol (IP) address is gathered. In the following example, omaha_server might translate into an IP address of 143.32.142.3. The following four steps illustrate how SQL*Net takes a remote request and translates it into the IP address of the destination database: 1. Issues a remote request, and checks the database link called omaha. select * from EMPLOYEE@omaha; 2. The database link gets the service name (omaha_server_d) using the link_name (omaha). create public database link omaha connect to omaha_server_d; 3. tnsnames.ora gets the SID name (omaha_sid) using service name (omaha_server_d). omaha_server_d = (description=(address=(protocol=tcp) (host=bluegill) (port=1521) (connect_data=(sid=omaha_sid) (server=dedicated))) 4. /etc/hosts gets the IP address (143.32.142.3) using the SID name (omaha_sid). 143.32.142.3

omaha_sid

omaha_server.corporate.com

As you can see, this translation occurs in a multistage process. The tnsnames.ora file specifies the name of the host containing the destination database. For Unix environments, this host name is then looked up in the /etc/hosts file to get the IP address of the destination box. Note that the service name is looked up in tnsnames.ora — if the service exists, the IP address is found in the /etc/hosts file, and a communications request is sent to the destination IP address. Both of the entries in this file connect to omaha, but omaha_server_d directs SQL*Net to spawn a dedicated process, while omaha_server uses the multithreaded server component because a shared server is specified. Now that you have the tnsnames.ora and /etc/hosts files in place, you can include any tables from the omaha sites by qualifying the remote site name in the SQL query.

select EMPLOYEE.employee_name, SKILLS.skills_date from EMPLOYEE@omaha, SKILLS where EMPLOYEE.emp_number = SKILLS.employee_number; Note that this query joins two tables at different locations, and the database link called omaha determines how the Oracle connection will be established on the destination system. However, regardless of how the connection is made to the destination, the user ID must have select privileges against the EMPLOYEE table, or this query will fail. Application Connection With SQL*Net Connections to remote databases can be made by specifying either the service names or connect strings. For SQL*Net, connect strings use the full connection, specifying the protocol:server:database. In the following example, the t: means a TCP/IP connection, host: is the name of the remote processor, and database: is the name of the databases on the host processor. The format for the two selections are: • Connect via a service name—emp@my_db • Connect via a server connect string—sqlplus /@t:host:database Connect strings are stored in the DBA_DBLINKS table and are created with the create database link command, as follows: create public database link ny_emp for ny_emp@t:myhost:mydatabase; SQL*Net can establish database communications via three methods: remote connection, remote request, or distributed request. A remote connection is the easiest way to make a database connection. The sending database simply makes a request by specifying a table name suffixed by @. SQL*Net takes it from there, seamlessly accessing the remote database and returning the data to the initiating system. Communication is established by making a distributed request to a remote database. Within Oracle, @ specifies the remote database name, but the functionality of the @ operator depends on where it’s used. Here’s an example: sqlplus scott/tiger@omaha select count(*) from EMPLOYEE; count(*) —————— 162 In this request, scott is using SQL*Plus to connect to the omaha database, and @omaha is the service name, as defined in the tnsnames.ora file. SQL*Net recognizes this as a remote connection and determines the appropriate linkage to establish communications with omaha. Internally, Oracle will check the tnsnames.ora file to ensure that omaha is a valid destination. However, there is another way of connecting to omaha from the same database. This is called a remote request. Following is an example of a remote request: sqlplus scott/tiger select count(*) from EMPLOYEE@omaha; count(*) ——————— 162 Unlike a remote connection made directly from SQL*Plus, the remote request has scott connecting

to the local copy of SQL*Plus to specify the remote table (in this case, EMPLOYEE@omaha). For a remote request to work, a database link must define omaha. A database link is a connection pathway to a remote database that specifies the service name of the remote database. Without the database link, the following request would fail: sqlplus jenny_burleson/secret_password select count(*) from EMPLOYEE@omaha; This request will give you the following error message: ORA-02019: Connection description for remote database not found. This error message results from the way Oracle defines the @ operator for remote connections. When entering an Oracle service, such as SQL*Plus from the Unix command prompt, the @ operator will go directly to the tnsnames.ora file to manage a request. Conversely, using the @ operator from within an Oracle program will direct Oracle to use a database link, and the database link will provide the service name that is looked up in the tnsnames.ora file. To make the call function properly, you must define a database link that specifies the service name used to establish the connection. Note that the database link name and service name are the same in the following example, but the database link and the connect descriptor are not related in any way: create database link omaha using 'omaha'; select count(*) from EMPLOYEE@omaha; count(*) ——————— 162

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

Let’s take a closer look at a database link. In this simple example, no mention is made of the user ID used to establish the connection on the remote database. Because scott is the user connecting to SQL*Plus, scott will be the user ID when the remote connection is established to the omaha database. Therefore, scott must have select privileges against the EMPLOYEE table in omaha in skills for the query to work properly. scott’s privileges on the initiating Oracle database have no bearing on the success of the query. Note: If you are using the Oracle Names facility, you must be sure that your database service names are the same as the global_databases_names and the domain init.ora parameter.

In cases where select security is not an issue, you can enhance the database link syntax to include a remote connect description: create database link omaha using 'omaha' connect to SCOTT1 identified by TIGER1; This way, all users who specify the omaha database link will connect as scott1 // and will have whatever privileges scott1 // has on the omaha system. Once you establish a communications pathway to the remote database, it is often desirable to implement location transparency. In relational databases such as Oracle, you can obtain location transparency by creating database links to the remote database and then assigning a global synonym to the remote tables. The database link specifies a link name and an SQL*Net service name. You can create database links with a location suffix that is associated with a host name (in this example, omaha_server). You can use database links to allow applications to point to other databases without altering the application code. For data warehousing applications, you can replicate a table on another machine and establish links to enable the application to point transparently to the new box containing the replicated table. To see the links for a database, query the Oracle dictionary in the following manner: select distinct db_link from DBA_DB_LINKS; Keep in mind that SQL*Net bypasses all operating system security settings when it connects to a database. All user accounts identified externally (that is, without an Oracle password) will not be allowed in SQL*Net transactions unless the init.ora parameter is changed. The identified externally clause (sometimes called OPS$) in Oracle version 6 allowed the operating system to manage passwords, but because SQL*Net bypasses the operating system, impostor accounts could be created from other platforms. For example, a Unix user running a PC-based Unix operating system such as Coherent could set their user ID to anyone they desired, and then connect with SQL*Net to any remote database with all database privileges consistent with the user ID. Consequently, Oracle now recommends that identified externally accounts be forbidden for distributed connections. It is interesting to note that Oracle will allow you to create accounts with an OPS$ prefix. Therefore, the

operating system can manage its passwords, while you also have passwords within Oracle. For example, assume the following user definition: create user ops$scott identified by tiger; Assuming that scott has logged onto the operating system, scott could enter SQL*Plus either with or without a password, as follows: sqlplus / sqlplus scott/tiger This ability to connect directly to Oracle presents a confounding issue with password management. Because two sets of passwords exist—one in the operating system and another in Oracle—you may need a third-party tool to keep the passwords synchronized. Understanding The SQL*Net Listener Each version of Oracle has its own listener process. For SQL*Net version 1.0, the listener process is called orasrv, and the SQL*Net version 2.0 listener process is called tnslsnr. Using the Unix ps command, you can see the listener processes running on your server, as shown in Listing 13.1. Listing 13.1 A sample Unix ps command. ps -ef|grep ora oracle 1201 1 80 Nov LISTENER -inherit oracle 934 1 3 Nov oracle 1443 1 83 Nov u00/dba/oracle/app/orac oracle 1231 1 80 Nov /u00/dba/oracle/app/orac

13 0:02

/u00/oracle/product/7.3.2/bin/tnslsnr

13 0:00 13 0:32

orasrv /u00/oracle/product/7.3.2/bin/oraweb -C

13 0:02

/u00/oracle/product/7.3.2/bin/wrb2 16 4

From Listing 13.1, we can see the SQL*Net listeners, WebServer listener, and Web Request Broker running on this server. To see what the Oracle listeners are doing, Oracle provides a series of listener commands, which include: • reload—Refreshes the listener • start—Starts the listener • stop—Stops the listener • status—Shows the status of the listener • services—Shows all connected services for the listener There are three listeners that accept and activate these commands. The activation commands are as follows: • tcpctl—Command to the SQL*Net v 1 Listener • lsnrctl—SQL*Net v 2 Listener • wlctl—Web Listener

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

Therefore, if we wanted to check the status of the SQL*Net version 2.0 Listener, we could issue the command lnsrctl stat. Listing 13.2 shows the output of the lsnrctl stat command. Listing 13.2 A sample output from the SQL*Net Listener command. [oracle]ram2: lsnrctl stat LSNRCTL for HPUX: Version 2.0.15.0.0 - Production on 16-SEP-94 15:38:00 Copyright (a)

Oracle Corporation 1993.

All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=TCP)(HOST=ram2)(PORT=1521)) STATUS of the LISTENER ———————————— Alias LISTENER Version TNSLSNR for HPUX: Version 2.0.15.0.0 - Production Start Date 29-AUG-94 13:50:16 Uptime 18 days 1 hr. 47 min. 45 sec Trace Level off Security OFF Listener Parameter File /etc/listener.ora Listener Log File /usr/oracle/network/log/listener.log Services Summary... dev7dba has 1 service handlers ram2dba has 1 service handlers The command completed successfully lsnrctl services

- lists all servers and dispatchers

[oracle]bluegill: lsnrctl services LSNRCTL for HPUX: Version 2.0.15.0.0 - Production on 16-SEP-94 15:36:47 Copyright (a)

Oracle Corporation 1893. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=TCP)(HOST=bluegill)(PORT=1521)) Services Summary... ftdab000 has 4 service handlers DISPATCHER established:1 refused:0 current:2 max:55 state:ready D001 (machine: bluegill, pid: 4146)

(ADDRESS=(PROTOCOL=tcp)(DEV=5)(HOST=141.123.224.38)(PORT=1323)) DISPATCHER established:1 refused:0 current:2 max:55 state:ready D000 (machine: bluegill, pid: 4145) (ADDRESS=(PROTOCOL=tcp)(DEV=5)(HOST=141.123.224.38)(PORT=1321)) DISPATCHER established:0 refused:0 current:1 max:55 state:ready D002 (machine: bluegill, pid: 4147) (ADDRESS=(PROTOCOL=tcp)(DEV=5)(HOST=141.123.224.38)(PORT=1325)) DEDICATED SERVER established:0 refused:0 The command completed successfully As a service request is intercepted by an Oracle server, the listener may direct the request via a dedicated server, an MTS, or an existing process (also known as a prespawned shadow). The key is whether the connection contacts the listener via a service name or bypasses the listener with the two_task connect string. If the listener is contacted as part of the connection and the MTS parms are defined to init.ora, the client will use the MTS. There are five basic listener commands: reload, start, stop, status, and services. Based on the request, the listener decides whether to dispatch a connection to a dedicated-server process (which it spawns) or to use the MTS. The programmer has several options when deciding how Oracle will manage the process. Dedicated requests can be specified by a version 1.0 connect string or by using a service name that specifies server=dedicated in the tnsnames.ora file. Managing SQL*Net Connections Listing 13.3 describes some of the utilities you can use to manage SQL*Net sessions effectively. You should be aware that some of the examples in this section are operation system–independent and may not apply to your environment. Listing 13.3 Commit point strength. commit.sql - Reports the commit point strength for the database. set feedback column name column type column value

off format a30 heading 'Name' format a7 heading 'Type' format a60 heading 'Value'

prompt Commit Point-strength Report Output: prompt prompt select name, decode(type,1,'boolean', 2,'string', 3,'integer', 4,'file') type, replace(replace(value,'@','%{sid}'),'?','%{home}') value from v$parameter where name = 'commit_point_strength';

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Managing Oracle’s Multithreaded Server One of the problems with SQL*Net version 1.0 was that each incoming transaction was spawned by the listener as a separate operating system task. With SQL*Net version 2.0, Oracle now has a method for allowing the listener connection to dispatch numerous subprocesses. With the MTS, all communications to a database are handled through a single dispatcher instead of separate Unix process IDs (PIDs) on each database. This translates into faster performance for most online tasks. Even local transactions will be directed through the MTS, and you will no longer see a PID for your local task when you issue the Unix command ps -ef|grep oracle. However, be aware that the MTS is not a panacea, especially at times when you want to invoke a dedicated process for certain WebServer connections. For a process that has little idle time, such as an intensive table update with WebServer (and also Pro*C programs or I/O-intensive SQL*Forms applications), you will get better performance if you bypass the MTS and use a dedicated process connection. In general, the MTS offers benefits, such as reduced memory use, fewer processes per user, and automatic load balancing. Remember the following rules of thumb when initially starting the MTS: • The MTS is governed by the init.ora parameters. If no MTS parms are present in init.ora, the MTS is disabled. • The MTS is used when the MTS parms are in the init.ora and requests are made by service name (such as @my_database). In other words, you must retrieve the rowid of all version 1.0 connect strings (such as t:unix1:my_database). • Each user of the MTS requires 1 K of storage, so plan to increase your shared_pool_size. • The V$QUEUE and V$DISPATCHER system tables indicate whether the number of MTS dispatchers is too low. Even though the number of dispatchers is specified in the init.ora file, you can change it online in SQL*DBA with the alter system command, as follows: SQLDBA> alter system set mts_dispatchers = 'TCPIP,4';

• If you encounter problems with the MTS, you can quickly regress to dedicated servers by issuing an alter system command. The following command turns off the MTS by setting the number of MTS servers to 0: SQLDBA> alter system set mts_servers=0; • In order to use OPS$, you must set two init.ora values to true (the default is false), as follows: remote_os_authent = true remote_os_roles = true • When both SQL*Net 1.0 and 2.0 are installed, the user may connect to the server via a dedicated server or the MTS. However, you cannot stop and restart the listener when connecting via the MTS. You must connect to SQL*DBA with a dedicated server. • In some cases, the instance must be bounced if the listener is stopped, or it will restart in dedicated mode. Whenever an instance is to be bounced, stop the listener, shut down the instance, restart the listener, and start up the instance. The listener reads the MTS parameters only if it’s running before startup of the instance. Therefore, bouncing the listener will disable the MTS. Managing The Listener Processes The listener is a software program that runs on each remote node and “listens” for any incoming database requests. When a request is detected, the listener may direct the request to any of the following: • Dedicated server • Multithreaded server • Existing process or prespawned shadow Note that the configuration of an Oracle listener is a direct result of the parameters specified in the startup deck for the Oracle database. This parameter file is called init.ora and will contain the parameters used to define the multithreaded server and listener, as shown in Listing 13.4. Listing 13.4 init.ora parameters for the multithreaded server. #———————————# Multithreaded Server #———————————MTS_DISPATCHERS

= "tcp,3"

MTS_LISTENER_ADDRESS = "(ADDRESS=(PROTOCOL=tcp) (HOST=bluegill) (PORT=1521))" MTS_MAX_DISPATCHERS

= 5

MTS_MAX_SERVERS

= 20

#—————————————# Distributed systems options #—————————————-

DISTRIBUTED_LOCK_TIMEOUT

= 60

DISTRIBUTED_RECOVERY_CONNECTION_HOLD_TIME = 200 DISTRIBUTED_TRANSACTIONS

= 6

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Managing Two-Phase Commits (2PCs) In some cases, you may want your WebServer application to issue updates against two or more remote databases in a single SQL command. When a distributed update (or delete) has finished processing, SQL*Net will coordinate commit processing, which means that the entire transaction will roll back if any portion of the transaction fails. The first phase of this process is to issue a prepare phase to each node, followed by the commit, and then terminated by a forget phase. If a distributed update is in the process of issuing the 2PC and a network connection breaks, Oracle will place an entry in the DBA_2PC_PENDING table. The recovery background process (RECO) will then roll back or commit the good node to match the state of the disconnected node to ensure consistency. You can activate RECO via the alter system enable distributed recovery command. The DBA_2PC_PENDING table contains an advise column that directs the database to either commit or roll back the pending item. You can use the alter session advise syntax to direct the 2PC mechanism. For example, to force the completion of an insert, you could enter the following: alter session advise commit; insert into payroll@omaha. .. ; When a 2PC transaction fails, you can query the DBA_2PC_PENDING table to check the state column. You can enter SQL*DBA and use the Recover In-Doubt Transaction dialog box to force either a rollback or a commit of the pending transaction. If you do this, the row will disappear from DBA_2PC_PENDING after the transaction has been resolved. If you force the transaction the wrong way (for example, rollback when other nodes committed), RECO will detect the problem, set the mixed column to yes, and the row will remain in the DBA_2PC_PENDING table. Internally, Oracle examines the init.ora parameters to determine the rank that the commit processing will take. The commit_point_strength init.ora parameter determines which of the distributed databases is to be the commit point site. In a distributed update, the database with the largest value of commit_point_strength will be the commit point site. The commit point site is the database that must successfully complete before the transaction is updated in the other databases. Conversely, if a transaction fails at the commit point site, the entire transaction will be rolled back at all of the other databases. In general, the commit point site should be the database that contains the most critical data. Listing 13.5 shows a script that identifies 2PC transactions that have failed to complete. Listing 13.5 pending.sql reports on any pending distributed transactions. set pagesize 999; set feedback off;

set wrap on; column local_tran_id column global_tran_id column state column mixed column advice select from skills

format format format format format

a22 a50 a16 a5 a5

heading heading heading heading heading

'Local Txn Id' 'Global Txn Id' 'State' 'Mixed' 'Advice'

local_tran_id,global_tran_id,state,mixed,advice dba_2pc_pending by local_tran_id;

Viewing SQL*Net Sessions On systems running SQL*Net version 2.0, the following SQL*Plus script can be used to query the number of dedicated and shared servers on the system. For example, Listing 13.6 shows an SQL*Plus script to view all sessions. Listing 13.6 session.sql displays all connected sessions. set echo off; set termout on; set linesize 80; set pagesize 60; set newpage 0; ttitle "dbname Database|UNIX/Oracle Sessions"; spool /tmp/session set heading off; select 'Sessions on database '||substr(name,1,8) from v$database; set heading on; select substr(b.serial#,1,5) ser#, substr(b.machine,1,6) box, substr(b.username,1,10) username, substr(b.osuser,1,8) os_user, substr(b.program,1,30) program from v$session b, v$process a where b.paddr = a.addr and type='USER' skills by spid; ttitle off; set heading off; select 'To kill, enter SQLPLUS> ALTER SYSTEM KILL SESSION', ''''||'SID, SER#'||''''||';' from dual; spool off; [oracle]ram2: sqlx session Wed Sep 24 Page 1 ram2db Database Sessions for SQL*Net SERVER

Oracle user

——————

——————————

DEDICATED

JAME_GASTON

O/S

User

Machine Program

————

————

—————————————

jgaston

ram2

sqldba@ram2 (Pipe Two-Task)

DEDICATED

LINDA_ODELL

lodell

ram2

runform30@ram2 (Pipe TwoTask)

DEDICATED

RICK_WAHL

rwahl

ram2

sqlplus@ram2 (Pipe Two-Task)

DEDICATED

MARK_REULBACH

mreulbach

dlt2

sqlplus@clt2 (TNS interface)

DEDICATED

BOB_PAPAJ

bpapaj

ram2

?

DEDICATED

DEB_SCHUMACHER dschumacher ram2

runmenu50@ram2 (Pipe TwoTask)

DEDICATED

KAREN_CHAN

kchan

sqlplus@ensc (TCP Two-Task)

DEDICATED

MARC_MASCARO

mmascaro

DEDICATED

KELVIN_CONNOR

kconnor

ram2

sqlplus@ram2 (Pipe Two-Task)

DEDICATED

STEVE_WOHL

swohl

ram2

sqlforms30@ram2 (Pipe TwoTask)

DEDICATED

CRISTAL_WONG

cwong

ram2

RUN_USEX@ram2 (Pipe TwoTask)

xnsc

@ram2 (TCP Two-Task)

C:\PB3\PBSYS030.DLL

11 rows selected. Here we see each of the four types of SQL*Net connections: • Pipe Two-Task—Used for internal tasks (SQLPLUS /). • TNS Interface—Used when a connection is made with a v2 service name (SQLPLUS /@ram2). • TCP Two-Task—Used when a connection is made with a v1 connect string (SQLPLUS /@t:ram2:ram2db). • PC Connection Task—Denoted by the PC DLL name (c:\pb3\pbsys030.dll, which was initiated via PowerBuilder DLL).

Summary Now that we have reviewed the basics of distributed Oracle database management, you should have a good idea of how a distributed Oracle database can be integrated for use by a WebServer application by using database links and SQL*Net connections. While we can only gloss over the high points of SQL*Net in this chapter, sophisticated tools such as SQL*Net 2.0 require a great deal of knowledge and skill to use effectively. As systems continue to evolve into complex distributed networks, interdatabase communications will continue to become more complex and require more sophisticated tools. Object-orientation promises to make interdatabase communications simple, but the DBA in the trenches will continue to struggle with implementing everyday distributed database communications. In the following chapters, we will take a look at Oracle database design issues to ensure that the Oracle database portion of the WebServer application does not become the bottleneck in the overall system.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

CHAPTER 14 Logical Design For WebServer Applications There are many books containing tips on the effective design of Oracle systems, but many of these texts are purely theoretical and fail to take into account the real-world issues involved in designing a high-performance Oracle database. In this chapter, we’ll take a real-world approach toward designing WebServer applications and discuss the importance of system response time.

Normalization And Modeling Theory For Oracle As we know, there are five basic types of data relationships that must be modeled when designing any Oracle database: • one-to-one • one-to-many • many-to-many • recursive many-to-many • “is a” (ISA) The effective WebServer designer must be able to represent these five types of data relationships in a sensible way, while ensuring acceptable Oracle database performance. This chapter focuses on one-to-many and many-to-many relationships. Redundancy And Database Design An Oracle database with either one-to-many or many-to-many relationships

has redundant foreign keys embedded in the tables to establish logical relationships between entities. The redundant duplication of foreign keys in subordinate tables creates the data relationships, making it possible to join tables together and relate the contents of the data items in the tables. As the size of the database increases, data redundancy can become a major problem. Today, many users create very large databases, many of which contain trillions of bytes. For databases of this size, a single table can contain more than a billion rows, and the introduction of a single new column to a table could represent thousands of dollars in additional disk expense. Data redundancy is detrimental for two reasons. First and foremost, duplicating the redundant material consumes disk storage space. Second, updating redundant data requires extra processing. Redundant duplication of very large and highly volatile data items can cause huge processing bottlenecks. However, this does not imply that redundancy is always undesirable. Performance is still an overriding factor in most systems. Proper control of redundant information implies that redundant information may be introduced into any structure, as long as the performance improvements outweigh the additional disk costs and update problems. Since the first publication of Dr. E. F. Codd’s 1993 research paper, Providing OLAP (Online Analytical Processing) to User-Analysts: An IT Mandate, database designers have attempted to find an optimum way of structuring tables for low data redundancy. Codd’s rules of normalization often guide designers to create logically correct table structures with no redundancy, but many designers have found that performance demands often dictate the introduction of duplicate table data. This is especially true for distributed Oracle databases. Any node in a distributed database may want to browse a list of customers from another node without establishing a connection to it. In addition, the technological complexity inherent in Oracle’s two-phase commit often necessitates the widespread replication of entire tables or selected columns from tables. However, the distributed database designer does not have free reign to introduce redundancy anywhere in the enterprise. Redundancy always has a price tag, whether it is the cost of the disk storage or the cost of maintaining a parallel update scheme. Figure 14.1 shows a strategy for analyzing the consequences of data redundancy.

Figure 14.1 A comparison of size versus volatility for redundant data. In Figure 14.1, a boundary line lies within a range between the size of a redundant data item and the frequency in which the data item updates. The size of the data item relates to the disk costs associated with storing the item, and the frequency of update is associated with the cost of keeping the redundant data current, whether by replication techniques or by two-phase commit

updates. Because the relative costs are different for each hardware configuration and for each application, this boundary may be quite different depending on the type of application. The rapid decrease in disk storage costs means that the size boundary is only important for very large-scale redundancy. A large, frequently changing item (for example, street_address) is not a good candidate for redundancy. But large static items (for example, service_history) or small, frequently changing items (such as product_price) may be acceptable for redundancy. Small static items (for example, gender) represent ideal candidates for redundant duplication.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

One-To-Many Data Relationships One-to-many relationships exist in many real-world situations. Many entities that possess one-to-many relationships can be removed from the data model, eliminating some join operations. The basic principle here is simple: Redundant information avoids expensive SQL joins and yields faster processing. But remember, we must deal with the issue of additional disk storage and the problems associated with updating the redundant data. For example, consider the Entity/Relation (E/R) model shown in Figure 14.2.

Figure 14.2 A fully normalized E/R model sales database. In Figure 14.2, we see that the structure is in pure Third Normal Form. Notice that the CITY and STATE tables exist because each state has many cities and each city has many customers. This model works for most transactions in an online transaction processing (OLTP) system. However, this high degree of normalization would require the joining of the CITY and STATE tables each time address information is requested, forcing some SQL requests to perform very slowly. Consider a query to display the state_bird for all orders that have been placed for birdseed. This is a cumbersome query that requires the joining of six tables, as shown in Listing 14.1. Listing 14.1 Joining six tables. select state_bird

from STATE, CITY, CUSTOMER, ORDER, QUANTITY, ITEM where item_name = 'BIRDSEED' and ITEM.item.nbr = QUANTITY.item.nbr AND QUANTITY.order_nbr = ORDER.order_nbr AND ORDER.cust_nbr = CUSTOMER.cust_nbr AND CUSTOMER.cust_city = CITY.cust_city AND CITY.state_name = STATE.state_name; With Oracle and the rule-based optimizer, this type of complex join guarantees that at least one table is read front to back using a full-table scan, and a full-table scan may slow down even the best WebServer application. This is a shortcoming of Oracle’s rule-based optimizer, because an SQL optimizer should generally avoid a full-table scan whenever indexes are present (except, of course, when the table is very small). This situation might be avoided by using Oracle hints with the cost-based optimizer to determine the optimal path to this data. A hint is an extension of Oracle’s SQL that directs the SQL optimizer to change its normal access path. But what happens if you are designing a data warehouse and your goal is to simplify the data structure by removing several of the one-to-many relationships? For example, you may choose to eliminate the “one” side of a relationship by copying the data columns into the “many” side of the relationship. This is a very common approach in the design of denormalized STAR schemas for use by Oracle 7.3 data warehouses. (We’ll talk more about STAR schemas later in this chapter.) However, adding redundancy poses two issues. First, you need additional disk space for the redundant item, and second, you need to provide a technique to update the redundant item if it needs to be changed. In our example, one solution is to build a table of columns that rolls the CITY and STATE tables into the CUSTOMER table. Table 14.1 assumes that the STATE table contains 50 rows, the CITY table has 2,000 rows, and the CUSTOMER table has 10,000 rows. Table 14.1 Redundancy matrix to determine optimal normalization. Column Size Duplication Total Space Change state_bird

10

10,000

100,000

Rare

state_flower

10

10,000

100,000

Rare

region_name

2

10,000

20,000

Never

cost_of_living city_mascot

8 10

10,000 10,000

80,000 100,000

Quarterly Rare

From Table 14.1, you can see that the CITY and STATE tables can be removed entirely for a total savings of 400,000 bytes (refer to Figure 14.3).

What about the cost_of_living field? If we choose to eliminate the CITY table, and duplicate cost_of_living in every CUSTOMER table row, it would be necessary to visit each and every CUSTOMER row—which means changing the cost of living 10,000 times. Before this change, the following SQL was used to update each CITY table: update CITY set cost_of_living = :var1 where CITY = :var2; 2000 rows updated

Figure 14.3 A denormalized E/R model sales database. While the management of redundancy seems a formidable challenge, the following SQL update statement makes this change easily, and we can make the change to all affected rows: update CUSTOMER set cost_of_living = :var1 where CITY = :var2; 100,000 rows updated Using the same state_bird query as before, we see how it is simplified by removing the extra tables, as follows: select state_bird from CUSTOMER, ORDER, QUANTITY, ITEM where item_name = 'BIRDSEED' and ITEM.item_nbr = QUANTITY.item_nbr and QUANTITY.order_nbr = ORDER.order_nbr and ORDER.cust_nbr = CUSTOMER.cust_nbr; It is still necessary to join three tables, but this results in a much faster, simpler query than the original six-way table join. You can carry this concept to the point where this model is condensed into a single, highly redundant table. When creating an E/R model, it is often tempting to look at the data model from a purely logical perspective without any regard for the physical implications of the model. The designer strives to recognize and establish all of the logical relationships in the model while sometimes finding that the relationships are misleading. A relationship can be misleading when the relationship actually exists, but the application may have no need to reference this relationship. Consider the E/R model for a university shown in Figure 14.4.

Figure 14.4 An example of misleading data relationships. Consider the association of the hair_color attribute to the student entity. Does a many-to-many data relationship really exist between hair_color and student? Many students have blonde hair, and blonde hair is common to many students. Why not create a many-to-many relationship between student and hair_color? The solution depends upon whether any other non-key data items exist within the hair_color entity.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

If many other data items relating to hair color are present, then it is perfectly appropriate to create another entity called hair_color. But in this case, even though a many-to-many relationship exists between hair_color and student, hair_color is a standalone data attribute, so it is unnecessary to create an additional data structure. Another example is the zip_code attribute in the student entity. At first glance, it appears that a violation of Third Normal Form (that is, a transitive dependency) has occurred between city and zip_code. In other words, it appears that a zip_code is paired with the city of residence for the student. If each city has many zip_codes, while each zip_code refers only to one city, it makes sense to model this as a one-to-many data relationship (see Figure 14.5). The presence of this data relationship requires creating a separate entity called zip with attached student entities. However, this is another case where the zip entity lacks key attributes, making it impractical to create. In other words, zip_code has no associated data items. Creating a database table with only one data column would be nonsense.

Figure 14.5 An example of correct many-to-many relationships. The example in Figure 14.5 demonstrates that it is not enough to group together like items and then identify the data relationships. A practical test must be made regarding the presence of no-key attributes within an entity class. If an entity has no attributes (that is, the table has only one field), the presence of the entity is nothing more than an index to the foreign key in the member entity. It can be removed from the E/R model. This technique not only simplifies the number of entities, but it creates a better environment for a client/server architecture. More data is logically grouped together, resulting in

less data access effort. Many-To-Many Data Relationships Oftentimes, a many-to-many relationship can be condensed into a more efficient structure to improve the speed of data retrieval. After all, with denormalization, less tables will need to be joined together to get the desired information. For example, Figure 14.6 shows how a many-to-many relationship can be collapsed into a more compact structure by considering the relationship between a course and a student.

Figure 14.6 An example of a university database. A student takes many courses, and each course has many students. This is a classic many-to-many relationship that would require that we define a junction table between the base entities to establish the foreign keys necessary to join the tables together. Note that the junction table is called GRADE with the following contents: • course_nbr—the primary key for the COURSE table • student_nbr—the primary key for the STUDENT table • grade—a no-key attribute to both foreign keys Next, consider the question, In what context does a grade have meaning? Stating that “The grade was A in CS-101” is insufficient, and stating that “Joe earned an A” makes no sense. Only when both the student name and the course number are associated does the grade column have meaning. Stating that “Joe earned an A in CS-101” makes sense. Recursive Data Relationships Recursive many-to-many relationships contain an object that also has a many-to-many relationship with other occurrences of the same object. These relationships are often termed Bill-of-Materials (BOM) relationships, and the graphical representation of the recursive relationship is sometimes termed a Bill-of-Materials explosion. BOM relationships are termed recursive because a single query makes many subpasses through the tables to arrive at the solution (see Figure 14.7).

Figure 14.7 An example of recursive many-to-many relationships. Bill-of-Materials relationships denote an object with a many-to-many relationship with another object in the same class. For example, a part may consist of other parts, but, at the same time, it is a component in a larger assembly. Or, a class at a university may have many prerequisites, but, at the same time, it is a prerequisite for other classes.

Bill-of-Materials relationships become even more complex when we begin to create class hierarchies on top of the relationship. In Figure 14.8, you can see that the recursive relationship between parts and components has been extended to allow for different classes of parts, each with its own data elements and behaviors. Unfortunately, these types of challenges are very common. While it is true that “parts are parts,” different parts often have subtle variations—which, of course, leads to separate data columns. For example, a food-related part might have a shelf_life column, but that column does not apply to a non-food part.

Figure 14.8 Recursive many-to-many relationships with the addition of an ISA hierarchy. With an understanding of the nature of recursive relationships, the question becomes one of implementation: What is the best way to represent a recursive relationship in Oracle and navigate the structure? Listing 14.2 shows Oracle table definitions that describe the tables for our part-component example. Listing 14.2 Oracle table definitions. create table part_nbr part_name part_desc qty_on_hand

PART( number, varchar2(10), varchar2(10), number);

create table has_part is_a_part qty

COMPONENT ( number, number, number);

Look closely at the COMPONENT example. Both the has_part and is_a_part fields are foreign keys for the part_nbr field in the PART table. Therefore, the COMPONENT table contains all key values except for the qty field, which tells how many parts belong in an assembly. To understand how this works, look at the following SQL code used to display all components in a Big_Meal: select part_name from PART, COMPONENT where has_part = 'BIG MEAL' and PART.part_nbr = COMPONENT.has_part; This type of Oracle SQL query requires joining the table against itself. Unfortunately, because all items are of the same type (namely, PART), no real substitute exists for this type of data relationship, therefore the BOM

relationship will most likely remain popular in Oracle.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

Using STAR Schema Design With WebServer One of the most popular uses for Oracle WebServer has been servicing the front-end requirements for decision support systems and data warehouses. Oracle has announced that their Oracle Express multi-dimensional component has now been Web enabled, but there is still a need to use Web pages for the display (and data capture) of decision support information. One common use of WebServer is to allow end users to display highly summarized Oracle data on Web pages, where they can use MS-Windows cut-and-paste commands to extract data into spreadsheets for further analysis. Because the data can be gathered from a Web page, developers do not need to write cumbersome data downloading routines, and end users can get data from anywhere in the world. The STAR schema design was first introduced by Dr. Ralph Kimball as an alternative database design for data warehouses. The name STAR comes from the design that the completed schema creates, where a large fact table resides at the center of the model surrounded by various reference tables, or points. The basic principle behind the STAR query schema is the introduction of highly redundant data for high performance. Returning to the customer-order E/R model in Figure 14.3, we see an illustration of a standard Third Normal Form database used to represent the sales of items. Because redundant information is not an issue, salient data (such as the total for an order) is computed from the items comprising the order. In this Third Normal Form database, users need a list of line items to multiply the quantity ordered by the price for all items belonging in order 123. An intermediate table called TEMP holds the result list, as shown in the following example: create table TEMP as select (QUANTITY.quantity_sold * ITEM.list_price) line_total from QUANTITY, ITEM where QUANTITY.order_nbr = 123 and QUANTITY.item_nbr = ITEM.item_nbr; select sum(line_total) from TEMP;

Note: The STATE-CITY-CUSTOMER hierarchy in Figure 14.2 is very deliberate. To be truly in the Third Normal Form, no redundant information is allowed. As such, a user’s seemingly simple query is complex to the system. For example, the SQL calculating the sum of all orders for the Western region looks very complex and involves the five-way table join, as follows: create table TEMP as select (QUANTITY.quantity_sold * ITEM.list_price) From QUANTITY, ITEM, CUSTOMER, CITY, STATE where QUANTITY.item_nbr = ITEM.item_nbr /* join and ITEM.cust_nbr = CUSTOMER.cust_nbr /* join and CUSTOMER.city_name = CITY.city_name /* join and CITY.state_name = STATE.state_name /* join and STATE.region_name = 'WEST';

line_total QUANTITY and ITEM */ ITEM and CUSTOMER */ CUSTOMER and CITY */ CITY and STATE */

In reality, sufficient redundancy eliminates the CITY and STATE tables. The point is clear: A manager analyzing a series of complete order totals requires a huge amount of realtime computation. This process arrives at the basic tradeoff. For true freedom from redundant data, query time demands a price. In practice, the Third Normal Form database generally evolves into a STAR schema as you create a fact table to hold the quantity for each item sold (see Figure 14.9).

Figure 14.9 The STAR query E/R model. At first glance, it’s hard to believe this is the same data as the normalized database. The new fact table contains one row for each item on each order, resulting in a tremendous amount of redundant key information in the table. It should be obvious that the STAR query schema requires far more disk space than a Third Normal Form database. Also, the STAR schema is most likely a read-only database because of the wide-spread redundancy introduced into the model. Finally, the widespread redundancy makes updating difficult (if not impossible) for the STAR schema. Notice the dimension tables around the fact table. Some of the dimension tables contain data that is added to queries with joins. Other dimensions, such as the Region dimension, contain no data. What purpose, then, does this STAR schema achieve with huge disk space consumption and a read-only restriction? Using the STAR schema in Figure 14.9, let’s formulate SQL queries for rapid retrieval of desired information. For example, identifying the total cost for an order is simple, as seen in the following code: select sum(total_cost) order_total from FACT where FACT.order_nbr = 123; It is clear that the new structure makes the realtime query faster and simpler. Consider the result if the goal is to analyze information by aggregate values using this schema. Suppose that the manager needs the breakdown of regional sales. The data by region is not available, but the

FACT table supplies the answer. Obtaining the sum of all orders for the Western region is now simple, as seen in the following code: select sum(total_cost) from FACT where region = 'WEST' The merits of the STAR schema should now be apparent, but we need to note some other ways to represent time-oriented data suitable for OLAP type systems, namely, the multidimensional database architecture, as seen in Oracle Express.

Summary It should now be clear to the reader how a proper design can be critical for good database performance. While far from being an exhaustive description of all of the relational design techniques, this chapter has focused on basic principles that will help to ensure that your WebServer database performs as quickly as possible. Once a good logical model has been created, it is critical to translate the logical model into an Oracle implementation capable of performing at optimal speed. Oracle involves many design issues, and in this chapter we’ve taken a look at how some physical design models can be used to exploit client/server performance. We have come to believe that response time is one of the most critical factors to the success of any database. Regardless of how well the system was analyzed or implemented—no matter how flashy the GUI interface—if the system fails to deliver data in a timely fashion, the project is doomed. Now that we have reviewed logical database design, let’s move on to the physical implementation of WebServer databases.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

CHAPTER 15 Physical Oracle Design When creating a WebServer application, you must pay careful attention to the components that might affect system response time. These considerations include WebServer’s interaction with the Internet, Web Listener, Web Request Broker, and Oracle databases. Unfortunately, you have virtually no control over the Internet’s speed and very little control over the Web Listener and Web Request Broker. Oracle’s Web Listener and Web Request Broker have both been preoptimized by Oracle and cannot be tuned by adjusting any of their parameters. However, you can control how these components interact with your Oracle databases. More than other online applications, special consideration must be given to Oracle databases. Database transactions must be serviced efficiently to ensure that Web pages are sent to end users quickly. This chapter takes a look at the physical Oracle database design issues that can influence the performance of your WebServer applications. The topics in this chapter include the use of table replication with snapshots, referential integrity, index placement, and Oracle’s parallel facilities. The overall focus is on the use of physical database techniques for creating high-performance Oracle WebServer applications. Without an effective physical design, no amount of tuning will significantly improve performance. Hence, it is critical to any WebServer effort that you derive the optimal performance from all of your Oracle database servers.

Replication With Oracle Snapshots Oracle snapshots are used to create read-only copies of tables in other Oracle databases. Table replication is a highly effective way to avoid time-consuming and expensive cross-database joins of tables. As we know, an SQL join with a

table at a remote server will be far slower than a join with a local table. The network overhead also increases as Oracle retrieves and transfers data across the network. The prudent use of replicated tables can greatly improve the response time for WebServer applications. It’s interesting to note that the general attitude about data replication has shifted dramatically in the past 10 years. In the 1980s, table replication was too expensive, both in terms of disk costs and the processing costs to update redundant tables. Also, academia believed that there was no substitute for the Third Normal Form database, and students were taught Codd’s Rules of Normalization as if the rules were physical laws of nature. Today, the practical realities of cheap disks and distributed processing have made replication an inexpensive and viable alternative to expensive cross-database joins. Table replication has proven to be stable and has been so successful within Oracle version 7 that Oracle version 7.3 is now introducing the concept of updatable snapshots. Snapshot is the term used by Oracle to implement their table replication strategy. However, table replication is not to be used indiscriminately, and the following several guidelines exist for using replicated tables in a WebServer application: • The replicated table should be read-only—Obviously, a table snapshot cannot be updated because the master copy of the table is on another server. • The replicated table should be relatively small—Ideally, a replicated table is small enough that the table can be dropped and re-created each night, or the refresh complete option can be used. Of course, large tables can be replicated with the refresh fast option, but this involves a complicated mechanism for holding table changes and propagating them to the replicated table. • The replicated table should be frequently accessed—It does not make sense to replicate a table if it is only referenced a few times per day, because the cost of the replication would outweigh the cost of the cross-database join. Despite any claims by Oracle to the contrary, only tables that meet the listed criteria should be placed in snapshots. In practice, snapshots are not maintenance-free, and many points of failure are possible—especially if the snapshot is created with the refresh fast option. Problems can occur writing to the SNAPSHOT_LOG table, and SQL*Net errors can cause failures of updates to transfer to the replicated tables.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

How To Create Oracle Snapshots A snapshot is created on the destination system with the create snapshot SQL command, and the remote table is immediately defined and populated from the master table. After a snapshot has been created, it may be refreshed periodically. There are two types of refreshing in Oracle: complete and fast. A complete refresh can be done in several ways, but most savvy Oracle developers drop and re-create the snapshots with a Unix cron job to achieve full refreshes, especially if the table is small and easily re-created. Optionally, tables can be refreshed with only the changes made to the master table. This requires additional work on the slave database to create an Oracle refresh process (in the init.ora) and the definition of a snapshot log on the master database (see Figure 15.1).

Figure 15.1 A high-level overview of Oracle snapshots. Several steps need to be completed by the Oracle database administrator before your Oracle system is ready to use snapshots. First, the DBA needs to run catsnap.sql, which can be found in your $ORACLE_HOME/rdbms/admin directory. This script will populate the Oracle dictionary with the necessary system tables to manage the snapshots. The DBA also needs to run dbmssnap.sql, which can be found in the $ORACLE_HOME/rdbms/admin directory. This script creates the stored procedures that can be used to manipulate the snapshots. The following parameters must also be added to the init.ora file for each Oracle instance:

• snapshot_refresh_interval=60—This sets the interval (in minutes) for the refresh process to wake up. • snapshot_refresh_processes=1—This is the number of refresh processes on the instance (the minimum is 1). • snapshot_refresh_keep_connections=FALSE—This specifies whether the database should keep remote connections after refreshing the tables. Always use FALSE. For snapshots that are small enough to be totally repopulated, it is recommended that the following steps are followed to re-create the snapshot from scratch. Note that it is possible to do a refresh complete or a refresh force rather than a cron job, but using a cron is a simple way to guarantee that the replicated table will be fully repopulated. To avoid the refresh fast option with a Unix cron, the following two steps are required: 1. Create the snapshot with the refresh complete option. 2. Alter oracle.cron to drop and re-create the snapshot. For snapshots on large tables, you may want to use the refresh fast option. To use refresh fast, the following steps are required: 1. Destination system—Create the snapshot with the refresh fast option signed on as user SYS. (Be sure to define a database link with connect to xxx identified by zzz and ensure that user xxx has select privileges against the master table.) 2. Master system—Create a snapshot log on each master table. 3. Bounce the destination system to begin the refreshes based on the interval specified in the create snapshot. Listing 15.1 shows an example of a snapshot that reads a table from an instance called fairport. Listing 15.1 Example of a snapshot with periodic refreshing. CONNECT sys/xxxx; DROP PUBLIC DATABASE LINK fairport; CREATE PUBLIC DATABASE LINK fairport CONNECT TO db_link IDENTIFIED BY db_pass USING 'fairport'; ———————————————————————————— DROP SNAPSHOT my_replicated_table; ———————————————————————————— CREATE SNAPSHOT my_replicated_table PCTFREE 10 PCTUSED 40 TABLESPACE ts2 STORAGE (initial 60k next 10k pctincrease 1) REFRESH FAST START WITH SYSDATE NEXT (sysdate+1) + 3/24 AS SELECT * FROM ORACLE.my_master_table@fairport; GRANT ALL ON my_replicated_table TO PUBLIC; —****************************************************** — Add the appropriate synonyms for the snapshots...

—****************************************************** CONNECT /; CREATE PUBLIC SYNONYM snap$_my_replicated_table FOR ops$oracle.snap$_my_replicated_table; In Listing 15.1, you can see that the my_replicated_table table is refreshed each morning at 3:00 AM, and the read-only name snap$_my_replicated_table has been replaced with synonym my_replicated_table. Following is an example of the snapshot log syntax that needs to be run on the master database: CREATE SNAPSHOT LOG ON employee_table TABLESPACE ts2 STORAGE (initial 20k next 20k); The dbms_snapshot.refresh_all procedure can be run at any time on the destination system to refresh the snapshot tables. To force a refresh of an individual table, execute the following procedure: EXECUTE

dbms_snapshot.refresh('office','f');

Note: Any refresh errors are written to the alert.log file.

The snapshot log is a table that resides in the same database as the master table, which can be seen in the dba_tables view as a table with the name MLOG$_TABLENAME. In our example, the snapshot log would be called MLOG$_EMPLOYEE. Even with Oracle’s distributed features, it is still far faster to process a table on a local server than it is to process a remote table across SQL*Net’s distributed communication lines. As such, table replication is a very desirable technique for improving processing speeds. Several factors influence the decision about replicating tables. The foremost considerations are the size of the replicated table and the volatility of the tables. Large, highly active tables with many updates, deletes, and inserts will require a lot of system resources to replicate and keep synchronized with the master table. Smaller, less active tables would be ideal candidates for replication, because the creation and maintenance of the replicated table would not consume a high amount of system resources.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Oracle’s snapshot facility is relatively mature and generally works as noted in the Oracle documentation. However, the flexibility of the snapshot tool gives the developer many choices concerning how the snapshot will be created and refreshed. You can refresh a replicated table in full, re-create a snapshot at will, choose to periodically refresh a snapshot, and use database triggers to propagate changes from a master table to a snapshot table. Although the choice of techniques depends on the individual application, some general rules apply. If a replicated table is small and relatively static, it is usually easier to drop and re-create the snapshot than to use Oracle’s refresh complete option. A crontab file can be set up to invoke the dropping and re-creation of a snapshot at a predetermined time each day—completely refreshing the entire table. Another popular alternative to a snapshot is the use of Oracle’s distributed SQL to create a replicated table directly on the slave database. In the following example, the New York database creates a local table called EMP_NY, which contains New York employee information from the master employee table at corporate headquarters: create table emp_ny as select emp_nbr, emp_name, emp_phone, emp_hire_date from emp@hq where department = 'NY'; Very large replicated tables consume too much time in dropping and re-creating a snapshot or using the refresh complete option. For static tables, a snapshot log would not contain very many changes—we could direct Oracle to propagate the changes to the replicated table at frequent intervals. Let’s take a look at the different refresh intervals that can be specified for a snapshot. The following code tells Oracle to apply the snapshot log to the replicated table every seven days: create snapshot emp_snap1 refresh fast start with sysdate next sysdate+7 as select emp_nbr, emp_name from employee@hq where department = 'NY'; The next example code shows the command for a table to be refreshed each Tuesday at 6:00 AM:

create snapshot EMP_SNAP1 refresh fast start with sysdate next next_day(trunc(sysdate),'tuesday')+6/24 as select emp_nbr, emp_name from employee@hq where department = 'NY'; For very static tables, you can specify refreshes to run quarterly. The following example refreshes a table completely on the first Tuesday of each quarter: create snapshot emp_snap1 refresh complete start with sysdate next next_day(add_months(trunc(sysdate,'q'),3),'tuesday') as select emp_nbr, emp_name from employee@hq where department = 'NY'; For dynamic tables that require refreshing daily, you can specify that the table is refreshed at a particular time each day. The following code refreshes a table every day, at 11:00 AM: create snapshot emp_snap1 refresh fast start with sysdate next sysdate+11/24 as select emp_nbr, emp_name from employee@hq where department = 'NY'; In addition to using the time range specified in the create snapshot syntax, you can also use Oracle stored procedures to get the same results. If you run the dbmssnap.sql script, you can refresh a snapshot by issuing the following command: execute dbms_snapshot.refresh('employee','c'); execute dbms_snapshot.refresh('employee','f'); execute dbms_snapshot.refresh('employee','?');

/* complete refresh */ /* forced refresh */ /* fast refresh */

Using Triggers To Update Snapshots What about replicated tables that require instantaneous propagation? Oracle version 7.3 offers updatable snapshots. Fortunately, users of previous releases of Oracle can also update snapshots by using database triggers to simulate the realtime propagation of changes from a master table to replicated tables. In the following example, an update trigger has been placed on the employee tables, and relevant changes will be propagated to the New York branch: Create trigger add_employee after insert on employee As If :dept = 'NY' then (insert into employee@NY values(:parm1, :parm2,:parm3); ); Your next question might be, What can we do about rows deleted from the employee table? Using the same technique, a delete trigger can be placed on the employee table to remove rows from the replicated tables: create trigger delete_employee after delete on employee as

if :dept = 'NY' then (delete from employee@NY where emp_nbr = :employee_parm ); Using Snapshots To Propagate Subsets Of Master Tables As we have seen, snapshot replication is very handy for taking a master table and copying it to a remote location. But, what if we only want to replicate a portion of a table? Yes, Oracle provides a method for excluding certain rows and columns from the replicated table. For example, let’s assume that you are replicating a central employee table for use by your New York branch. However, you only want to replicate employee records for those who work in the New York branch, and you want to exclude confidential columns, such as the employees’ salaries. The snapshot would appear as follows: create snapshot emp_ny refresh fast start with sysdate next next_day(trunc(sysdate),'tuesday')+6/24 as select emp_nbr, emp_name, emp_phone, emp_hire_date from emp@hq where department = 'NY';

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Using Referential Integrity With Oracle Referential Integrity (RI) rules ensure that one-to-many and many-to-many relationships are enforced within the relational schema. In addition, valid values can also be enforced with constraints. Constraints are especially important to WebServer applications, because WebServer allows constraint checking to take place at the database server, thereby relieving the Web client of the burden of checking constraints. Several types of constraints can be applied to Oracle tables to enforce referential integrity, including: • Check Constraint—This constraint validates incoming columns at row insert time. For example, rather than having an application verify that all occurrences of region are North, South, East, or West, a check constraint can be added to the table definition to ensure the validity of the region column. • Not Null Constraint—This constraint is used to specify that a column may never contain a NULL value. This is enforced at SQL insert and update time. • Primary Key Constraint—This constraint is used to identify the primary key for a table. This operation requires that the primary columns are unique, and Oracle will create a unique index on the target primary key. • References Constraint—This is the foreign-key constraint as implemented by Oracle. A references constraint is only applied at SQL insert and delete times. For example, assume a one-to-many relationship between the EMPLOYEE and DEPENDENT tables—each employee may have many dependents, yet each dependent belongs to only one employee. The references constraint tells Oracle at insert time that the value in DEPENDENT.emp_num

must match the EMPLOYEE.emp_num in the employee row, thereby ensuring that a valid employee exists before the dependent row is added. At SQL delete time, the references constraint can be used to ensure that an employee is not deleted if rows still exist in the DEPENDENT table. • Unique Constraint—This constraint is used to ensure that all column values within a table never contain a duplicate entry. Notice the distinction between unique and primary key. While both of these constraints create a unique index, a table may contain only one primary key constraint column—but it may have many unique constraints on other columns. Referential integrity usually needs to be double coded: once for the database and again within the application. For example, in a multipart SQL*Form, you may not become aware of an RI violation until you are many pages into the form and your form attempts to commit. In WebServer applications, you do not have the luxury of making a lot of queries against the database, and you need to be careful to keep the Oracle transactions as few as possible. Referential integrity maintains business rules. Relational systems allow control of business rules with constraints, and RI rules form the backbone of relational tables. For example, RI ensures that a row in the CUSTOMER table is not deleted if the ORDER table contains dependents for that employee (see Figure 15.2).

Figure 15.2 An example of referential integrity. It is clear that enforcing this business rule in our new distributed environment is a real challenge. While it is relatively simple to tell an Oracle system not to delete a row from its CUSTOMER table if rows for that employee exist in the ORDER table, it is not simple to enforce this rule when the CUSTOMER table resides in a Sybase database and the ORDER table resides within Oracle. The solution is to remove the database RI rules from each database, remembering to manually replicate the RI rules using procedural code within the application. This essentially creates your own customized RI within the application.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Indexes And Oracle Performance In Oracle, an index is used to speed up the time required to access table information. Internally, Oracle indexes are B-tree data structures, in which each tree node may contain many sets of key values and row IDs. In general, Oracle indexes exist for the purpose of preventing full-table scans. Full-table scans have two problems, the most important being the time lost in servicing a request as each and every row of a table is read into Oracle’s buffer pool. The second problem associated with full-table scans is that they cause performance degradation at the system level. All other tasks on the system may have to incur additional I/O, because the buffer block held by competing tasks will have been flushed by the full-table scan. As blocks are flushed from the buffer pool, other tasks incur additional I/Os to reread information that would have remained in the buffer pool if the full-table scan had not been invoked. In general, just about any Oracle table will benefit from the use of indexes. The only exception to this rule would be a very small table that can be read in less than two physical I/Os. Two physical I/Os are used as the guideline because Oracle needs to perform at least one I/O to access the root node of the index tree and another I/O to retrieve the requested data. For example, assume that a lookup table contains rows of 25 bytes each, and you have configured Oracle to use 4 K block sizes. Because each data block would hold about 150 rows, using an index for up to 300 rows would not make the processing any faster than a full-table scan. If you plan to use the Oracle parallel query facility, all tables specified in the SQL query must be optimized for a full-table scan. If an index exists, the cost-based optimizer must be used with a hint to invalidate the index in order to use parallel query. For the rule-based optimizer, indexes can be turned off by using an Oracle function in the where clause.

One important concept in indexing is the selectivity, or the uniqueness, of the values in a column. To be effective, an index column must have many unique values. Columns that have only a few values (e.g., sex = m/f, status = y/n) would not be good candidates for indexing. Similar to the index itself, the sparse distribution of values would be less efficient than a full-table scan. To see the selectivity for a column, compare the total number of rows in the table with the number of distinct values for the column. For example: select count(*) from EMPLOYEE; select distinct status from EMPLOYEE; Another concept used in indexing is called distribution, which refers to the frequency that each unique value is distributed within the database. For example, we may have a state_abbreviation column that contains 1 of 50 possible values. This would be acceptable to use as an index column, provided that the state abbreviations are uniformly distributed across the rows. However, if 90 percent of the values are for New York, then the index will not be very effective. Oracle has addressed the index data distribution issue with the analyze table command. When using Oracle’s cost-based SQL optimizer, analyze table will look at both the selectivity and distribution of the column values. If they are found to be out-of-bounds, Oracle may decide not to use the index. Oracle recommends the following guidelines when considering whether to use an index on a column: • Columns frequently referenced in SQL where clauses are good candidates for an index. • Columns used to join tables (primary and foreign keys) should be indexed. • Do not use a B-tree index on columns with poor selectivity. Any column with less than 10 percent of unique values should be indexed as a bitmap index. • Frequently modified columns are not good candidates for indexing because excessive processing is necessary to maintain the structure of the index tree. • Do not index columns used in SQL where clauses using Oracle functions or operators. For example, an index for last_name will not be effective if it is referred to in the SQL as upper(last_name). • When using referential integrity, always create an index on the foreign key.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Tuning Queries With Indexes As a general rule, indexes will always increase the performance of a database query. In situations where a query intends to sweep a table in the same sequence that the rows are physically stored, the indexes in some tables may actually hinder performance. For Oracle, indexes are recommended for two reasons: to speed the retrieval of a small set of rows from a table and to presort result sets so that the SQL order by clause does not cause an internal sort. In order to use an index, the SQL optimizer must recognize that the column has a valid value for index use. This is called a sargeable predicate, and it’s used to determine the index access. Listing 15.2 shows some valid predicates, and Listing 15.3 shows invalid predicates. Listing 15.2 Viewing valid predicates. select * from EMPLOYEE where emp_no = 123; select * from EMPLOYEE where dept_no = 10; Listing 15.3 Viewing invalid predicates. select * from EMPLOYEE where emp_no = "123"; select * from EMPLOYEE where salary * 2 < 50000; select * from EMPLOYEE where dept_no != 10; Whenever a transformation to a field value takes place, the Oracle database will not be able to use the index for that column. Some databases, such as DB2, will recognize a linear search and invoke a sequential

prefetch to look ahead, reading the next data block while the previous data block is being fetched by the application. As a general rule, an SQL query that retrieves more than 15 percent of the table rows in a table will run faster if the optimizer chooses a full-table scan rather than an index. For example, assume that a student table has 1,000 rows, representing 900 undergraduate students and 100 graduate students. A nonunique index has been built on the student_level field that indicates underdgrad or grad. The same query will benefit from different access methods, depending upon the value of the literal in the where clause. The following query will retrieve 90 percent of the rows in the table and will run faster with a full-table scan rather than an index: select * from STUDENT where student_level = 'undergrad'; This next query will only access 10 percent of the table rows and will run faster by using the index on the student_level field: select * from STUDENT where student_level = 'grad'; Unfortunately, the Oracle database cannot predict in advance the number of rows that will be returned from a query. Many SQL optimizers will invoke an index access even though it may not always be the fastest access method. To remedy this problem, some dialects of SQL allow the user to control the index access. This is a gross violation of the declarative nature of theoretical SQL, in which the user does not control access paths. But, in practice, these extensions can improve performance. Oracle, for example, allows the concatenation of a null string to the field name in the where clause to suppress index access. The previous query could be rewritten in Oracle SQL to bypass the student_level index, as follows: select * from STUDENT where student_level||'' = 'undergrad'; The concatenation (||) of a null string to the field tells the Oracle SQL optimizer to bypass index processing for this field, instead of invoking a faster-running full-table scan. This a very important point. While SQL optimizers are becoming more intelligent about their databases, they still cannot understand the structure of the data and will not always choose the best access path. Concatenated Indexes A concatenated index is an index created on multiple columns. This type of index can greatly speed up queries where all of the index columns are specified in the queries’ SQL where clauses. For example, assume the following index on the STUDENT table: create index idx1 on STUDENT (student_level, major, last_name) ascending; The following concatenated index could be used to speed up queries that reference both student_level and major in the where clause:

select student_last_name from STUDENT where student_level = 'undergrad' and major = 'computer science'; However, some queries using only major or student_level will not be able to use this concatenated index. In the following example, only the major field is referenced in the query, and a concatenated index cannot be used to service the query: select * from STUDENT where major = 'computer science'; In the following example, we see that student_level is the high-order index key, and the index will be used because student_level is the high-order index key: select last_name from STUDENT where student_level = 'plebe' order by last_name; Because student_level is the first item in the index, the leading portion of the index can be read, and the SQL optimizer will invoke an index scan. Why have we chosen to add the last_name to the index, even though it is not referenced in the where clause? Because Oracle will be able to service the request by reading only the index, and the rows of the STUDENT table will never be accessed. Also, because the order by clause asks to sort by last_name, Oracle will not need to perform a sort on this data. The not (!) operator will cause an index to be bypassed, and the query “show all undergrads who are not computer science majors” will cause a full-table scan: select * from STUDENT where student_level = 'undergrad' and major != 'computer science'; Here, the not condition isn’t a sargeable predicate and will cause a full-table scan.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Oracle Locking While most commercial database products provide mechanisms for locking and concurrency control, new issues emerge when using a relational database such as Oracle (see Figure 15.3). This problem is especially prevalent when a single Oracle task updates multiple remote servers, which is becoming increasingly common with distributed Oracle systems. The real nightmare begins when the remote servers are of differing architectures—for example, a distributed update to a relational and a network database. In these cases, the concurrency control is generally turned off for each database and is provided for inside the application program. After all, neither database can be expected to manage the internals of the other database.

Figure 15.3 An overview of Oracle locking. In addition to the technical issues, the popularity of client/server interfaces has also changed how concurrency is handled. Many client/server systems disable their Oracle database locking and rely upon procedural tricks to maintain data integrity at the server level. Oracle is one of these products, and we’ll discuss how to avoid contention by disabling Oracle locks. Most programmers do not realize that database deadlocks occur frequently within database indexes. It’s important to note that a select of a single row from a database may cause more than one lock entry to be placed in the storage pool. When one row is locked, all affected index rows will also be locked. In other words, the individual row receives a lock, as well as each index node that contains the value for that row. If the “last” entry in a sorted

index is retrieved, the database will lock all index nodes that reference the indexed value (in case the user changes that value). Many indexing schemes always carry the high-order key in multiple index nodes, so an entire branch of the index tree can be locked—all the way up to the root node of the index. While each database’s indexing scheme is different, some relational database vendors recommend that tables with ascending keys be loaded in descending order, so that the rows are loaded from Z to A on an alphabetic key field. Oracle recommends dropping indexes before large updates and re-creating the indexes after the rows have been loaded into the table. When an update or delete is issued against a row that participates in an index, the database will attempt an exclusive lock on the row, which requires the task to check for any shared locks held against the row as well as any index nodes that will be affected. Many indexing algorithms allow for the index tree to dynamically change shape, spawning new levels as items are added and condensing levels as items are deleted. For any table of consequential size, indexes are recommended to improve performance. Of course, an index requires additional disk space—a table with an index on each column will have indexes that consume more space than the table. Oracle will also update the indexes at runtime, as columns are deleted, added, or modified. This index updating can cause considerable performance degradation. For example, adding a row to the end of a table will cause Oracle to adjust the high-key value for each node in the table. One guideline for determining when to use an index involves examination of the SQL issued against a table. In general, the SQL can be collected, and each value supplied in each SQL where clause could be a candidate for inclusion in an index. Another common approach for determining where to create indexes is to run an explain plan for all SQL and carefully look for any full-table scans. The Oracle optimizers operate in such a fashion that Oracle will sometimes perform a full-table scan, even if an index has been defined for the table. This occurs most commonly when issuing complex n-way joins. If you are using rule-based optimization in Oracle, the structure of the SQL statement can be adjusted to force the use of an existing index. For Oracle’s cost-based optimizer, adding hints to the structure will ensure that all indexes are used. Keep in mind that indexes do much more than speed up an individual query. When full-table scans are performed on a large Oracle table, the buffer pool begins to page out blocks from other queries. This causes additional I/O for the entire database and results in poor performance for all queries—not just the offending full-table scan. Indexes are never a good idea for long descriptive columns. A column called employee_description would be a poor choice for an index because of its length and the inconsistency of the data within the column. If this column was 300 bytes, Oracle would be forced to do a huge amount of processing whenever the column is altered. Also, a field such as employee description would usually be referenced in SQL by using Oracle extensions, such as substr, like, and upper. Remember, these Oracle extensions invalidate the

index. Suppose that an index has been created on employee_last_name. The following query would use the index: select status from EMPLOYEE where employee_last_name = 'burleson'; The following queries would bypass the index, causing a full-table scan: select status from EMPLOYEE where employee_last_name = lower('burleson'); select status from EMPLOYEE where employee_last_name like 'burl%'; Unlike other relational databases, Oracle cannot physically load a table in key order. Consequently, we can never guarantee that the rows in the table will be in any particular physical order. The use of an index can help whenever the SQL order by clause is used. For example, even if there are no complex where conditions, the presence of a where clause will assist the performance of the query. Consider the following SQL: select employee_last_name, employee_first_name from EMPLOYEE order by employee_last_name, employee_first_name; Building a multi-valued index on employee_last_name and employee_first_name will alleviate the need for an internal data sort. You can significantly improve the performance of the query by using the following SQL: create index emp_name on EMPLOYEE (employee_last_name, employee_first_name) ascending;

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

Oracle Constraints And Indexes In Oracle, some constraints will create an index on your behalf. For example, creating a primary key constraint on the EMPLOYEE table for the emp_id will create an index on the field, and it is not necessary to manually build an index (see Listing 15.4). Listing 15.4 Creating a primary key constraint. create table EMPLOYEE ( emp_nbr number constraint emp_ukey primary key (emp_nbr) using index pctfree 10 initrans 2 maxtrans 255 tablespace ts1 storage ( initial 256000 next 102400 minextents 1 maxextents 121 pctincrease 1 ), dept_name char(10) constraint dept_fk references DEPT on delete cascade, organization_name char(20) constraint org_fk references ORG on delete restrict, region_name char(2) constraint state_check check (region_name in ('north', south', 'east', 'west')) ); Notice that you should always specify the location clause when declaring constraints. In the previous example, had the emp_ukey constraint been defined without the storage clause, the index

would have been placed in whatever tablespace is specified by the table owner’s default tablespace, with whatever default storage parameters are in effect for that tablespace. Listing 15.4 shows some good examples of Oracle constraints. The first constraint is on the emp_nbr column—the primary key. When you use Oracle’s RI to specify a primary key, Oracle automatically builds a unique index on the column to ensure that no duplicate values are entered. The second constraint is on the dept_name column of the DEPT table. This constraint tells Oracle that it may not remove a department row if there are existing employee rows that reference that department. The on delete cascade tells Oracle that when the department row is deleted, all employee rows that reference that department will also be deleted. The next RI constraint on organization_name ensures that no organization is deleted if employees are participating in that organization. on delete restrict tells Oracle not to delete an organization row if any employee rows still reference the organization. Only after each and every employee has been set to another organization can the row be deleted from the organization table. The last RI constraint is called a check constraint. In a check constraint, Oracle verifies that a column is one of the valid values before inserting a row, but it will not create an index on the column. Using Multicolumn Indexes With Oracle When an SQL request is commonly issued using multiple columns, a concatenated or multicolumn index can be used to improve performance. Oracle supports the use of multivalued indexes, but there are some noteworthy limitations. Unlike other relational databases, Oracle requires that all columns in the index are sorted in the same order, either ascending or descending. For example, if we needed to index on employee_last_name ascending, followed immediately by gross_pay descending, we would not be able to use a multivalued index. Sometimes, two columns that have poor selectivity (i.e., columns having few unique values) can be combined into an index that has better selectivity. For example, we could combine a status field that has three values (good, neutral, and bad) with another column such as state_name (only 50 unique values), thereby creating a multivalued index that has far better selectivity than each column would have if indexed separately. Also, in Oracle version 7.3, bitmapped indexes can be defined for columns with poor selectivity, thereby improving SQL through put. Another reason for creating concatenated indexes is to speed the execution of queries that reference all of the values in an index. For example, consider the following query: select

employee_last_name, employee_status, employee_zip_code from EMPLOYEE order by employee_last_name; Now, you can create an index as follows: create index last_status_zip on EMPLOYEE (employee_last_name, employee_status, employee_zip_code) ascending; If this query were to be issued against the employee table, Oracle would never need to access any rows in the base table! All of the key values are contained in the index, and the high-order key (employee_last_name) is in the order by clause. Oracle can scan the index, retrieving the data without ever touching the base table. With the assistance of this feature, the savvy Oracle developer can add columns to the end of the

concatenated index so that the base table is never touched. For example, if the previous query also returned the value of the employee_address column, this column could be added to the concatenated index, dramatically improving performance. In summary, the following guidelines apply when creating a concatenated index: • Use a composite index whenever two or more values are used in the SQL where the clause and the operators are joined by and. • Place the columns in the where clause in the same order as in the index, with data items added at the end of the index.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

How Oracle Chooses Indexes It is interesting to note that the fastest execution for an individual task may not always be the best choice. For example, consider the following query against an employee table: select employee_name from EMPLOYEE where credit_rating = 'poor' and amount_due > 1000 and state = 'iowa' and job_description like lower('%computer%'); Here, you can see a query where a full-table scan would be the most efficient processing method. Because of the complex conditions and the use of Oracle extensions in the SQL, it might be faster to perform a full-table scan. However, the fast execution of this task may be done at the expense of other tasks on the system as the buffer pool becomes flushed. In general, the type of optimizer will determine how indexes are used. As we know, the Oracle optimizer can run as either rule-based or cost-based. As a general rule, Oracle is intelligent enough to use an index if it exists, but there are exceptions to this rule. The most notable exception is the n-way join with a complex where clause. The rule-based optimizer will get confused and invoke a full-table scan on at least one of the tables, even if the appropriate foreign key indexes exist for all of the tables. The only remedy to this problem is to use the cost-based optimizer, which involves analyzing statistics for each table.

You should also remember that Oracle will only use an index when the index column is specified in its “pure” form. The use of the substr, upper, lower, and other functions will invalidate an index. However, there are a few tricks to help you get around this obstacle. Consider the following two equivalent SQL queries: select * from EMPLOYEE where total_purchases/10 > 5000; select * from EMPLOYEE where total_purchases > 5000*10; The second query, by virtue of the fact that it does not alter the index column, would be able to use an index on the total_purchases column.

Parallelism And Client/Server The widespread acceptance of distributed processing and multitasking operating systems has heralded a new mode of designing and implementing business systems. Instead of the traditional linear design of systems, tomorrow’s system will incorporate massively parallel processing. The result? Many tasks may be concurrently assigned to service a database request. Indeed, the entire definition of data processing is changing. The corporate data resource has been expanded to include all sources of information, not just databases. Corporate information lies within email, scheduling programs, and many other nontraditional sources. Many companies are collecting this information without fully exploiting its value, and multiprocessing is an ideal technique for searching these huge amounts of free-form corporate information. Multitasking And Multithreading WebServer Processes Before tackling this subject, a distinction needs to be made between multitasking and multiprocessing. Multitasking refers to the ability of a software package to manage multiple concurrent processes, thereby allowing simultaneous processing. Although OS/2 and Windows NT are good examples of this technology, multitasking can be found within all midrange and mainframe databases. Multiprocessing refers to the use of multiple CPUs within a distributed environment where a master program directs parallel operations against numerous machines. Two levels of multiprocessing are possible. The first is the hardware level, where arrays of CPUs are offered. The second is the software level, where a single CPU can be partitioned into separate logical processors. The Prism software on the IBM mainframe environment is an example of multiprocessing technology. In any case, programming for multiprocessors is quite different from linear programming techniques. Multiprocessing programming falls into two areas: data parallel programming and control parallel programming. Data parallel programming partitions the data into discrete pieces, running the same

program in parallel against each piece. Control parallel programming identifies independent functions that are simultaneously solved by independent CPUs (see Figure 15.4).

Figure 15.4 An example of a parallel query. One of the greatest problems with implementing parallel processing systems is the identification of parallelism. Parallelism refers to the ability of a computer system to perform processing on many data sources in the same instant. Traditionally, database applications were linear in nature. Today’s systems have many opportunities for parallel processing. Parallelism is especially important for processes such as scientific applications that benefit from having hundreds—or even thousands—of processors working together to solve a problem. The same concept of parallelism applies to very large databases. If a query can be split into subqueries where each subquery is assigned to a processor, the response time for the query can reduce by a factor of thousands (see Figure 15.5).

Figure 15.5 The performance benefits of adding processors.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

A review of the past 30 years makes it clear that tremendous improvements have been made in the speed of processors. At the same time, the prices of processors have continued to decline. However, this trend cannot continue forever. The physical nature of silicon processors has been pushed to its limit and is now reaching a diminishing point of return. In order to continue to enjoy increases in performance, either silicon needs to be replaced as a medium or new ways need to be devised to exploit parallelism in processing. Parallelism is an issue of scale. Where a linear process may solve a problem in 1 hour, a parallel system with 60 processors should be able to solve the problem in 1 minute, as demonstrated in Figure 15.5. In some instances, this statement would be analogous to the statement that one woman takes nine months to have a baby, so nine women should be able to produce a baby in one month. Speed can only be improved in situations where parallel processing is appropriate, which excludes traditional linear systems where one process may not begin until the preceding one ends. Other facets to parallel processing can be extremely valuable. A query against a very large database can be dramatically improved if the data is partitioned. For example, if a query against a text database takes one minute to scan a terabyte, then partitioning the data and processing into 60 pieces would result in a retrieval time of one second. Another key issue is the balancing of the CPU processing with the I/O processing. In a traditional data processing environment, the systems are not computationally intensive, and most of the elapsed time is spent waiting on I/O. However, this does not automatically exclude business systems from taking advantage of multiprocessing. A continuum of processing architecture exists for parallel processing. On one end of the spectrum you find a few powerful CPUs loosely connected; on the other end is a large number of small, tightly coupled processors. Parallelism can be easily identified in a distributed database environment. For the database administrator, routine maintenance tasks such as export/import

operations can be run in parallel, reducing the overall time required for system maintenance. In an open systems environment, parallelism may be simulated easily by using a remote mount facility. With a remote mount, a data file may be addressed directly from another processor, even though the data file physically resides on another machine. SMP Vs. MPP Processing SMP, or symmetrical multiprocessing, describes an architecture where many CPUs share a common memory area and I/O buffer. This type of architecture is not scaleable, as additional processors must compete for the shared memory and I/O resources. On the other hand, massively parallel processors (MPP) describes an architecture where many independent processors share nothing, operating via a common I/O bus. An MPP system can add processors without impeding performance, and performance will actually increase as processors are added.

Using Oracle’s Parallel Query With Oracle version 7.2, some powerful new features have been introduced to allow parallel processes to be used against the Oracle database. These features include: • Parallel create table as select • Parallel query • Parallel index building Please note that the new features of Oracle versions 7.2 and 7.3 will not be activated unless the following init.ora parameter has been used: COMPATIBILITY=7.3.0.0.0 Also, note that it is not necessary to have parallel processors (SMP or MPP) in order to use and benefit from parallel processing. Even on the same processor, multiple processes can be used to speed up queries. Oracle parallel query options can be used with any SQL select statements—the only restriction being that the query performs a full-table scan on the target table. Parallel queries are most useful in distributed databases where a single logical table has been partitioned into smaller tables at each remote node (see Figure 15.6). For example, an employee table ordered by employee name may be partitioned into an employee table at each remote database, such that you have a phoenix_employee, a los_angeles_employee, and so on. This approach is very common with distributed databases, where local autonomy of processing is important. However, what about the needs of those in corporate headquarters? How can they query all of these remote tables as a single unit and treat the logical employee table as a single entity?

Figure 15.6 An example of Oracle’s parallel query. While this splitting of a table according to a key value violates normalization theory, it can dramatically improve performance for individual queries. For large queries that span many logical tables, the isolated tables can be easily reassembled using Oracle’s parallel query facility, as follows: create view all_employee as select * from phoenix_employee@phoenix UNION ALL select * from los_angeles_employee@los_angeles UNION ALL select * from rochester_employee@rochester; Note: The @ references refer to SQL*Net service names for the remote hosts.

We can now query the all_employee view as if it were a single database table, and Oracle parallel query will automatically recognize the union all parameter, firing off simultaneous queries against each of the three base tables. It’s important to note that the distributed database manager will direct each query to be processed at the remote location, while the query manager waits until each remote node has returned its result set. The following query will assemble the requested data from the three tables in parallel, with each query optimized separately: select employee_name from ALL_EMPLOYEE where total_purchases > 5000; The result set from each subquery is then merged by the query manager.

Summary Now that you understand the logical and physical database design issues that influence WebServer’s performance, let’s take a look at the performance and tuning issues that arise when creating a WebServer database. Let’s also look at how the tuning of SQL can help WebServer’s performance. We’ll do just that, in upcoming chapters.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

CHAPTER 16 Database Performance And Tuning There are several factors that influence the performance of a WebServer application. While most of the factors are within the control of Oracle developers, some issues, such as Internet communications, are beyond the control of the Oracle developer. Consequently, we can only address performance and tuning of WebServer applications from the time a URL request is intercepted by the Web Listener until the completed request has been serviced and returned to the client. During this period, the following steps occur: 1. The request is intercepted by the Web Listener. 2. The request is forwarded to the CGI or the WRB. 3. The request is handed to Oracle. 4. Oracle services the request and passes the data back to the CGI or WRB. 5. The Web document is prepared and sent through the Web Listener to the requesting client. Oracle WebServer achieves acceptable performance through a variety of mechanisms. The following sections discuss some of the mechanisms affecting WebServer’s performance.

WebServer Performance Issues Response time with the Oracle WebServer is a function of the interaction between numerous components. The following components are listed in order of their impact on WebServer performance and speed:

1. 2. 3. 4. 5.

The Internet (data transmission across the Internet) The Oracle database (servicing data requests) The Web Listener (spawning Oracle requests) The Web Request Broker (building HTML pages) The PL/SQL agent (loading and executing Oracle stored procedures)

We have no control over the speed of the Internet, but we do have some control over the Oracle components. Let’s take a look at some of the performance and tuning issues involved with the last two components. The Web Request Broker The Web Request Broker accepts connections from the Web Listener. These requests are in the form of URLs. When the WRB first receives a request, it interrogates the URL to determine the type of object being requested. The request could be for an Oracle stored procedure, a Java routine, or any routine that has been defined with a socket. The determination of the type of object being requested is a function of the pathname in the URL. The internal meaning of pathnames is governed by the WebServer configuration. For example, the WebServer may be configured so that URL requests beginning with /oraproc are passed to the PL/SQL agent and URL requests beginning with /java are passed to the Java interpreter. The PL/SQL Agent Interacting with a PL/SQL agent is generally much easier than interacting with Oracle using LiveHTML or Java. In addition, the PL/SQL agent is much faster than it was in WebServer version 1.0. This is due to a change in the architecture, whereby each instance of the PL/SQL agent stays connected to Oracle between database requests. Continuous connection does not mean that a run-unit connection is maintained with Oracle. Rather, it means that a communication connection to Oracle has been established, but no database connection has been made via SQL*Net. As you know, when someone establishes a connection to SQL*Plus, you can see the connection by selecting the V$SESSION view within Oracle. This is not the case with WebServer, because the PL/SQL agent only connects to Oracle during the servicing of the request. The servicing of a PL/SQL request consists of the following steps: 1. Retrieving the stored procedure from Oracle. 2. Executing the stored procedure. 3. Performing the specified database access. Because each HTTP request initiates a new SQL*Net session, Oracle is technically logging off and reestablishing an SQL*Net session each time a URL request is made. However, this process happens quickly because the Oracle server connection is maintained between URL requests.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Oracle Stored Procedures As objects such as stored procedures and triggers become more popular, more application code will move away from external programs and into the database engine. Oracle has been encouraging this approach in anticipation of the object-oriented features of Oracle8. We have even more reasons for using stored procedures with WebServer applications because stored procedures are the method used for all PL/SQL interfaces with Oracle. However, Oracle DBAs must be aware of the increased memory demands associated with stored procedures. DBAs must plan carefully for the increased memory requirements when processing logic within databases. Today, most Oracle databases have only a small amount of code in stored procedures—but this is rapidly changing. WebServer requirements aside, many compelling benefits can be derived by placing all Oracle SQL inside stored procedures. These benefits include: • Better performance—Stored procedures are loaded once into the SGA and remain there unless they become paged out. Subsequent executions of the stored procedure are far faster than external code. • Coupling of data with behavior—Relational tables can be coupled with the behaviors associated with them by using naming conventions. For example, if all behaviors associated with the EMPLOYEE table are prefixed with the table name (i.e., EMPLOYEE.hire, EMPLOYEE.give_raise), then the data dictionary can be queried to list all behaviors associated with a table (for instance, select * from dba_objects where owner = ‘EMPLOYEE’), and code can be readily identified and reused. • Isolation of code—Because all SQL is moved out of the external programs and into stored procedures, the application programs are nothing more than calls to stored procedures. As such, it becomes very simple to

swap out one database and swap in another. One of the foremost reasons why stored procedures and triggers function faster than traditional code is related to Oracle System Global Area (SGA). After a procedure has been loaded into the SGA, it will remain in the library cache until it’s paged out of memory. Items are paged out of memory based on a least-recently-used algorithm. Once loaded into the RAM memory of the shared pool, the procedure will execute very quickly. The trick is to prevent pool-thrashing during the period when many procedures are competing for a limited amount of library cache within the shared pool memory. Thrashing is the condition where stored procedures are flushed out of the library cache to make room for other stored procedures. When tuning Oracle, two init.ora parameters emerge as more important than all of the other parameters combined. These are the db_block_buffers and the shared_pool_size parameters. These two parameters define the size of the in-memory region that Oracle consumes on startup and determines the amount of storage available to cache data blocks, SQL, and stored procedures. Oracle also provides a construct called a package. Essentially, a package is a collection of functions and stored procedures that can be organized in a variety of ways. For example, functions and stored procedures for employees can be logically grouped together in an employee package, as follows: create package employee as function compute_raise_amount (percentage number); procedure hire_employee(); procedure fire_employee(); procedure list_employee_details(); end employee; Here we have encapsulated all employee “behaviors” into a single package that will be added into Oracle’s data dictionary. If we force our programmers to use stored procedures, the SQL moves out of the external programs and into the database, reducing the application programs into nothing more than a series of calls to Oracle stored procedures. As systems evolve and the majority of process code resides in stored procedures, Oracle’s shared pool becomes very important. The shared pool consists of the following subpools: • Dictionary cache • Library cache • Shared SQL areas • Private SQL area (these exist during cursor open/cursor close) • persistent area • runtime area As mentioned, the shared pool utilizes a least-recently-used algorithm to determine which objects are paged out of the shared pool. As this paging occurs,

fragments, or discontiguous chunks of memory, are created within the shared pool. This means that a large procedure that initially fits into memory may not fit into contiguous memory when it’s reloaded after paging out. Consider the body of a package that has been paged out of an instance’s SGA because of other, more recent or frequent activity. Fragmentation will occur, and the server will not be able to find enough contiguous memory to reload the package body, resulting in an ORA-4031 error.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

Pinning WebServer Packages In The SGA To prevent paging, packages can be marked as nonswappable, which tells the database that after their initial load they must always remain in memory. This is called pinning or memory fencing. Oracle provides a procedure called dbms_shared_pool.keep to pin a package. Packages can be unpinned with dbms_shared_pool.unkeep. Note: Only packages can be pinned. Stored procedures cannot be pinned unless they are placed into a package.

The choice of whether to pin a package in memory is a function of the size of the object and the frequency of its use. Very large packages that are called frequently might benefit from pinning, but any difference may go unnoticed because the frequent calls to the procedure have kept it loaded into memory. Therefore, because the object never pages out, the pinning has no effect. Also, the way procedures are grouped into packages may have some influence. Some Oracle DBAs identify high-impact procedures and group them into a single package, which is pinned in the library cache. In an ideal world, the shared_pool parameter of the init.ora should be large enough to accept every package, stored procedure, and trigger that may be used by an application. However, reality dictates that the shared pool cannot grow indefinitely, and wise choices must be made in terms of which packages are pinned and which are excluded from the pinning routine. Because of their frequent usage, Oracle recommends that the standard, dbms_standard, dbms_utility, dbms_describe, and dbms_output packages always be pinned in the shared pool. To illustrate how pinning works, the following snippet demonstrates how a stored procedure called sys.standard can be pinned: connect internal; @/usr/oracle/rdbms/admin/dbmspool.sql execute dbms_shared_pool.keep('sys.standard'); A stored procedure can be written to pin all of the recommended Oracle packages into the shared pool. Following is what this type of script might look like: EXECUTE EXECUTE EXECUTE EXECUTE EXECUTE EXECUTE EXECUTE

dbms_shared_pool.keep('DBMS_ALERT'); dbms_shared_pool.keep('DBMS_DDL'); dbms_shared_pool.keep('DBMS_DESCRIBE'); dbms_shared_pool.keep('DBMS_LOCK'); dbms_shared_pool.keep('DBMS_OUTPUT'); dbms_shared_pool.keep('DBMS_PIPE'); dbms_shared_pool.keep('DBMS_SESSION');

EXECUTE EXECUTE EXECUTE EXECUTE

dbms_shared_pool.keep('DBMS_SHARED_POOL'); dbms_shared_pool.keep('DBMS_STANDARD'); dbms_shared_pool.keep('DBMS_UTILITY'); dbms_shared_pool.keep('STANDARD');

Automatic Repinning Of Packages While this pinning routine ensures that a package stays pinned while the Oracle instance is running, you may also want to ensure that a package gets pinned each time the Oracle instance is started. Users of Oracle for Unix may want to add code to the /etc/rc file to ensure that the packages are repinned after each database startup. The rc file is generally maintained by the Unix system administrator, and this process guarantees that all packages are repinned with each bounce of the box. A pinning script might look like this: [root]: more pin ORACLE_SID=mydata export ORACLE_SID su oracle -c "/usr/oracle/bin/svrmgrl / 1 then increase the shared_pool_size in init.ora) PROMPT COLUMN "LIBRARY CACHE MISS RATIO" FORMAT 99.9999 COLUMN "executions" FORMAT 999,999,999 COLUMN "Cache misses while executing" format 999,999,999 SELECT sum(pins) "executions", sum(reloads) "Cache misses while (((sum(reloads)/sum(pins)))) "LIBRARY CACHE MISS RATIO" FROM v$librarycache;

RATIO"

executing",

PROMPT PROMPT ========================= PROMPT LIBRARY CACHE SECTION PROMPT ========================= PROMPT hit ratio should be > 70, and pin ratio > 70 ... PROMPT COLUMN "reloads" FORMAT 999,999,999 SELECT namespace, trunc(gethitratio * 100) "Hit ratio", trunc(pinhitratio * 100) "pin hit ratio", reloads "reloads" FROM v$librarycache; Just as the wisdom of the 1980s dictated that data should be centralized, the 1990s have begun an era where SQL is also centralized and managed. With the centralization of SQL, many previously impossible tasks have become

trivial. For example: • SQL can easily be identified and reused. • SQL can be extracted by DBAs, enabling explain plan utilities to be run to determine the proper placement of table indexes. • SQL can be searched, allowing for fast identification of “where used” information. For example, when a column changes definition, all SQL referencing that column can be quickly identified. As memory becomes less expensive, it will eventually become desirable to have all of the application’s SQL and code loaded into the Oracle library cache, where the code will be available quickly for execution by any external applications, regardless of platform or host language. The most compelling reasons for putting all SQL within packages are portability and code management. If all applications become “SQL-less,” with calls to stored procedures, then entire applications can be ported to other platforms without altering a single line of the application code. As the cost of memory drops, 500 MB Oracle regions will not be uncommon. Until that time, however, DBAs must carefully consider the ramifications of pinning a package in the SGA.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

Oracle Triggers Many database systems now support the use of triggers that can be fired at specific events. The insertion, modification, or deletion of a record may fire a trigger; or a business event, such as place_order, may initiate a trigger. Oracle Corporation claims that the design of their triggers closely follows the ANSI/ISO SQL3 draft standard (ANSI X3H6), but Oracle triggers are more robust in functionality than the ANSI standard. Triggers are defined at the schema level of the system, and will fire whenever an SQL select, update, delete, or insert command is issued. Remember that a trigger is always associated with a single DML event. Deciding When To Use A Trigger The choice of when to use a trigger and when to use a stored procedure can have a profound impact on the performance of the system. In general, triggers are used when additional processing is required as a row is inserted into a table. For example, assume that whenever a customer row is added, the system is required to look for the customer in the BAD_CREDIT table. If the customer appears in the BAD_CREDIT table, then its shipping_status column is set to COD. In this case, a trigger on insert of customer can fire the PL/SQL procedure to do the necessary lookup and set the shipping_status field to its appropriate value. Oracle triggers have the ability to call procedures, and a trigger may include SQL statements, thus providing the ability to nest SQL statements. Oracle triggers are stored as procedures that may be parameterized and used to simulate object-oriented behavior. For example, assume that we want to perform a behavior called check_total_inventory whenever an item is added to an order. (See Figure 16.1.)

Figure 16.1 The relationship among objects, triggers, and SQL. The trigger definition would be: create trigger check_total_inventory after select of item for each row

select count(*) into :count from quantity where item_num = :myitem if :count < item.total then ...... end if; Triggers can also be combined to handle multiple events, such as the reordering of an item when the quantity-on-hand falls below a predefined level, as follows: create trigger reorder before update on item for each row when (new.reorderable = 'y') begin if new.qty_on_hand + old.qty_on_order < new.minimum_qty then insert into reorder values (item_nbr, reorder_qty); new.qty_on_order := old.qty_on_order + reorder_qty; end if; end;

Oracle Hashing Oracle7 now supports the concept of hash clusters. A hash cluster is a construct that works with Oracle clusters and uses the hashkeys command to allow fast access to the primary key for the cluster, thereby reducing I/O for your WebServer application. To reduce I/O, Oracle relies on a hashing algorithm, which takes a symbolic key and converts it into a row ID (rowid). The hashing function ensures that the cluster key is retrieved in a single I/O, which is faster than reading multiple blocks from an index tree. Because a hashing algorithm always produces the same key each time it reads an input value, duplicate keys have to be avoided. In Oracle, these collisions result when the values of hashkeys are less than the maximum number of cluster key values. For example, if a hash cluster uses the cust_nbr field as the key, and we know that there will be 50,000 unique cust_nbr values, then we must be sure that the value of hashkeys is set to at least 50,000. Also, you should always round up your value for hashkeys to the next highest prime number. Following is an example of a hash cluster: create cluster my_cluster (customer_nbr varchar(10)) tablespace user1 storage (initial 50k next 50k pctincrease 1) size 2k hash is customer_nbr hashkeys 50000; Now a table is defined within the cluster: create table customer ( customer_nbr number primary key) cluster my_cluster (customer_nbr); The size parameter is usually set to the average row size for the table. Oracle recommends using a hash cluster when the following are true: • Use hash clusters to store tables commonly accessed by where clauses that specify equalities. • Only use hash clusters when you can afford to keep plenty of free space on each database block for updates. This value is set by the pctfree statement in the create table parameter.

• Only use hash clusters if you are absolutely sure that you will not need to create a new, larger cluster at a later time. • Do not use a hash cluster if your table is commonly accessed by full-table scans, especially if a great deal of extra space from future growth has been allocated to the hash cluster. In a full-table scan, Oracle will read all blocks of the hash cluster, regardless of whether they contain any data rows. • Do not use a hash cluster if any of the hash cluster keys are frequently modified. Changing the value of a hash key causes the hashing algorithm to generate a new location, and the database will migrate the cluster to a new database block if the key value is changed. This is a very time-consuming operation. Keep in mind that the total size of the index columns must fit inside a single Oracle block. If the index contains too many long values, additional I/O will be required and updates and inserts will cause serious performance problems. Note the sample hashing routine shown in Figure 16.2.

Figure 16.2 A sample hashing routine. The database designer may choose to make the buffer blocks large to minimize I/O if the application clusters record on a database page. If a customer record is only 100 bytes, we will not gain by retrieving 32,000 bytes in order to get the 100 bytes that we need. However, if we cluster the orders physically near the customer (on the same database page), and if I/O usually proceeds from customer to order, then we will not need further I/O to retrieve orders for the customer.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Oracle Clusters Clustering is a very important concept for improving Oracle performance. As you know, when accessing Oracle, reducing I/O always improves throughput and overall performance. The concept of a cluster is very similar to the use of the VIA set in the CODASYL Network database model, where member records are stored physically near parent records. For Oracle, clusters can be used to define common one-to-many access paths, and the member rows can be stored on the same database block as their owner row. For example, assume that we have a one-to-many relationship between customers and orders. If our application commonly accesses the data from customer to order, we can cluster the order rows on the same database block as the customer row. In this way, we’ll receive the list of all orders for a customer in a single I/O. (See Figure 16.3.) Of course, we will need to size the database blocks with db_block_size so that an entire order will fit onto a single database block.

Figure 16.3 A sample Oracle cluster. We need to note one important issue: While a cluster will tremendously improve performance in one direction, queries in the other direction will suffer. For example, consider the many-to-many relationship between customers and orders. We have the junction table, ORDER_LINE, at the intersection of this many-to-many relationship and we need to decide which owner, ORDER or ITEM, will be the anchor for our cluster. If we commonly traverse from ORDER to ITEM (e.g., displaying an order form), it would make sense to cluster the ORDER_LINE records on the same database block as their ORDER owner. If, on the other hand, we commonly traversed from ITEM to ORDER (e.g., requesting the details for all orders containing

widgets), we would cluster the ORDER_LINE rows near their ITEM owner. If we cluster on the ORDER owner, database queries that display order forms will be very fast, while queries in the other direction will have to do additional I/O.

Oracle Parallel Query One of the most exciting performance features of Oracle version 7.3 and above is the ability to partition an SQL query into subqueries and dedicate separate processors to concurrently service each subquery. At this time, parallel query is useful only for queries that perform full-table scans on long tables, but the performance improvements can be dramatic. Here’s how it works. Instead of having a single query server manage the I/O against a table, parallel query allows the Oracle query server to dedicate many processors to acess the data, simultaneously, as shown in Figure 16.4.

Figure 16.4 A sample parallel query. To be most effective, the table should be partitioned onto separate disk devices, such that each process can do I/O against its segment of the table without interfering with the other simultaneous query processes. However, the client/server environment of the 1990s relies on RAID or a logical volume manager (LVM), which scrambles data files across disk packs in order to balance the I/O load. Consequently, full utilization of parallel query involves striping a table across numerous data files, each on a separate device. Even if your system uses RAID or LVM, some performance gains are still available with parallel query. In addition to using multiple processes to retrieve the table, the query manager will also dedicate numerous processes to simultaneously sort the result set. (See Figure 16.5.)

Figure 16.5 A sample parallel sort. Parallel query works best with symmetric multiprocessor (SMP) boxes, which have more than one internal CPU. Also, it is important to configure the system to maximize the I/O bandwidth, either through disk striping or high-speed channels. Because of the parallel sorting feature, it is also a good idea to beef up the memory of the processor. While sorting is no substitute for using a presorted index, the parallel query manager will service requests far faster than a single process. The data retrieval will not be significantly faster, though, because all of the retrieval processes will be competing for a channel on the same disk. Each sort process has its own sort area (as determined by the sort_area_size init.ora parameter), which speeds along the sorting of the result set. In addition to full-table scans

and sorting, the parallel query option also allows parallel processing for merged joins and nested loops.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

Invoking the parallel query option requires all indexing to be bypassed. And, most importantly, the execution plan for the query specifies a full-table scan. If the output of the explain plan does not indicate a full-table scan, the query can be forced to ignore the index by using query hints. The number of processors dedicated to service an SQL request is ultimately determined by the Oracle query manager, but the programmer can specify the upper limit on the number of simultaneous processes. When using the cost-based optimizer, the parallel hint can be embedded into the SQL to specify the number of processes. For example: select /*+ full(EMPLOYEE_TABLE) parallel(EMPLOYEE_TABLE, employee_name from EMPLOYEE_TABLE where emp_type = 'SALARIED';

4) */

If you are using SMP with many CPUs, you can issue a parallel request and leave it up to each Oracle instance to use their default degree of parallelism, as follows: select /*+ full(EMPLOYEE_TABLE) parallel(EMPLOYEE_TABLE, default, default) */ employee_name from EMPLOYEE_TABLE where emp_type = 'SALARIED'; Several important init.ora parameters have a direct impact on parallel query: • sort_area_size—The higher the value, the more memory available for individual sorts on each parallel process. Note that the sort_area_size parameter allocates memory for every query on the system that invokes a sort. For example, if a single query needs more memory and you increase the sort_area_size, all Oracle tasks will allocate the new amount of sort area, regardless of whether they will use all of the space. • parallel_min_servers—The minimum number of query servers active on the instance. System resources are involved in starting a query server, so having the query server started and waiting for requests will speed up processing. Note that if the actual number of required servers is less than the value of parallel_min_servers, the idle query servers will be consuming unnecessary overhead, and the value should be decreased. • parallel_max_servers—The maximum number of query servers allowed on the instance. This parameter will prevent Oracle from starting so many query servers that the instance is unable to service all of them properly. To see how many parallel query servers are busy at any given time, the following query can be issued against the v$pq_sysstat table:

select * from v$pq_sysstat where statistic = 'Servers Busy'; STATISTIC Servers Busy

VALUE 30

In this case, we see that 30 parallel servers are busy. Do not be misled by this number. Parallel query servers are constantly accepting work or returning to idle status, so it is a good idea to issue the query many times over a one hour period. Only then will you have a realistic measure of how many parallel query servers are being used.

Summary Now that we have covered the some of the tricks that can be used within Oracle to speed up WebServer queries, let’s take a look at the broader Oracle picture and explore how Oracle tuning can help WebServer at the system level. In the next chapter, we’ll explore how Oracle memory (SGA) can be tuned so that you’ll achieve maximum performance from your WebServer data requests.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

CHAPTER 17 Tuning Oracle SQL Up until now, you’ve been reading about the physical Oracle database issues involved when creating a WebServer application; now let’s take a look at how Oracle’s SQL can be tuned to ensure optimal performance from WebServer. While several books have been devoted to the efficient use of Oracle SQL, only a handful of general rules and guidelines are effective in guaranteeing optimal performance from Oracle databases. This chapter focuses on the basic techniques for quickly achieving the maximum SQL performance with the least amount of effort. Topics in this chapter include: • Reviewing tips for creating efficient SQL • Using index predicates • Using concatenated indexes • Improving performance using temporary tables • Tuning with the rule-based optimizer • Using hints with the cost-based optimizer Tuning Oracle SQL Syntax SQL is a declarative language, so you can write a query many ways. And while each query might return identical results, the execution time can vary dramatically. To illustrate this concept, let’s consider a small employee table with 100 rows and an index on sex and hiredate. Let’s say you issue the following query to retrieve all female employees who have been hired within the last 90 days. The query uses Oracle’s rule-based optimizer, as follows:

select emp_name from EMPLOYEE where sex = 'F' and hiredate between sysdate-90 and sysdate; Because the table has only 100 rows, the most efficient way to service this request would be to use a full-table scan. However, Oracle will walk the index that exists, performing dozens of extra I/Os as it reads the index tree to access the rows in the table. This simplistic example serves to illustrate the concept that the execution time of SQL is heavily dependent on the way a query is stated, as well as the internal index structures within Oracle. It’s true that each dialect of SQL is different, but general rules apply that can be used to keep database queries running efficiently. And while these guidelines are no substitute for the SQL explain plan facility, they can reduce the chances that a database query will consume large amounts of system resources. The first step is to look at the relative costs for each type of SQL access. Oracle has published the cost list shown in Table 17.1 that describes the relative cost of each type of SQL access. Cost 1

Table 17.1 Costs for SQL access. Type of Operation Single row by row ID (rowid)

2

Single row by cluster join

3

Single row by hash cluster key with unique or primary key

4

Single row by unique or primary key

5

Cluster join

6 7

Hash cluster key Indexed cluster key

8

Use of a multicolumn index

9

Use of a single-column index

10

Bounded range search on indexed columns

11

Unbounded range search on unindexed columns

12

Sort-merge join

13 14

Max or min search of an indexed column Use of order by on an indexed column

15

Full-table scan

As you can see, the fastest way to retrieve a row is by knowing its row ID. A row ID (called a rowid in Oracle) is the number of the database block followed by the displacement, or position, of the row on the block. For example, 1221:3 refers to the third row on a page, on block number 1221. Many experienced Oracle programmers capture the rowid for a row if they

plan to re-retrieve it. In Oracle, rowid is a valid column statement, such that you can select the rowid along with your data in a single statement, such as: select rowid from EMPLOYEE into :myvar; Inside a WebServer application, PL/SQL storage arrays can be defined to hold rowid values. For details, see Chapter 8, WebServer’s OWA Utilities. When creating WebServer applications, keep in mind that the most expensive SQL statement is one that invokes a full-table scan. As you may know, a full-table scan is acceptable for small tables, but it can wreak havoc on an entire Oracle instance when a full-table scan is invoked against a large table. Therefore, more than any other SQL tuning technique, avoiding large-table full-table scans is a primary consideration. With proper tuning of Oracle SQL, full-table scans can usually be avoided by using indexes and index hints. What about queries that need to read every row of a table? While a full-table scan may be the fastest for an individual query where every row in the table must be read (i.e., using sum, avg, or queries with many complex where conditions), the full-table scan is done at the expense of other SQL on the system. As a large-table full-table scan reads rows into memory, buffer pages containing rows from other queries will be flushed from the buffer, and Oracle will need to re-retrieve these rows. So, the question is, do you tune an individual query for performance, or do you tune the database as a whole? Generally speaking, we cannot allow a single query to achieve good response time at the expense of all other tasks on the database.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

General Tips For Efficient SQL Fortunately, some general rules are available for writing efficient SQL in Oracle. These rules may seem simplistic, but diligently following them will relieve more than half of your SQL tuning problems. • Never do a calculation on an indexed column (e.g., where salary*5 > :myvalue). • Whenever possible, use the union statement instead of or. • Avoid the use of not in or having in the where clause. Instead, use the not exists clause. • Always specify numeric values in numeric form and character values in character form (e.g., where emp_number = 565, where emp_name = ‘Jones’). • Avoid specifying NULL on an indexed column. • Avoid the like parameter if = will suffice. Using any Oracle functions will invalidate the index, causing a full-table scan. • Never mix datatypes in Oracle queries, as it will invalidate the index. If the column is numeric, remember not to use quotes (e.g., salary = 50000). For char index columns, always use quotes (e.g., name = ‘BURLESON’). • Remember that Oracle’s rule-based optimizer looks at the order of table names in the from clause to determine the driving table. Always make sure that the last table specified in the from clause is the table that will return the smallest number of rows. In other words, specify multiple tables with the largest result set table specified first in the where clause. • Avoid using subqueries when a join will do the job. • Use the Oracle decode function to minimize the number of times a table has to be selected. • To turn off an index you do not want to use (only with cost-based), concatenate a null string to the index column name (e.g., name||‘’), or add zero to a numeric column name (e.g., salary+0). • If your query will return more than 20 percent of the rows in the table, use a

full-table scan rather than an index scan. • Always use table aliases when referencing columns. Historically, queries pose a common problem with SQL. Simple queries can be written in many different ways, each variant of the query producing the same result but with widely different access methods and query speeds. For example, a simple query such as “What students received an A last semester?” can be written in three ways, as shown in Listings 17.1, 17.2, and 17.3, each returning an identical result. Listing 17.1 A standard join. select * from STUDENT, REGISTRATION where STUDENT.student_id = REGISTRATION.student_id and REGISTRATION.grade = 'A'; Listing 17.2 A nested query. select * from STUDENT where student_id = (select student_id from REGISTRATION where grade = 'A' ); Listing 17.3 A correlated subquery. select * from STUDENT where 0 < (select count(*) from REGISTRATION where grade = 'A' and student_id = STUDENT.student_id ); Each of these queries will return identical results, but the access path that the queries take through the Oracle database varies greatly. The following discussion will review the basic components of an SQL query, showing how to optimize a query for remote execution. It is important to note that several steps are required to understand how SQL is used in a distributed database. Distributed SQL queries function in the same way as queries within a single database, with the exception that

cross-database joins and updates may utilize indexes that reside on different databases. Regardless, a basic understanding of the behavior of SQL can lead to dramatic performance improvements.

Using Oracle’s Explain Plan Facility Because SQL is a declarative language, it is not immediately apparent how an SQL query is being serviced. Whether or not Oracle is using an index, performing a full-table scan, or performing a merge sort, is hidden from view. Fortunately, tools exist within Oracle’s implementation of SQL that allow the access path to be interrogated. To see the output of an explain plan, you must first create a plan table to store the output from the explain. Oracle provides a script in $ORACLE_HOME/rdbms/admin with a script called utlxplan.sql. Execute utlxplan.sql, and create a public synonym for the PLAN_TABLE, as follows: sqlplus>@utlxplan table created. sqlplus > create public synonym PLAN_TABLE for SYS.PLAN_TABLE; synonym created. Oracle uses the explain utility by taking the SQL statement as input, running the SQL optimizer, and then sending the access path information into a PLAN_TABLE, which can then be interrogated to see the access methods. Listing 17.4 runs a query against a sales database to get the sum of costs for a particular month. Listing 17.4 A database query against a sales database. explain plan set statement_id = 'test1' for set statement_id = 'run1' into PLAN_TABLE for select 'T'||costsnet.terr_code, 'P'||detcost.pac1 || detcost.pac2 || detcost.pac3, 'P1', sum(costsnet.ytd_d_ly_tm), sum(costsnet.ytd_d_ty_tm), sum(costsnet.jan_d_ly), sum(costsnet.jan_d_ty), from costsnet, detcost where costsnet.mgc = detcost.mktgpm and detcost.pac1 in ('N33','192','195','201','BAI', 'P51','Q27','180','181','183','184','186','188', '198','204','207','209','211') group by 'T'||costsnet.terr_code, 'P'||detcost.pac1 || detcost.pac2 || detcost.pac3; This syntax is piped into the SQL optimizer, which will analyze the query and store the plan information in a row in the plan table identified by RUN1. Please note that the query will

not execute; it will only create the internal access information in the plan table. The plan table contains the following fields: • operation—Type of access being performed. Usually table access, table merge, sort, or index operation. • options—Modifiers to the operation, specifying a full table, a range table, or a join. • object_name—Name of the table being used by the query component. • process ID—Identifier for the query component. • parent ID—Parent of the query component. Note that several query components may have the same parent.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

Now that the PLAN_TABLE has been created and populated, you may interrogate it to see your output by running the following query: rem plan.sql - displays contents of the explain plan table set pages 9999; select lpad(' ',2*(level-1))||operation operation, options, object_name, position from plan_table start with id=0 and statement_id = 'RUN1' connect by prior id = parent_id and statement_id = 'RUN1'; Listing 17.5 shows the output from the plan table. Listing 17.5 The plan table’s output. SQL>@list_explain_plan OPERATION ——————————————————————————————————— OPTIONS OBJECT_NAME ————————————— ——————————————— SELECT STATEMENT SORT GROUP BY

POSITION ————————————

1

CONCATENATION 1 NESTED LOOPS TABLE ACCESS FULL

COSTSNET

1 1

TABLE ACCESS BY ROWID

DETCOST

2

INDEX RANGE SCAN

DETCOST_INDEX5

1

NESTED LOOPS From this output, you can see the dreaded table access full on the COSTSNET table. To diagnose the reason, return to the SQL and look for any COSTSNET columns in the where clause. There you can see that the COSTSNET column called mgc is being used as a join column in the query, indicating that an index is necessary on COSTSNET.mgc to alleviate the full-table scan. While the plan table is useful for determining the access path to the data, it doesn’t tell the whole story. The configuration of the data is also a consideration. While the SQL optimizer is aware of the number of rows in each table (the cardinality) and the presence of indexes on fields, the SQL optimizer is not aware of data distribution factors, such as the number of expected rows returned from each query component. The other tool used with the plan table is an SQL trace facility. Most database management systems provide a trace facility that shows the resources consumed within each query component. The trace table will show the number of I/Os required to perform the SQL, as well as the processor time for each query component. Some other relational databases, such as DB2, allow the DBA to specify the physical sequence for storing the rows. Generally, this sequence will correspond to the column value most commonly used when the table is read sequentially by an application. If a customer table is frequently accessed in customer ID order, then the rows should be physically stored in customer ID sequence. The explain plan output will display many database access methods. The major access techniques include: • and-equal—Indicates that tables are being joined and that Oracle will be able to use the values from the indexes to join the rows. • concatenation—Indicates an SQL union operation. • counting—Indicates the use of the SQL count function. • filter—Indicates that the where clause is removing unwanted rows from the result set. • first row—Indicates that a cursor has been declared for the query. • for update—Indicates that returned rows were write locked (usually by using the select…for update of…). • index (unique)—Indicates that an index was scanned for a value specified in the where clause. • index (range scan)—Indicates that a numeric index was scanned for a range of values (usually with the between, less_than, or greater_than specified). • intersection—Indicates a solution set from two joined tables. • merge join—Indicates that two result sets were used to resolve the query. • nested loops—Indicates that the last operation will be performed n times, once for each preceding operation. For example, below the index (unique), these operations will be performed for each row returned by table access (full): nested loops, table access (full) of ‘customer’, and index (unique) of sy_01_idx. • projection—Indicates that only certain columns from a selected row are to be returned. • sort—Indicates a sort, either into memory or the TEMP tablespace. • table access (rowid)—Indicates a row access by rowid that is very fast. • table access (full)—Indicates a full-table scan and is usually cause for concern unless the table is very small. • union—Indicates that the distinct SQL clause was probably used. • view—Indicates that an SQL view was involved in the query.

Database statistics packages can be made to capture this information, but they tend to be very resource intensive. Turning on SQL trace statistics for a very short period of time during processing is a good practice to follow and enables you to gather a representative sample of the SQL access. Using Temporary Tables The prudent use of temporary tables can dramatically improve WebServer performance. Consider the following example. You want to identify all users who exist within Oracle, but have not been granted a role. You could formulate the following query: select username from dba_users where username not in (select grantee from dba_role_privs); This query runs in 18 seconds. Now, you could rewrite the same query to utilize temporary tables, as follows: create table temp1 as select distinct username from dba_users; create table temp2 as select distinct grantee from dba_role_privs; select username from temp1 where username not in (select grantee from temp2); This query runs in less than 3 seconds.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Tuning With The Rule-Based Optimizer In Oracle’s rule-based optimizer, the ordering of the table names in the from clause determines the driving table. The driving table is important because it is retrieved first, and the rows from the second table are then merged into the result set from the first table. Therefore, it is essential that the second table returns the least amount of rows based on the where clause. This is not always the table with the least amount of rows (i.e., the smallest cardinality). For example, consider two EMP_TABLEs—one in London and another in New York, as shown in Table 17.2. Table 17.2 New York and London EMP_TABLES. Rows Dpt 100 Dpt 200 New York

1,000

100

900

London

200

150

50

In this example, a total select from the EMP_TABLE should specify the New York table first because London has the least amount of returned rows. The SQL should appear as follows: select * from emp@new_york, emp@london; If the SQL specifies a where condition to include only Department 100, the order of table names should be reversed, as follows: select * from emp@london, emp@new_york where

DEPT = 100; It’s not always known what table will return the least amount of rows, so procedural code could be used to interrogate the tables and specify the tables in their proper order. This type of SQL generation can be very useful for ensuring optimal database performance, as shown in Listing 17.6. Listing 17.6 Automatic generation of optimal rule-based SQL. select count(*) into :my_london_dept from emp@london where dept = :my_dept; select count(*) into :my_ny_dept from emp@new_york where dept = :my_dept; if my_london_dept >= my_ny_dept { table_1 = emp@london table_2 = emp@new_york else table_1 = emp@new_york table_2 = emp@london } /* Now we construct the SQL */ select * from :table_1, :table_2 where dept = :my_dept; As you probably know, Oracle version 7 offers two methods of tuning SQL. If you are running version 7.2 or above, you can use the cost-based optimizer; releases of Oracle 7.1 and below require the rule-based optimizer. With the rule-based optimizer, the indexing of tables and order of clauses within an SQL statement control the access path. The cost-based optimizer automatically determines the most efficient execution path, and the programmer is given hints that can be added to the query to alter the access path. The cost-based optimizer or the rule-based optimizer is set in the init.ora file when the DBA sets the optimizer_mode to rule, choose, first_rows, or all_rows. Beware of using the choose option. When you give Oracle the ability to choose the optimizer mode, Oracle will favor the cost-based approach if any of the tables in the query contains statistics. (Statistics are created with the analyze table command.) For example, if a three-table join is specified in choose mode and statistics exist for one of the three tables, Oracle will decide to use the cost-based optimizer and will issue an analyze table estimate statistics at runtime. This will dramatically slow down the query. The optimizer option (rule versus cost) can be controlled at the database level or at the program level. Prior to version 7.0.16, the cost-based analyzer had

significant problems, and Oracle recommended the use of the rule-based optimizer. Here are some tips for effective use of Oracle’s rule-based optimizer: • Try changing the order of the tables listed in the from clause. Page 1915 in Oracle RDBMS Database Administrator’s Guide states, “Joins should be driven from tables returning fewer rows rather than tables returning more rows.” In other words, the table that returns the fewest rows should be listed last. This usually means that the table with the most rows is listed first. If the tables in the statement have indexes, the driving table is determined by the indexes. One Oracle developer recently slashed processing time in half by changing the order of the tables in the from clause. Another developer had a process shift from running for 12 hours to completing in 30 minutes by changing the from clause. • Try changing the order of the statements in the where clause. Here’s the idea: Assume that an SQL query contains an if statement with several boolean expressions separated by ands. Oracle parses the SQL from the bottom of the SQL statement in reverse order. Therefore, the most restrictive boolean expression should be on the bottom. For example, consider the following query: select last_name from STUDENT where eye_color = 'BLUE' and national_origin = 'SWEDEN'; Here, the number of students from Sweden is assumed to be smaller than the number of students with blue eyes. To further confound matters, if an SQL statement contains a compound if separated by ors, the rule-based optimizer parses from the top of the where clause. Therefore, the most restrictive clause should be the first boolean item in the if statement. • Analyze the existence/nonexistence of indexes; understand your data. Again, unlike the cost-based optimizer, the rule-based optimizer only recognizes the existence of indexes and does not know about the selectivity or the distribution of the index column. Consequently, use care when creating indexes, especially when using rule-based optimization. Consider all programs that use a field in a where clause of a select. A field should only be indexed when a very small subset (less than 10 percent) of the data will be returned. • Check to see if the target table is fragmented. For example, a table could be fragmented if it constantly has a large number of rows inserted and deleted. This is especially true in pctfree because the table has been set to a low number. Regular compression of the table with Oracle’s export/import utility will restore the table row and remove fragmentation.

• Always run questionable SQL through explain plan to examine the access path. • Understand which “query paths” are the fastest. For example, accessing a table by rowid is the fastest access method available where a full-table scan is 17 out of 18 for the ranking of query paths. (Reference Table 17.1 for the complete list of relative costs.) • Avoid joins that use database links into Oracle version 6 tables. • Make effective use of arrays. Array processing significantly reduces database I/O. Consider the following example. A table has 1,000 rows to be selected. The records are manipulated and then updated in the database. Without using array processing, the database receives 1,000 reads and 1,000 updates. With array processing (assuming an array size of 100), the database receives 10 reads (1,000/100) and 10 updates. According to Oracle, increasing the array size to more than 100 has little benefit. Beware of an Oracle rule-based “feature” whereby a join of numerous large tables will always result in a full-table scan on one of the tables, even if all of the tables have indexes and the join could be achieved with an index scan. Of course, full-table scans are costly, and SQL hints can be used to force the query to use the indexes. You can use hints with the rule-based optimizer.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Using Hints With The Cost-Based Optimizer The rule-based optimizer is supposed to be obsolete with the introduction of Oracle version 8, but its replacement—the cost-based optimizer—is already available today. Unlike the rule-based optimizer, which uses heuristics to determine the access path, the cost-based optimizer uses data statistics to determine the most efficient way to service the request. Here is a summary of the most common hints that can be added to SQL: • all_rows—This is the cost-based approach designed to provide the best overall throughput. • cluster—Requests a cluster scan of the table(s). • first_rows—This is the cost-based approach designed to provide the best response time. • full—Requests the bypassing of indexes doing a full-table scan. • index—Requests the use of the specified index. If no index is specified, Oracle will choose the best index. • rowid—Requests a rowid scan of the specified table. • rule—Indicates that the rule-based optimizer has been invoked (sometimes to the absence of table statistics). • ordered—Requests that the tables should be joined in the order that they are specified. For example, if you know that a STATE table has only 50 rows, you may want to use this hint to make STATE the driving table. • use_nl—Requests a nested loop operation with the specified table as the driving table. • use_merge—Requests a sort-merge operation. Remember, the cost-based optimizer will only be as accurate as the statistics computed from the tables. The DBA will need to create a periodic cron job for statistics. This job

will re-estimate statistics for tables that are volatile and change columns frequently. While a full analyze table xxx estimate statistics will interrogate every row of the table, a faster method can be used by issuing analyze table estimate statistics sample nn rows. By taking a sample of the rows within the table, the statistics generation will run much faster. Keep in mind that one of the things the analyze command reviews is the selectivity and distribution of values within an index. As such, care should be taken to sample at least 100 rows from each table. Here is a test that created a set of three tables—DEPT, DEPT1, and DEPT2—each with an index on deptno and set optimizer_goal as rule in the init.ora. Listing 17.7 shows the results of the query. Listing 17.7 The results of the execution plan query. select /*+ INDEX(dept DEPT_PRIMARY_KEY) INDEX(dept2 i_dept2) INDEX(dept1 i_dept1)*/ dept.deptno, dept1.dname, dept2.loc from dept, dept1, dept2 where dept.deptno=dept1.deptno and dept1.deptno=dept2.deptno Misses in library cache during parse: 1 Optimizer hint: RULE Parsing user id: 48 (DON) Rows ——— 0 4 4 4 5 4 8 4 4 5

Execution Plan ————————————————————————— SELECT STATEMENT OPTIMIZER HINT: RULE MERGE JOIN SORT (JOIN) NESTED LOOPS INDEX (RANGE SCAN) OF 'DEPT_PRIMARY_KEY' (UNIQUE) TABLE ACCESS (BY ROWID) OF 'DEPT1' INDEX (RANGE SCAN) OF 'I_DEPT1' (NON-UNIQUE) SORT (JOIN) TABLE ACCESS (BY ROWID) OF 'DEPT2' INDEX (RANGE SCAN) OF 'I_DEPT2' (NON-UNIQUE)

Listing 17.8 shows the previous query’s results without any hints. Listing 17.8 The query results with no hints. select dept.deptno, dept1.dname, dept2.loc from dept, dept1, dept2 where dept.deptno=dept1.deptno and dept1.deptno=dept2.deptno Misses in library cache during parse: 1 Optimizer hint: RULE Parsing user id: 48 (JACK)

Rows ——— 0 4 4 4 4 8 4

Execution Plan ————————————————————————— SELECT STATEMENT OPTIMIZER HINT: RULE NESTED LOOPS NESTED LOOPS TABLE ACCESS (FULL) OF 'DEPT2' TABLE ACCESS (BY ROWID) OF 'DEPT1' INDEX (RANGE SCAN) OF 'I_DEPT1' (NON-UNIQUE) INDEX (UNIQUE SCAN) OF 'DEPT_PRIMARY_KEY' (UNIQUE)

If a hint was added for the DEPT2 index, the full-table scan would be on DEPT1, and so on.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next -----------

Tuning PL/SQL Procedure Language/SQL is the standard procedural language for WebServer applications. PL/SQL is also commonly used within Oracle’s SQL*Forms application framework. But the re-emergence of PL/SQL’s popularity for non-SQL*Forms applications can be attributed to the benefits of using Oracle stored procedures—which must be written with PL/SQL. It is Oracle’s stored procedures that make the htp utilities possible for WebServer implementation. PL/SQL offers the standard language constructs, including looping, if statements, assignment statements, and error handling. There are several problems with PL/SQL, each of which warrants special attention. PL/SQL offers two types of SQL cursors: the explicit cursor and the implicit cursor. Explicit cursors are manually declared in the PL/SQL, as follows: DECLARE CURSOR C1 IS select last_name from customer where cust_id = 1234; However, it’s possible to issue the SQL statement directly in PL/SQL without specifying the cursor name. When this happens, Oracle opens an implicit cursor to handle the request. Implicit cursors create a tremendous burden for Oracle, as the implicit cursor must always reissue a fetch command to ensure that only a single row is returned by the query. This will double the amount of fetch statements for the query. The moral is simple: Always declare all cursors in your PL/SQL. PL/SQL allows certain types of correlated subqueries to run much faster than traditional Oracle SQL queries. This is a critical issue with WebServer, because it may be much faster to embed all Oracle SQL in PL/SQL rather than embedding the SQL in Perl or Java. To illustrate why WebServer may run faster with PL/SQL than with Perl or Java SQL, consider a situation where a bank maintains a general ledger table and a transaction table. At the end of the banking day, the check transaction table is applied to the GENERAL_LEDGER table, making the requisite deductions from the account_balance column. Let’s assume that the GENERAL_LEDGER table contains 100,000 rows and 5,000 daily checks need to be processed.

A traditional SQL query (shown in Listing 17.9) used to accomplish the updating of account_balance would involve a correlated subquery. This is the type of SQL that you might embed into a Perl or Java script for a WebServer application. Listing 17.9 Using a traditional SQL query. update general_ledger set account_balance = account_balance (select check_amount from transaction where transaction.account_number = general_ledger.account_number) where exists (select 'x' from transaction where transaction.account_number = general_ledger.account_number); When Oracle detects a correlated subquery, Oracle will execute the subquery first, and then apply the query result to the entire outer query. In this case, the inner query will execute 5,000 times, and the outer query will be executed once for each row returned from the inner query. This is called a Cartesian product and has always been a problem for this type of query. Now, consider the identical query written in PL/SQL, as shown in Listing 17.10. Listing 17.10 The PL/SQL query. DECLARE CURSOR c1 is select account_number, check_amount from transaction; keep_account_number keep_check_amount

number; number;

BEGIN OPEN C1; LOOP fetch C1 into keep_account_number, keep check_amount; exit when C1%NOTFOUND; update general_ledger set account_balance = account_balance - keep_check_amount where account_number = keep_account_number; END LOOP; END; Here you can see that each check amount is retrieved in a separate transaction and fetched into cursor C1. For each check_amount, the balance is applied to the GENERAL_LEDGER row, one at a time.

Summary Now that you’ve reviewed Oracle database tuning for WebServer, let’s take a look into the future to get an idea how the nature will be changing. As you may know, the next major release of Oracle

(version 8) will have object-oriented features, and the WebServer developer will benefit from understanding how these changes to the Oracle architecture will affect the Oracle WebServer product.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

CHAPTER 18 The Future Of Database Management While Oracle WebServer is considered cutting-edge technology today, it will only be a few short years before the technology again shifts direction. The introduction of Oracle version 8, the concept of a “universal” database server, and the advances in hardware technology are combining to present an exciting future for Oracle applications. Many new terms are being used to describe future database systems—knowledgebases, intelligent databases, neural databases, and database machines are but a few. Oracle version 8 is just the beginning.

Oracle Version 8 The next progression of database architectures is moving toward object-oriented databases. Early file managers stored data; network databases stored data and relationships; object-oriented databases will store data, data relationships, and the behaviors of the data. In general, the Oracle8 engine is remarkably similar to the relational engine found in Oracle 7.3, but with major extensions to the relational architecture. It is interesting to note that Oracle has not discarded the idea of creating a “universal” database engine. Oracle is calling Oracle8 the “Oracle Universal Server,” adding text and multidimensional and object capabilities to the relational engine. The most exciting enhancements involve the introduction of Sedona, the incorporation of the Oracle Express MDDB, and the “object layer” that will be tightly coupled with the relational engine. Oracle Sedona

Due to the secrecy around the development of Oracle8, many Oracle professionals assumed that Sedona was the code name for Oracle8. However, Sedona is actually an extension to Oracle8. Sedona has been billed as a universal object manager, and it appears that its basic function is to act as an object consolidator. Sedona will allow for Oracle methods to be indexed and quickly located across many databases and platforms. Sedona achieves this by placing an object wrapper around Oracle objects so that they can be accessed by other distributed systems. While the details are sketchy, Sedona will incorporate many of the features of an Object Request Broker (ORB), with a metadata dictionary for the distributed management of objects. With Sedona, object classes may be registered in a central repository so that they will be available for use transparently across the enterprise. Oracle has made the interface specifications for Sedona available to third-party software vendors, hoping that vendors will create application products utilizing Sedona. Oracle ConText A text searching option called Oracle ConText has also been added to the relational engine of Oracle8. Oracle ConText allows thematic word searching capabilities against Oracle’s relational database. Although the ConText option indexes on each word within the text, the real power of the text retrieval system is located in the front-end software. While this represents a major improvement over Oracle Book (which is now obsolete), it remains to be seen how ConText will compete in the marketplace as a text search engine. There are two fundamental ways to measure the accuracy of text retrieval: • Precision—Retrieves only relevant documents (no false or “noisy” hits). • Recall—Retrieves all relevant documents in a given data collection. Together, precision and recall represent the overall accuracy of a text retrieval system. Natural language is a phrase frequently heard in conjunction with concept-based searching, and morphology is a term commonly used by text databases to simulate natural language query. Morphology recognizes basic units of meaning and parts of speech. To understand morphology, consider the phrase “Please write to Mr. Wright right now.” To the human ear, all of the words sound identical; the meaning of the words can be determined only by the context of the sentence. From the initial review, it is still unclear how well Oracle ConText will be able to compete with the other more established text engines such as ConQuest, Fulcrum, and Folio. Oracle Express Unlike Oracle 7.3, where the Express multidimensional database was installed independently of Oracle, the Express product has been incorporated into the Oracle8 kernel. This implies yet another change for Oracle DBAs, who must now manage both the relational and multidimensional components of Oracle. Oracle Express will be offered for NT and PC, as well as Unix platforms. The basic reporting functions of Express have been enhanced to provide forecasting and model building. Unlike the Express product developed by IRI, Oracle Express has been

enhanced so that it does not require data to be preloaded into its internal data structures. This enhancement enables Express to read relational data directly from relational Oracle databases, dynamically transforming and aggregating the data for multidimensional presentation. This means that Express will now compete against other relational back-end products, such as Holos and MetaCube. SQL For Object-Orientation The object-oriented approach borrows heavily from C++ and Smalltalk. Both languages allow for the storing of behaviors with the data, such that data and business rules share a common repository. With the properties of encapsulation, abstraction, and polymorphism, object technology systems are moving toward a unified data model that models the real world far more effectively than previous modeling techniques. Furthermore, a properly designed object-oriented model promises to be maintenance-free, because all changes to data attributes and behaviors become a database task—not a programming task. The distinguishing characteristic of the object-oriented database is its ability to store data behavior. At first glance, incorporating data into the database may seem to be a method for moving application code from a program into a database. While it is true that an object-oriented database stores behaviors, these databases must also have the ability to manage many different objects—each with different data items.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

The ISA Relationship As presented earlier in this book, the ISA relationship is a data relationship that indicates a type/subtype data relationship. While traditional E/R modeling deals only with single entities, the ISA approach recognizes that many “types” or classes of an individual entity may exist. In fact, the ISA relationship is the foundation of object-oriented programming, which allows the designer to create hierarchies of related classes and then use inheritance and polymorphism to control which data items will participate in the low-level objects. Oracle is planning to introduce an extension to their Designer/2000 product to allow for the modeling of class hierarchies. This new extension, tentatively dubbed Designer/2001, should allow for object-oriented constructs to be described and modeled.

The ODMG Object Model ODMG is a vendor organization dedicated to providing standards for object-oriented databases. The ODMG object model was developed jointly by a consortium of object-oriented database vendors. These companies feel a sense of urgency to create a unified standard for object-oriented databases, and they have prepared the ODMG model in the hope that all OODB vendors will adopt the model. Current commercial OODB systems are not portable across hardware platforms, and it is hoped that a joint approach toward object-oriented database architecture will create an environment where object-oriented systems share many characteristics, just as relational databases share common interfaces, such as SQL. Because of a lack of standards for object-oriented database architectures, most of the major OODB vendors have been creating commercial products with very diverse internal structures. A recent effort has been made to propose a

standard architecture for object-oriented database systems (Loomis, 1993), and this standard may become the foundation for an industry-wide architecture for object-oriented databases. The ODMG object model was developed jointly by a consortium of object-oriented database vendors, including Versant, Ontos, O2 Technology, Object Design, SunSoft, and Objectivity corporations. Notably absent is Microsoft. While we can only speculate about Microsoft’s failure to participate in these standards, their market dominance may have something to do with their level of participation. The other companies feel a sense of urgency in creating a unified standard for object-oriented databases, and they have prepared the ODMG model in the hope that all OODB vendors will adopt the model. The ODMG model creates an independent model that is language independent, and object models may be bound to many different languages. ODMG develops a hierarchy of objects with the most general object called a denotable object. Denotable objects may be mutable or immutable. A mutable object may change its values and properties, but an immutable object contains only literal values. Within immutable objects, we find two subcategories: atomic and structured (as shown in Figure 18.1). A denotable, immutable, atomic object is represented by the same datatypes found in relational databases, namely char, integer, and float. A denotable, immutable, structured object is a literal structure such as the date and time datatypes.

Figure 18.1 The ODMG object model. Unlike the relational database model, the ODMG model requires that all objects are assigned an object identifier (OID) to uniquely identify each object. While still unclear, it appears that it is not possible to reference an object by the data values in the object. For example, in a relational database, one could state select * from order where order_nbr = 123; this would not be possible under the current ODMG object model. Rather, the ODMG model requires database currency to locate the object, and the system must know the OID. The ODMG model also categorizes objects according to their lifetime within the runtime system. Temporary objects, those associated with a procedure or a process, are classified separately from database objects, which require external storage. The ODMG object model also attempts to redefine the basic principles of entity/relationship modeling, but carries the concept one step further, specifying directionality when navigating the data relationship. This model also specifies navigational operators to traverse the linked-list data structures found in commercial implementations of object-oriented databases.

These operators are remarkably similar to the DML found in other pointer-based models, such as CODASYL, and include verbs such as create, add_member, and traverse. The model also has database operators that help maintain data integrity. These are absolutely identical to the CODASYL network data model and have the verbs begin, commit, abort, and checkpoint. ODMG attempts to recognize the importance of coexistence with relational databases, and the ODMG model is called a superset of the relational database model. The ODMG authors state: An important difference between the relational model and the ODMG object model is that the relational model does not support user-defined subtyping of the type hierarchy. Only built-in types can be used by applications. An object programmer must translate objects into the predefined structures supported by the relational DBMS in order to use the relational DBMS for persistent storage. Only the predefined, table-oriented operations supplied by SQL can be used to access the relational database. By contrast, the ODMG object model provides a way for application semantics to be expressed explicitly in the schema and supported directly by the OODBMS. (Loomis, 1993)

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

The Future Of Hypermedia In Database Management Hypermedia has become a very popular term within the arena of database systems. Many PC-based systems and products advertise themselves as “hypermedia,” but a comparison of these products shows that they have very little in common. In basic terms, hypermedia refers to the ability of the database to incorporate audio and video information. From a database perspective, this audio and video information is simply other sources, or media. Many databases already allow for the inclusion of graphical images, and even mainframe databases allow for Binary Large Object (BLOB) datatypes. The latest craze within PC-based systems is the inclusion of WAV files. These files consist of binary audio information and always have the .WAV suffix, such as HORN.WAV. These files create predetermined sound effects and can be triggered by events within the system. For example, Microsoft Windows uses video-clip files, which allow for the inclusion of moving videos within the database. Many flashy database systems have been created by the addition of audio and video, and Microsoft corporation implements OLE (pronounced Oh-Lay), which refers to their Object Linking and Embedding technology. From a database perspective, these new forms of information are not a problem for the database designer. Sound effects and moving images are stored in the database and retrieved on request, just like conventional information. The problem with hypermedia lies in the effective design and presentation of the hypermedia information. Microsoft’s OLE allows divergent media to be incorporated into a single

application. OLE runs under Microsoft Windows and allows a user to bundle audio, video, and graphics from any source in the Windows domain. Hyper in the phrase hypermedia system refers to the ability of the system to allow links, or calls, to other components within the system that contain ancillary information. These hyperlinks are commonly used within the Windows environment and allow the user of the system to dynamically move to other areas of interest. This concept is analogous to the See also references within encyclopedias. Some text-based databases, such as the Folio database, allow for linking between textual items. The real problem with the development of hypermedia systems is the presentation style of the system. Many vendors create hypermedia shells that allow database designers to add hypertext links to their applications, and it is very simple for a novice to create a system that takes advantage of sound and video. Unfortunately, many of these systems suffer from an artistic overload. Data processing professionals often have trouble with the feel for the dynamics of an effective presentation system, and the delivered products are often “noisy” and distracting. Today, the development of hypermedia systems should be done by professional choreographers who use design techniques more familiar to advertising professionals than computer programmers. This has major implications for the future of database systems design. The tools for the presentation of material are now so sophisticated that anyone can develop a hypermedia system, but not everyone can create an effective user interface. In many areas of database design, a feel for artistic design and graphics presentation will be more important than technical skills.

A Return To Centralized Data As corporations begin to realize that widespread distribution of their data resources can cause severe problems, there will be a movement toward the data warehouse concept (see Figure 18.2). Just as we saw a movement towards centralized data repositories in the 1970s, we are now seeing the same type of movement as a result of the failure of distributed data mechanisms to provide a simple solution to corporate-wide data. This is not a condemnation of the replication tools within Oracle databases but simply a backlash against the inherent complexity involved when distributing data across multiple physical locations.

Figure 18.2 The return to centralized databases. From a data management viewpoint, the same problems that led to the invention of the first commercial databases are now returning. Thirty years ago, the industry was in the age of departmental computing, whereby each area within an organization had its own data processing staff, its own systems, and worst of all, its own data and data structures. This lack of data sharing is now

returning as more departments are abandoning the mainframe and developing their own systems on PC platforms or midrange computers. You should remember that the impetus behind downsizing is primarily monetary. There is no reason to migrate from a mainframe to smaller systems except for the cheaper MIPS available on the smaller machines. Unfortunately, many companies are not only distributing their processing, they are distributing their data, often with disastrous results. As more and more companies learn that distributing their data can cause problems at the corporate level, we will see a move toward the recentralization of data. This doesn’t mean a return to the mainframe as we know it; it means that very large amounts of data will be managed and distributed to all platforms within a company.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Experiential Databases As the cost of computer hardware continues to fall, data processing will undergo another revolution. Just as the first supercomputers went unnoticed by mainstream computer professionals, the new hardware technology will emerge with a whisper. However, the implications toward the way people think about databases will change dramatically. Peripheral sensors have been developed that are far superior to human peripherals, but cognitive development lags far behind. We have cameras that can read a newspaper headline from outer space and ears that can hear far better than our own, but we have never mastered the cognitive ability of even the most primitive animal. Every second, the human mind processes thousands of bits of information. We perceive the distant humming of fluorescent light bulbs, the pressure of our bodies against our chairs, and many other perceptions unnoticed by our conscious mind. Numerous researchers in human cognition hypothesize that the human mind never forgets; what is lost when a memory is forgotten is the ability to recall the data and not the data itself. Oliver Sacks, the famous brain surgeon portrayed in the movie Awakenings, related a story in his fascinating book, The Man Who Mistook His Wife For A Hat. Doctor Sacks was performing brain surgery on a conscious patient when stimulation to a specific area of the brain caused the patient to remember a long forgotten incident. Remembering is not really an appropriate term, because the patient relived the incident and described a scene from her childhood in such detail that she could sing along with a tune playing on the Victrola. When computers advance to the point where storage capacity approaches the capacity of the human mind, there will be a movement toward experiential database machines. Experiential machines will perceive the world around them and process information in a similar fashion to the human mind.

Computers have long been able to learn from experience. Early database experiments in the 1960s demonstrated that a naive computer could learn the rules to simple games by playing the game with another computer. However, human reasoning often differs from computer reasoning—often in very fundamental ways. An excellent example happened during World War II when the allied forces were planning bombing raids on Germany. Attempts at bombing targets in Germany had proved disastrous, with well over one-half of the aircraft lost. A primitive computer was engaged to solve the problem of delivering the maximum bomb load while minimizing the amount of lives lost. The computer was able to prove that less lives would be lost if a smaller number of planes were sent on the missions. Each of these planes would carry double the bomb load and just enough fuel to reach their target. After dropping their bombs, the crew would bail out and take their chances within Axis territory. Assume, for the point of this argument, that the statistical conclusion was correct, and that less lives would be lost if these one-way trips were adopted. The members in the Eighth Air Force were somewhat less than elated with this proposed solution, and elected to ignore the study. The idea of drawing straws for one-way trips to Germany was abhorrent to the crew members, even though they had a much higher probability of survival. Ultimately, the air crews decided to ignore the study, and hundreds of American lives were lost as a direct result of “irrational” human cognition. An experiential system needs to be able to perceive and act upon stimuli in the world. In order to do so, a model would need to be developed that would allow the database to retain information in a similar fashion to the human mind. Sigmund Freud postulated that human memory is persistent. All memories are retained within the brain, but most are inaccessible. These inaccessible, or unconscious, memories and experiences are nonetheless present and serve to guide the decision-making abilities of the human organism. Other psychologists have postulated that the human mind has very little ability to address detailed memory, and the human mind filters out unneeded stimuli, storing only what is required for the organism. This filtering mechanism is activated by priorities set by the conscious mind. For example, a pessimist chooses to ignore positive stimuli and instead focuses on the bad events of the day. Emotional reactions also govern what is stored in the mind. The human mind represses, or blocks, events that are unacceptable to the conscious mind, and would therefore interrupt the functioning of the organism. These types of filtering devices will need to be incorporated into the database memory processors, and a great deal will be learned about the relationship between human and computer cognition.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Previous Table of Contents Next

-----------

Voice Recognition Database Access Recognizing a human voice is one of the first things a baby learns, but it’s a very complex skill for a computer to learn. To create a system with voice recognition, a method needs to be devised that will allow voice access to database managers. Unfortunately, computers have had dismal results when learning to parse and understand human English. It is relatively simple to digitize sound waves for processing by a computer, but it is very difficult to get a computer to partition the sounds into words and to recognize where words begin and end. For example, computers have a hard time recognizing that bus station is two words because the sounds run together when they are spoken. Another problem with voice recognition is context-sensitive grammar. Even a child understands what it means when someone says, “Mary had a little lamb.” A computer, on the other hand, will be unable to resolve the verb had. What do you mean Mary had a little lamb? Did she buy the lamb? Did she eat the lamb? Exactly how did she have this lamb? Determining the context of spoken English has been a difficult, but not insurmountable task. Technology has progressed to the point where computers can isolate individual spoken words and can spell the words according to their context, such as “please write to Mr. Wright, right now.” After the spoken words and their individual meanings have been determined, the next step is to derive the meaning from the sentence. Nonstructured access to databases has long been of interest to researchers, and several products have come to the marketplace. Computer Associates markets a product called Online English, which claims to allow nonstructured queries against their IDMS database product. Other vendors have created tools that allow macros for the classification of database queries. For example, a user could state, “All salesmen who have not sold 3,000 products this month are turkeys.” This

establishes a condition set for the word turkey, and a subsequent query, “Show me the turkeys,” will produce a list of salesmen who have sold less than 3,000 birds. Some of this research deals with the translation of English into foreign languages. A tool was built that translates English into Russian, and a reverse component was designed to translate Russian into English. The individual components worked relatively well when presented with well-structured sentences, but more obtuse sentences produces humorous results. For example, the phrase The spirit is willing but the flesh is weak, was translated into Russian, and then back into English. When the translation was complete, the phrase said, The vodka is good, but the meat is rotten. Savvy, a database query product by Excalibur corporation, performs in the same fashion. For example, an employee database could be queried with the statement, “How long has Joe been with us?” Savvy will respond by stating, “Are you asking for Joe’s date of birth, or Joe’s date of hire?” West publishing company has recently released a tool called Natural, which provides nonstructured queries against its vast legal database. West claims that the researcher only needs to state a general concept, and Natural will create a structured query on behalf of the user, returning the desired information. Query By Example (QBE) is a database retrieval tool by IBM that allows users to query their tables without learning SQL. Users of the DB2 database are presented with a list of database fields that they can combine to create “sample” tables that contain all of the columns and rows they desire. The user could also specify selection constraints. QBE will generate the appropriate SQL for the use and return of their query in a tabular format. Despite the primitive state of today’s technology, the next 30 years will see a revolution in ad hoc database access. Tools will be devised allowing users to state a query to an intelligent front end that will parse the meaning from the statement and return the results.

Summary While this chapter may seem futuristic, many of the topics discussed will soon become commonplace within the world of database management. It remains to be seen how soon the technology will be changing, but if the current trends in hardware technology continue, it will not be uncommon to see desktop computers with enough hardware resources to make artificial intelligence a reality.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.

To access the contents, click the chapter and section titles.

Oracle Databases on the Web Go! Keyword Brief Full Advanced Search Search Tips

(Publisher: The Coriolis Group) Author(s): Robert Papaj and Donald K. Burleson ISBN: 1576100995 Publication Date: 02/01/97

Search this book: Go!

Table of Contents

-----------

Index A Abstract data typing. See ADT. Abstraction, 20, 547 Access privileges types, 346 Adding redundancy issues, 461 Adobe PageMill, 46 ADT, 18, 395 Advanced Research Projects Administration Network. See ARPANET. Amigo, 394 Analysis top-down, 138 traditional systems vs. Web-page systems, 138 API, 5, 36, 160, 389, 402 AppleScript, 153, 154 Applets, 41, 391, 402, 403, 406 Application developers, cardinal rule, 144 front-ends, designing, 137 object-oriented, 26 protocol interfaces. See APIs. standalone, 5 Archie, 5

ARPANET, 1 Array, 539 associative, 307 Audio, 46, 155 Audit script, using, 368

B Basic, 24 Basic Mapping System. See BMS. Behaviors, 396 Berners-Lee, Tim, 7 BIF, 291 Bill-of-Materials explosion, 466 relationships. See BOM relationships. Binary Large Object. See BLOB. Bitmap. See BMP. Black box, 26 BLOB, 551 BMP, 60 BMS, 137 Body procedures, 166 BOM relationships, 466 Bourne shell, 153. See also CGI scripts. Browser display, 127 Built-in functions. See BIF. Burleson, Donald K., 438 Bush, Vannevar, 6

C C, 154 C or C++, 153 C programming languages, 394 C++, 15, 42, 154, 392, 547. See also Languages, object-oriented. vs. Java, 395 Caillian, Robert, 7 Cartesian product, 543 Cartridge, 35 Cattributes, 45 CERN, 7 CGI, 33, 34, 36, 112, 151, 278, 405, 420, 441, 503

components, 152–59 origins, 151–52 programming, common use, 153 languages, 153 programs vs. CGI scripts, 154 scripts, 154, 159, 423 vs. WRB, 159 Character format procedures, 169 Check constraint, 494 Checkboxes, 64, 332 Claris, 46 Class, 396 definition vs. interface definition, 400 Clickable image maps, 135, 152 Client/server, 5, 439 application, 120 architecture, 465 environment, 520 interfaces, 490 paradigm, 120 and parallelism, 497–500 processing, 120 running Java on, 402 Clones access, 122 Cluster, 519 COBOL, 14, 293 CODASYL, 15, 550 Codd, Dr. E. F., 458, 474. See also Rules of normalization. Code reusability, 395 Coherent operating system, 447 Common Gateway Interface. See CGI. Community, 439 Compiled programs vs. interpretive CGI scripts, 154 Computer Associates, 556 Concatenated index guidelines, 495 Concurrency control, 489

management, 378 Connect strings, 443 Connection client-to-server, 11 ConQuest, 118, 547 Constraints, 482 Contention, 386 Context Level DFD, 138 Cookies, 121, 251 definition, 121 expiring, 253 file, 252 Copyright, 137 Corruption, logical, 386 Cost-based optimizer. See Optimizer. Cron, 437 Crontab, 334 Cross-database access, 436 C-shell, 147, 153, 426, 429. See also CGI scripts. Cursors types, 542 Customer ID, 127 Cyberspace domain, 143

D Data flow diagram. See DFD. Data items, 396 Data Manipulation Language. See DML. Data redundancy, 458 Data relationships many-to-many, 465–66, 519 one-to-many, 327, 460–65, 519 recursive, 466–69 types, 457 Data warehouse concept, 552 Database Administration. See DBA. Database Connection Descriptors. See DCD. Database data, 46 deadlock, 382, 385, 386, 490 experiential, 554–56

integrity, maintaining, 387 link, 432, 445, 446 locking, 382 object-oriented, 15 redundancy, 459 relationships. See Data relationships. DB2, 487, 533 DBA, 19, 20, 346, 361, 390, 547 DCD, 104, 405 Deadly embrace, 382 DEC Alpha, 395 Declare section, 292 Denotable objects, 549 Design issues major, 142 Designer 2000, 28, 548 Designer 2001, 28, 548 Developer 2000, 121 DFD, 138, 139, 140 Diagram task-flow, 141 Dictionary update running, 106 Directory list, 178 Dirty reads, 379 Displacement, 526 Distributed data management, 12 Distributed request, 444 Distribution, 485 DML, 15 Domain, 435 Domain name, 9 Domain Name Services, 4 Dynamic page generation, 133

E E/R model, 460, 463, 464, 465, 468, 470, 548 Effective role development guidelines, 358

Efficient SQL general tips, 528–30 Email, 5 Encapsulating code benefits, 362 Encapsulation, 26, 396, 547 vs. SQL, 27 Enquire-Within-Upon-Everything, 7 Entity/Relation model. See E/R model. Environment variables, 154 Error page generic, 323 Error statuses, 321 European Particle Physics Institute, 7 Excalibur Corporation, 557 Executables, 74, 75 Existing process, 449 Explain plan, 530 Explicit cursors, 542

F File Transfer Protocol. See FTP. Focus, 14 Folio, 118, 547 Fonts and different platforms, 122 foreign keys, redundant, 458 Form, 157, 158, 326 procedures, 169 vs. traditional online screen, 326 Fortran, 14, 153, 154 Fragments, 507 Frame, 11, 127, 167, 207 definition, 127 procedures, 167 Freud, Sigmund, 555 FTP, 3, 5 Fulcrum, 118, 547 Full-table scans, 484, 491, 496, 518, 522, 526, 527, 539 Functional partitioning, 436 Functions, 349

G Gallium Arsenide, 15 General Interface Format. See GIF. Generalization, 28 GIF, 59, 60, 135, 337 GMT, 254, 255, 423 Gopher, 5 Gosling, James, 392 Grant privileges, cascading, 350 Graphical user interface. See GUI. GreenOS, 392 Greenwich Mean Time. See GMT. See also Time zones. GUI, 6, 8, 12, 125, 337

H Hash cluster, 517 Hashing, 516–19 Hashing algorithm, 517 Head procedures, 165 Help page, 144 Henrich, Charles, 152 High-speed phonelines, 2 Hint, 461 Holos, 547 Home Locator, 88 format, 79 Home page, 8 Horizontal partitioning, 435, 436 Hostname, 9 and domain name, 9 HotJava, 393 Hotspots, 158 HP-UX, 439 HTML, 7, 9, 11, 46, 155 basics, 46–48 official standards, 38 operations, 120 viewing source code, 64 HTP/HTF Parameters, 171 HTTP, 7, 8, 10, 11, 76, 77, 102, 112

HyperCard, 7 Hyperlinks, 46, 130–32 Hypermedia, 8 future, 551–52 Hypertext, 6 Hypertext Markup Language. See HTML. Hypertext Transfer Protocol. See HTTP.

I IBM’s IMS database, 15 Image, 155 Image map, 67, 157, 174, 213, 223, 337, 402 creation, 190–92 management, 253 Implicit cursor, 542 Indexes. See also Concatenated index. concatenated, 488 and constraints, 493–94 guidelines, 486 multicolumn, 494 and Oracle performance, 496 tuning queries, 486–88 Inheritance, 21, 22, 395, 396 multiple, 21 Installation process, 72 Installer prompts, 78 Intel 486, 395 Interface definition vs. class definition, 400 Interfaces, 400 Internet, 1, 504 address, 3 applications, 2, 5 communication protocols, 2 components, 2 cost of connecting, 2 physical network, 2 vs. World Wide Web, 6 Internet Explorer, 71, 120 Internet Network Information Center. See InterNIC. Internet Protocol. See IP.

Internet-based online systems, 12 future, 12 InterNIC, 4 Interscreen travel methods, 336 Intersystem connectivity, 436 Intranets, 8 Invoke, 375 IP, 3, 433, 442, 443 ISA relationship, 29, 548

J Java, 34, 41, 112, 118, 391–92, 542, 543 benefits of using, 42 creating dynamic HTML documents, 415 development, 392–93 error messages, 411 HTML examples, 416–19 object-orientation, 395–97 performance, 398 portability, 393–95 security, 397 vs. C++, 42, 395 vs. PL/SQL, 404 wrapper, 412 Java Cartridge, 33 Java Code fundamentals, 398–401 Java Interpreter, 41, 43, 401, 402, 404, 405 Java Virtual Machine, 393–94, 403 Java Web Toolkit, 43, 404, 405 JavaScript, 404 JDK, 411 Joint Photographic Experts Group. See JPEG. JPEG, 59, 60, 135, 337

K Kimball, Dr. Ralph, 468 Korn shell, 153, 334, 372. See also CGI scripts.

L

Languages declarative, 526 object-oriented, 13, 23, 24, 25, 36, 45, 301, 302, 541 procedural, 291, 541 LAN, 11 LaTeX, 11 Link, 46, 376 references, 59 Linux, 394 List procedures, 168 Listener commands, 449 processes, 112, 452 LiveHTML, 34, 118, 419–29 cartridge, 33, 43 examples, 423–29 Interpreter, 401, 420 similarity to SGML, 421 syntax, 421–23 Local area networks. See LAN. Local mode, 382 Location transparency, 4, 432, 446 Lock chain, 385 Lock escalation, 384 Lock pool resources, 386 Locking, 489 solution, 379 Locks exclusive, 381 shared, 381 table-level, 385 Logging features, 145 Logical volume manager. See LVM. LVM, 520, 521

M MacOS, 394 Mailto protocol, 222 Managing Distributed Databases, 438 MAP files, formatting, 158 Massively parallel processors. See MPP.

Master lookup table, 438 McCool, Rob, 152 Memory fencing. See Pinning. Message, 25 MetaCube, 547 Method, 396 coexistence, 381 Microsoft, 549 Access, 14 Internet Explorer, 11, 64 Visual Basic, 14 Windows, 6, 468, 551 and design issues, 124 MIME, 155, 278 types, 156 Mode conversational, 378, 382 pseudo-conversational, 378, 382 Model object-oriented, 16 Morphology, 547 Mosaic, 393 MPP, 500 MS Query, 373 MTS, 439, 440, 449, 450, 451 starting rules of thumb, 451 Multiprocessing, 497 Multipurpose Internet Mail Extension. See MIME. Multitasking, 497 Multithreaded server. See MTS. Multithreading, 497

N Names facility, 446 National Center for Supercomputing Applications. See NCSA. National Language Support. See NLS. National Science Foundation, 2 Natural, 557 Natural language, 547 Navigation pathway complexity, 142

NCSA, 152 HTTPd, 36 Nelson, Ted, 6 Netscape, 11, 54, 64, 71, 94, 101, 120, 122, 124, 129, 135, 152, 251, 393 communications server, 36 and frames, 128 Network Computers and Java technology, 402 Network host, 11 Network Programmatic Interface. See NPI. NeXT, 7 NFSNET, 1 NIC, 4 NLS, 81, 89 Nobody, 86, 161 NPI, 441

O O2 technology, 549 Object administrator functions, 20 consolidator, 546 Data Management Group. See ODMG. Design, 549 identifier. See OID. Linking and Embedding. See OLE. Management Group. See OMG. privileges, 348 Request Broker. See ORB. technology, 12 Object-oriented approach, 547 database standard architecture, 549 databases, 545 languages. See Languages, object-oriented. paradigm, 22 programming. See OOP. Objects aggregate, 19 and behaviors, associations, 17

ODMG, 18 ODMG Object Model, 548–51 OFA, 78 OID, 549 OLAP, 471 OLE, 551, 552 OMG, 18 Online English, 556 systems design, 138 video clips. See VID files. Ontos, 549 OODB, 548 OOP, 396 Open systems, 344 OPI, 441 OPS$, 446, 451 Optimal Flexible Architecture. See OFA. Optimizer cost-based, 458, 485, 491, 496, 521, 525, 537, 538, 539–40 rule-based, 458, 485, 496, 525, 526, 528, 535–39, 540 rule-based vs. cost-based, 539 Oracle7 database products, 72 Oracle8, 18, 19, 20, 27, 545–548 object layer, 18 Oracle bulletin #105025.433, 350 ConText, 546 database, 338 DBA, 297 Express, 547 and printing or downloading, 118 Programmatic Interface. See OPI. Sedona, 546 System ID. See SID. System Identifier, 73 table, 288 Web Administrative Server. See OWAS. Web Agent. See OWA. See also PL/SQL Agent.

Web Agent DBA. See OWA_DBA. Web Listener. See OWL. Oracle Magazine’s home page, 64 Oracle RDBMS Database Administrator’s Guide, 537 Oracle WebServer, 133 3.0, log server, 148 installation, 76 Installer, 74–76 uninstalling, 76, 85 Oraperl, 153, 154. See also CGI scripts. orasrv, 440. See also SQL*Net, listener process. ORB, 546 OS/2, 394, 497 Overloading, 24 OWA, 34, 77, 159, 338, 404 OWAS, 77, 100, 102 OWA_DBA, 95, 96, 97, 99, 104, 105 OWL, 33, 77, 85, 100, 155, 160, 403, 404, 504

P Package, 298, 349, 506, 508 wrapper, 406 Packets, 3 Pages framing, 174 levels, 142 Parallel query, 519–22 using, 500–502 Parallelism, 498, 499, 522. See also Client/server, parallelism. Partitioning, 180, 499, 520 Pattern, 268 Pellow, Nick, 7 People costs vs. CPU costs, 13 Perl, 112, 153, 154, 542, 543. See also CGI scripts. Persistence, 160 Personal Function,130, 131 Physical format procedures, 169 Pictures, 46 PID, 450 Pinging, 94, 100 Pinning, 507

automatic, 509 measuring packages, 509 PL/SQL, 41, 112, 134, 160, 291, 397, 412 problems, 299, 542 syntax structures, 292 tuning, 299–301, 541–44 PL/SQL Agent, 34, 36, 37, 159, 401, 403, 405, 504 Developer’s Toolkit, 107 packages, 408 procedure, 112, 114, 154 role, 38 stored procedure, 37 vs. Java Interpreter, 41 vs. Java Interpreter, 41 PL/SQL User’s Guide and Reference, 324 PL/SQL Web Toolkit and Java Web Toolkit, 404 Plain text, 155 Point-to-point lines, 2 Polymorphism, 23, 24, 25, 395, 547 Pop-up list, 63, 333 PowerBuilder, 118, 119, 126 Preemptive locks. See Locks, exclusive. Pre-spawned shadow. See Existing process. “Primacy of the user” principle, 145 Print procedures, 165 Prism, 497 Privileges combining, 350 object vs. system, 347 Pro*C, 450 Procedural Language/Structured Query Language. See PL/SQL. Procedures and packages problem, 349 Process ID. See PID. Processing improving speeds, 478 pseudo-conversational, 144 SMP vs. MPP, 500 Programming

object-oriented, 15 profession, 15 Protocols, 2 application, 3 levels, 3 network, 3 transport, 3 Providing OLAP (Online Analytical Processing) to User-Analysts: An IT Mandate, 458 Public synonym, creating, 109

Q Query By Example, 557 See QBE.

R Radio buttons, 63, 333 RAID, 520, 521 Referential Integrity. See RI. Remote client, speed, 121 connection, 444 request, 444 Requests servicing, 112 Results non-reproducible, 382 RI, 482, 483, 486, 494 Roles, 345, 352, 355 creating, 361 Ronco, 23 Router, 11 Row information updating, 339–44 Rows phantom, 382 RTF, 11 Rule-based optimizer. See Optimizer, rule-based. Rules of normalization, 458, 474

S Sacks, Oliver, 554

Sanders, Tony, 152 Sargeable predicate, 486, 489 SAS, 14 Savvy, 557 Screen layout creation, 137 Screen transfer vs. hyperlinks, 130 Screen moving in WebServer, 376 transfer, 375 SDK, 125 Security, 344 achieving simplicity, 365 checks, 345 data-specific vs. application-specific, 361–63 in remote database, 355 starting guidelines, 373–74 stored procedure vs. role-based, 349 two methods for managing, 346 Selectivity, 485 Sequential pre-fetch, 487 Server Side Includes. See SSI. See also LiveHTML. ServerManager, 281 Service lines, 2 Service names, 443 SGA, 298, 506, 507, 509, 512 SGML, 11, 47, 420 Short On Storage. See SOS. SID, 407, 439, 442 Slow image display, problems, 120 SmallTalk, 15, 547. See also Languages, object-oriented. SMP, 500, 521 Snapshots, 474–82 complete refresh, 475 creating, 475 fast refresh, 475 Software Asset Manager, 83–84, 91 Solaris, 394 space required, 74 Solaris Unix, 439 SOS, 381

Spawned, 450 SQL, 15, 20, 27 SQL cursors types, 299 SQL*DBA, 281 SQL*Forms, 118, 119, 121, 126, 130, 299, 312, 319, 327, 337, 341, 450, 483, 541 SQL*Net, 432, 436, 438–50, 478, 501, 505 1.0 vs. 2.0, 440 connection error message, 445 connections to remote databases, 443 connections types, 456 listener process, 447 ways to establish database communications, 444 SQL*Net Sessions viewing, 454–56 SQL*Plus, 27, 281, 354, 373, 445, 447, 454, 513 SSI, 43, 402, 420 Standard Generalized Markup Language. See SGML. Star schema design, 465–468 State, 396 Stored procedure, 297, 349, 356, 357, 377, 435, 441, 505, 508, 512 access, testing, 110 benefits, 505 Striping, 521 Structure procedures, 165 Structured Query Language. See SQL. Sun Microsystems, 392 SunSoft, 549 Symmetrical multiprocessing. See SMP. Synonyms, 353–54 System Global Area. See SGA. System privileges, 346, 347 Systems analysis purpose, 140 Systems design process purpose, 141

T Table, 129 HTML vs. Oracle, 243

partial replication, 481 privileges, 346 procedures, 170 replication, 436, 474 Table-level security, 356 replacing, 360 Tags, 47 Target string, 256 Task-flow diagram, 141 TCL, 153, 154. See also CGI scripts. TCP, 3 TCP/IP, 3, 101, 439, 443 Technical support, 115 Telnet, 5 Temporary tables using, 534–35 Text, 46 alignment, 124 highlighting, 235 Thrashing, 506 TIFF, 60 Time zones, 255 Time-Warner, 393 TNS, 433, 435 TNS listener, 440 tnslsnr, 440. See also SQL*Net, listener process. Trace facility, 533 Tracking error messages, 146 Tranparent network substrate. See TNS. Transaction freezing, 144 global, 432 Transfer, 376 Transmission Control Protocol. See TCP. Triggers, 297, 350, 481, 505, 515 vs. stored procedures, 516 when to use, 516 2PC, 389, 453–54 Two-phase commit. See 2PC.

U

UDP, 3 Uniform Resource Locator. See URL. Universal object manager, 546 Unix, 5, 424 documentation screen, 83 Updatable snapshots, 474 Update procedure, 303 UPI, 440, 441 URL, 8, 59, 85, 112, 280 components, 9 format, 9 User Datagram Protocol. See UDP. User Programmatic Interface. See UPI.

V Versant, 549 Vertical partition, 432, 436 VID files, 120 Video, 46, 155 Views, 357 Virtual reality environments. See VRML. Visual Basic, 153 Voice Recognition Database Access, 556–57 VRML, 120

W WAIS, 3, 5 WAN, 1, 2 Web listener, 32, 33, 34, 35, 190 Web page constructs, 46 definition, 46 vs. SQL*Form or PowerBuilder, 126, 319 Web Request Broker. See WRB. Web technology, 8 Web Transaction Manager, 43–44 WebMaster, 161 WebServer, 29, 38–39, 312 3.0, 121 Administrative Server, default port, 92 applications, 118–19

basic components, 33 configuring WebServer 1, 94–100 configuring WebServer 2, 100–05 differences between versions 1 and 2, 34 installing WebServer 1, 76–85 installing WebServer 2, 85–93 primary purpose, 32 real benefit, 41 using, 71 West Publishing Company, 557 Whitney, Eli, 13 Wide-Area Information Servers. See WAIS. Wide-area network. See WAN. Widgets, 125, 126 Wildcards, extensions, 257 Windows, 394 Windows NT, 497 Windows Standard Development Kit. See SDK. Wizards, 15 World Wide Web, 6, 12 elements, 8 origin, 7 principles, 7 Wrappers, 405 WRB, 33, 34, 36, 85, 112, 151, 159, 160, 278, 378, 401, 402, 403, 404, 405, 420, 441, 448, 503, 504 executable engine. See WRBX. services, 86 vs. CGI, 35, 112, 161 WRBX, 36, 85 WWW, 5

Z Zone names, 9

Table of Contents

Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.