Oracle

SQL and PL/SQL

Development and Maintenance
Concepts
EXECUTIVE SUMMARY---------------------------------------------------------------------------------- 1

BEST PRACTICES FOR PL/SQL PROGRAMMING---------------------------------------------- 2

Why PL/SQL and server-side code ------------------------------------------------------------------ 2

PL/SQL programming standards--------------------------------------------------------------------- 3

PL/SQL Integrated Development Environment (IDE) ------------------------------------------ 4

Supporting the Development Life cycle ------------------------------------------------------------ 4

CHANGE MANAGEMENT FOR DATABASE OBJECTS---------------------------------------- 9

Overview------------------------------------------------------------------------------------------------------ 9

Current Methods ------------------------------------------------------------------------------------------- 9

Required Automated Solutions ----------------------------------------------------------------------- 9

Access to Database Objects -------------------------------------------------------------------------- 9
Source Code Repository ------------------------------------------------------------------------------10
Object Granularity and Version Control -----------------------------------------------------------10
Deployment -----------------------------------------------------------------------------------------------11
Dependency Analysis ----------------------------------------------------------------------------------12
Security ----------------------------------------------------------------------------------------------------13

APPLICATION PERFORMANCE IMPROVEMENT — PROACTIVE SQL TUNING-----13

Coding SQL Statements in Oracle With Performance in Mind ----------------------------13

How to Evaluate the Performance of SQL and How to Improve It -----------------------14

Maintain the Performance in Production ---------------------------------------------------------16

UTILIZING COMPUTER ASSOCIATES’ UNICENTER® SQL-STATION® FOR PL/SQL

BEST PRACTICES----------------------------------------------------------------------------------------18

Synopsis-----------------------------------------------------------------------------------------------------18

History--------------------------------------------------------------------------------------------------------18

Best Practices for PL/SQL Programming --------------------------------------------------------18

Change Management for Database Objects -----------------------------------------------------19

Application Performance Improvement-----------------------------------------------------------19

Conclusion--------------------------------------------------------------------------------------------------20

SQL Development Guidelines White Paper

Executive Summary
Database programming has recently become more of a distinct discipline among other
types of programming. Within this distinct discipline, Oracle — the predominant
database server — has specific programming considerations, such as a dedicated
programming language —PL/SQL, significant control over the optimization process and
more. In Oracle shops, an increasing number of developers, traditionally isolated from
database specifics, have been exposed to database programming — as a result IS
management feels the need for establishing programming standards and guidelines.
In this paper we discuss the need for a set of programming guidelines for Oracle and
suggest a framework for creating a customized, specific standard within organizations.
We chose to address elements that are unique to database programming, and refrained
from discussing usage of Rapid Application Development tools with databases. This
white paper focus on server-side programming and PL/SQL because we believe that
these techniques are usually omitted or ignored in the corporate standards. It is also our
strong recommendation that these techniques should be promoted throughout the
enterprise for improving both the quality and the performance of applications.
The other two topics which are covered in detail are change management of database
objects and proactive tuning of SQL statements. Change management is a key element
in any application development process, and we find it relatively immature in database
objects and database programming. Performance is a major concern with any
client/server application, but not enough is done in the development stages to ensure
the best results upon release to production. Our experience proves that proactive SQL
tuning during early development stages is extremely effective in generating applications
with good overall performance.

A n a ly s is a n d de s ig n D e v e lo p m e n t D ep lo ym e n t

M od elin g

C od ing

T estin g an d D ebu g ging

L o gical T u nin g
M od el M ain ten ance, C han ge M an agem ent

S e rver-side log ic
P h y sical (P L /S Q L )
M od el
E m b edd ed S Q L

Figure 1 — Database related activities in the development life cycle.

Unfortunately, the state of tools for SQL tuning and PL/SQL development lags behind
more popular programming environments, with Oracle Corporation traditionally focused
more on applications and less on development tools. We provide our vision of the ideal
SQL Development Guidelines 1 White Paper
development tools required to implement our recommendations, and take a closer look
at the Unicenter SQL-Station suite.
We do not cover the topic of logical and physical database design since they are closer
to the analysis and design stages of application development than to the actual
implementation stages.

Best Practices for PL/SQL Programming

Why PL/SQL and Server-Side Code

Oracle programming and PL/SQL have become inseparable. All the implementation of
business rules in Oracle (stored procedures and database triggers) is programmed in
PL/SQL. Furthermore, PL/SQL is the language of preference in Oracle client-side
application development tools, and PL/SQL is also internally used in Oracle’s
development process. Oracle Corporation seems to further develop and stand behind
PL/SQL in the new releases of Oracle, and it is clear that PL/SQL is here to stay as the
language of preference for writing Oracle database and application logic.
PL/SQL is a powerful extension of Oracle’s SQL and is tightly integrated with it. PL/SQL
empowers database programmers with a rich set of language constructs, enabling them
to deliver better multi-platform Oracle database applications more quickly.
Server-side code is a generic name for those objects of code that execute on the
database server, such as stored procedures, database triggers and functions. The name
differentiates these objects from client-side code, which includes objects of code that
execute on the client, and within this context, on the application server. The ability to
execute code within the confines of the database server is not a new concept, as it has
been around since database triggers were first supported. The value of server-side code
is also well established and acknowledged — offering significantly less network traffic,
improved performance, easier central maintenance, reusability and portability of code.
Surprisingly though, server-side code has had a slow adoption rate, much slower than
expected based on the analysis of its benefits.
Developing server-side code in Oracle requires writing programs in PL/SQL. PL/SQL is
very rich in features and supports numerous advanced programming techniques,
including basic concepts of object-oriented programming. So why is there a slow
adoption rate? One of the key bottlenecks is the learning curve: feature rich usually
means difficult to learn. The other major reason lies in the lack of modern development
tools for PL/SQL.
To summarize, server-side code is undoubtedly highly recommended in client/server
applications. In Oracle 7 and 8, server-side code is written in PL/SQL, a language
different from most other languages, being a hybrid between a procedural language and
SQL. The challenge that developers face is becoming proficient with PL/SQL and server-
side programming techniques, while writing code that is both fast and easy to maintain
and modify. This section will attempt to shed some light on solutions and approaches to
this challenge.
Naturally, the first steps for producing effective code start with proper logical and
physical database design. The scope of the current paper does not include those
stages, although we do feel that there are significant benefits from ER modeling tools
that assist in visualizing and manipulating object relationships.

SQL Development Guidelines 2 White Paper

PL/SQL Programming Standards
The challenges of coding in PL/SQL start with the very basics: thorough knowledge of
the language and its constructs. PL/SQL is by no means a lean language, nor is it as
simple as C. It is packed with features and options and therefore not easily mastered. As
if this was not enough of a challenge, the typical PL/SQL programmer does not spend all
of his/her time with PL/SQL. Usually, PL/SQL is just an additional programming
language, used in conjunction with the client-side development language(s) — either
Visual C++, Visual Basic, PowerScript or Java. One of the drawbacks of PL/SQL’s
complexity is the fact that programmers tend to use only basic constructs and primitive
features of the language. Most developers never get the chance to learn the more
advanced features.
The solutions to these challenges are a combination of good training practices, solid
programming standards and excellent development tools.

Training
Training is essential. Any organization planning to develop in Oracle’s PL/SQL must
have a good training program. PL/SQL is not self-explanatory or intuitive enough to let
programmers pick it up as they go — the consequences will be illiteracy in PL/SQL, a
20% – 40% utilization of the power of the language and poorly written code.

Programming Standards
Programming standards are as important as good training procedures. Creating and
enforcing coding standards with PL/SQL, as with any other programming language, will
ensure higher quality code that is easier to read, understand, maintain and reuse. The
set of standards suitable to a specific organization should include a mix of existing
coding practices, advice from experienced PL/SQL developers, good programming
practices recommended by industry-experts in PL/SQL and a library of existing and
reusable, best-in-class PL/SQL code objects gathered from throughout the organization.
The list of topics in the set of PL/SQL programming standards should include:
• Modularization and structured programming rules of thumb.
• Guidelines for using packages and persistent data.
• Documentation guidelines—location in the module, mandatory contents, style and so
on.
• Coding style and indentation rules.
• Upper/lower case usage rules.
• Naming conventions — for objects, variables, arguments, exceptions, constants and
so on.
• Variable naming, typing and declaration formatting rules (and do not forget to
discuss anchored data types).
• Coding SQL statements within PL/SQL.
• Templates and coding rules for all the recommended control structures (cursors, if
statements, loops and so on).

SQL Development Guidelines 3 White Paper

• Exception handling guidelines.
• Numerous coding examples using advanced recommended techniques.
• Short list of the most useful Oracle provided functions and packages.
• List of useful local packages, stored procedures and functions.
• Testing guidelines.

PL/SQL Integrated Development Environment (IDE)

Promoting server-side code and publishing best practice programming standards are
important, but without adequate automated support for the actual implementation we
cannot expect to produce the high-quality, centralized, reusable, easy-to-maintain code
we have envisioned above. Today’s application developers use high-productivity
integrated development environments that assist them from end-to-end in the
development life cycle: syntax highlighted code editors, wizards for code generation,
context sensitive help, coding samples and templates, change management, testing and
debugging features. If we expect server-side database developers to be excited and
productive when developing in PL/SQL, we must provide them with equally valuable
tools.
Unfortunately, the state of tools for PL/SQL development lags behind more popular
client-side programming environments. Independent vendors, however, have seen the
value of tools for PL/SQL — after compiling your own checklist/wish list of features, go
hunt for the best!

Supporting the Development Life Cycle

The ideal PL/SQL IDE should support the whole development life cycle: coding, editing,
compiling, testing, debugging, tuning, deploying to production and maintenance — the
whole process iterating continuously throughout the life span of the application. None of
the stages enumerated is new or unfamiliar in software engineering, so when defining
specific required features for each stage we are on solid ground. Anybody that has spent
enough time in the software industry has probably acquired a good understanding of the
requirements for a robust editor for programmers, from the need to support change
management and team development, to the ability to iteratively test and debug code.
However, some stages of the development process are special to PL/SQL development
and are addressed in the following paragraphs.

Development Tool Objectives

To reiterate our objectives, we would like to see an IDE that includes best-of-breed
components in the major functional areas, such as editor, debugger and excellent
support for database programming, with all the functionality delivered in a common,
integrated framework.

SQL Development Guidelines 4 White Paper

Navigating database catalogs

Figure 2 — Exploring the database catalog (Unicenter® SQL-Station® Catalog Browser)

Dealing with database programming has some of its own specific requirements, and these should
not be ignored when evaluating tools. The ideal IDE should allow the developer to navigate the
database catalog, as the equivalent of the file system in conventional client-side environments,
and preferably support simultaneous access to multiple database servers in your distributed
environment. A developer should have access to catalog objects on the development environment
(test), but also to the production environment — especially in maintenance tasks as well as the file

SQL Development Guidelines 5 White Paper

system to search for items they may need. And needless to mention, the security of the RDBMS
should be unaffected.

Accessing Object Information in the Catalog

Oracle’s catalog, in conjunction with server-side code, is a powerful source of information that can
be exploited by the IDE. Object interdependencies can be clearly visualized; table and column
names, procedures and functions, and prototypes can be placed at the programmer’s fingertips
while coding; and the usual catalog information (such as table definition, columns and data types,
referential integrity constraints) can be made available. All this information needs to be available
both online and in hard copy, with easy to generate and utilize reports.

Interactive Access to Data

Access to live database data is another important requirement. Developers need easy
and fast access to the database to view values, make modifications and maybe populate
small test tables with data. The developer should be able to code and execute queries
against real data and view the results in an easy-to-use GUI.

Figure 3 — Query execution with friendly GUI and results display (Unicenter SQL-Station)

SQL Development Guidelines 6 White Paper

Editing
When the editor is evaluated, SQL Plus cannot pass the test — a real interactive editor
for programmers is needed. Developers are used to syntax highlighting, enhanced
search and replace, working with blocks of code, formatting and so on. Most advanced
PL/SQL programmers use one of the industry standards in editing (Windows, VI,
EMACS, Brief), but they need one that is integrated with the other features described
here.

PL/SQL Coding Assistance

With the complexity of PL/SQL, developers need much more assistance in the
programming process than with other more popular languages. You can easily expect a
programmer to remember the C syntax, but the syntax of complex constructs in PL/SQL
should be easily accessible in our ideal PL/SQL IDE, maybe even automatically pasted
into the editor. Syntax checking should be a breeze, with easy identification of
statements in error and quick access to detailed error messages from the Help system

Debugging
When evaluating debugging facilities, using printf (or the PL/SQL equivalent—the
DBMS_OUTPUT package) should not be regarded as a feasible solution. Programming
tools in the 1990s allow developers to step through statements while debugging, set
breakpoints, view and modify variable values, automatically detect dependencies and so
on. Debugging can take as much as a third of the development phase; so expediting the
debugging process has a significant impact on application delivery, not to mention
quality.

SQL Development Guidelines 7 White Paper

Figure 4 — Stepping through the code in debug mode (Unicenter® SQL-Station®
Debugger for Oracle)

Change Management and Version Control

Robust version control and configuration management is critical in a complex

development environment, which includes multi-tier applications accessing
heterogeneous databases and staged deployment of database server-side code from
development through test to production. The ability to check code objects in and out is
also critical to support team development and reuse.

Tuning
Performance problems in client/server applications are usually related to database
access and un-tuned SQL. The need to tune SQL statements is a facet of SQL
programming that is unique to database programming and not familiar in other
development environments. Therefore, a complete chapter is dedicated to this topic, so
essential to the success of client/server applications.

SQL Development Guidelines 8 White Paper

Change Management for Database Objects

Overview
Database objects, including both data objects (tables, indexes and views) and code
objects (stored procedures and triggers) are an important element of a complete
client/server application. Very much like other application elements, these objects need
to be managed and controlled, and should follow the same rules of change and
configuration management as the rest of the application.
Traditional source control and configuration management tools do not address database
objects well. This section will present the major challenges related to managing and
controlling database objects, and suggests desired functions from an ideal software
package.

Current Methods
The source control tools normally available to DBAs and project managers are limited
and rudimentary. They do not follow familiar version control metaphors, nor do they take
advantage of information or supporting data available from the RDBMS itself, such as
the catalog.
Usually, DBAs will combine DDL commands for creating tables and indexes into long
and difficult to manage scripts. This can create significant difficulties, including the
following:
• Dependencies are difficult to manage.
• Minor changes in scripts can impact the whole database.
• Object codes (especially stored procedures) are not integrated in the scripts.
• After a change is performed, it is difficult to revert to a previous working version.
• Deploying from various test and deployment environments can prove extremely hard
to manage.

Required Automated Solutions

Automated tools should address the pains stated above, and facilitate a manageable
and controllable environment in the area of database objects. Following are some details
regarding the features we would like to find in an ideal tool.

Access to Database Objects

Database objects reside in the catalog on the database server. These objects are not
readily accessible to developers — making them different than program source files
residing on the file system. Easy access to objects is a key requirement, especially in
team development environments, where code sharing and reusability play such an
important role.
Automation in this area should imitate tools available in web and client/server
environments, with additional support for operating on the database server. An ideal tool
should provide the same access options and metaphors that are available with tools

SQL Development Guidelines 9 White Paper

outside the database — developers use File Manager or Explorer to access objects in
the file system, they should have similar navigation tools for the database catalogs. In
distributed environments, multiple databases and heterogeneous database types should
all be accessible from the same development environment, at the same time.

Source Code Repository

Another characteristic of team development is the importance of change management,
reliability and availability of the data. Normally, applications and their related database
objects are developed in a test environment and later deployed into one or more
production environments.

Figure 5 — Source Code Repository Integrated in Development Environment

(Unicenter® SQL-Station® Code Manager for Oracle)

In an ideal world, all the application entities should be centrally managed and controlled
in a repository to ensure proper control, quality and reliability. On top of the repository,
additional procedures, standards and supporting software tools will enable proper
sharing and reusability of code, enforcement of security, version control, definition of
fixes, releases and versions.

Object Granularity and Version Control

Database objects should be managed and controlled similarly to other application
entities such as programs, forms and so on. Maintaining a complete database definition

SQL Development Guidelines 10 White Paper

in one long script that contains all the DDL for the tables, indexes, constraints and so on,
is far from a satisfactory solution. In a modern development environment, each entity in
the database should be controlled and versioned separately.

Figure 6 — Decompose a script and import as separate objects (Unicenter®

SQL-Station® Code Manager for Oracle)
Imagine a relatively minor patch to a production system that entails change in a constraint for a field
and some logic modification in a trigger. Without version control at the object level, what are the
options? Making a change in the script that defines the whole database would likely be too time and
resource intensive. In a more likely scenario, a developer will pull out the code for the constraint and
the trigger, perform the changes “by hand,” hopefully test and deploy the changes, and then modify
the “big” script to maintain consistency. The application development world has dealt with the
potential risks and chaos that such a process can create by turning to change management tools,
but this is still common practice in the database world today.
In a quality-aware development environment, we would like to be able to define a change to the
production system that affects only several entities, is completely reversible, and can be automatically
deployed to the production environment. The assigned developers will checkout the affected entities,
so that nobody else can modify them at the same time. They will modify the code, use testing and
debugging features available in the integrated development environment, and then check the entities
back in. In this scenario, if something goes wrong, the previous version or versions are still available
in a repository so that the change can be reverted. Moreover, a revision history of each object should
be available, with a timestamp and proper documentation of the modification. Another necessary
feature for this vision to become a reality is a compare facility that will highlight the differences
between any two revisions. And to complete the process, the whole change will be packaged in a
named and documented change-unit or project entity, so that either rollback (For example, reverting
to the previous version) or commit (For example, deployment to production) can be performed in one
logical unit of work.

Deployment
Once development and testing of the application/enhancements or fixes are completed,
the deployment of the new entities should be automatic and self-contained. The first step
in deployment is defining the deployment unit. The deployment unit is a project or sub-

SQL Development Guidelines 11 White Paper

project that is self-contained. A project can consist of one item (such as a table or a
stored procedure), or numerous items related to a change (such as a combination of modified
tables, triggers, packages and so on). In the project definition the project manager should be able
to define the items belonging to it, document the purpose of the package and identify deployment
targets. The deployment target concept is important, because tens or hundreds of servers may
host multiple applications in a distributed environment, and our starting point is a single central
repository. We would like to be able to define the deployment target as a generic group of
database servers, such as “the help-desk servers” or the “sales servers.” Then, by clicking on a
“Deploy” button an automated deployment mechanism is triggered that deploys the objects to one
or more servers.

Figure 7— Automatic Deployment (Unicenter® SQL-Station® Code Manager for Oracle)

Dependency Analysis
Unlike the application world, database objects usually have complex inter-relationships,
imposing a certain order in the deployment process. For example, a table referring to
another table (such as foreign key) cannot be defined before the other table is defined.
The dependency analysis can prove to be tricky and time-consuming, therefore
automatic dependency analysis is very useful in the deployment process to ensure
successful object deployment in the correct order.

SQL Development Guidelines 12 White Paper

Security
Modifying and deploying to production systems is very sensitive, hence the need to
enforce strict security. Channeling deployment to a single process facilitates much better
control and security enforcement.

Application Performance Improvement — Proactive SQL Tuning

It is estimated that 60 – 80% of performance problems in client/server applications are
associated with SQL that has not been properly tuned. As an obvious conclusion, the
most effective method for ensuring well-performing applications is tuning the SQL.
As a best practice, we strongly feel that the task of tuning SQL statements needs to be
one of the mandatory steps in product development, to be performed well in advance of
application deployment. Tuning SQL in Oracle is a difficult, tedious task that requires
extensive experience and expertise. The reason for this is the wealth of options available
to programmers in affecting Oracle’s optimization plans: selecting optimization modes,
using different SQL coding techniques for obtaining equivalent results and an ever
increasing selection of optimization hints.

Coding SQL Statements in Oracle With Performance in Mind

Writing optimized SQL is difficult and non-intuitive. SQL was designed so that users
could easily obtain information from the RDBMS based on their knowledge of the data.
The underlying implementation is generally unknown or ignored by users, as they are
primarily concerned with getting the correct information from the database, not with the
existence of indexes or alternate access paths.
The first rule in establishing best practices for server-side code is therefore awareness
of performance and optimization plans. Even if the application seems to function as
expected and the project is behind schedule, never bypass checking the SQL for
performance! SQL reviews should be an integral part of the overall application review
process, supported by a well-documented set of coding rules and the presence of a
senior DBA and appropriate supporting tools.
Following is a sample questionnaire to be used during the SQL review process. This is
by no means a complete list, but can serve as a starting point in compiling such a
comprehensive list:
• Parse phase is/should be combined with execute phase? (If statement is executed
multiple times, it’s preferable to separate and assume that most executions will use
the already parsed statement from the SGA. If statement cannot be shared, it’s
preferable to defer the parse and minimize network traffic.)
• Execute phase is/should be combined with Fetch phase?
• Is Describe used for static SQL? (Should never be used except for dynamic SQL.)
• Dynamic SQL? Ensure that it cannot be avoided.
• Statement uses bind variables? (Bind variables are usually preferable, since they
allow for sharing — whenever a constant is used, the memory kept for that statement
cannot be shared. On the other hand, sometimes using constants changes the
optimization plan, based on index statistics available to the optimizer.)

SQL Development Guidelines 13 White Paper

• Statement uses standard coding conventions and optimization mode? Any
differences, such as capitalization, prevent cursors from being shared.
• Update statements use array binding? (Array binding significantly reduces network
traffic.)
• Is the size for array fetching optimal?
• Statement contains correlated sub query? If so, consider using nested select, usually
a better performer for batch applications.
• Statement uses HAVING clause? Consider replacing with WHERE clause if
possible. (HAVING filters only after all the rows have been retrieved.)
• Statements use NOT IN? Consider replacing with NOT EXISTS.
• Statement uses EXISTS? Consider replacing with joins.
• Statement uses DISTINCT? Consider replacing with EXISTS.
• Any function applied on WHERE column that is indexed? Try to avoid, since it will
cause full table scan.
• Avoid using NOT on indexed columns (prevents usage of the index by the optimizer).
• Statement uses ORDER BY? Check if the column is indexed and replace with
WHERE clause.
• Statement/cursor likely to be used by other modules? Consider creating server-side
object (package, stored procedure) to improve performance and facilitate reusability.

How to Evaluate the Performance of SQL and How to Improve it

The next major step beyond following the rules of thumb mentioned above goes deeper
into Oracle optimization plans and their understanding. The Oracle optimizer can
generate Explain plans for each statement — those plans describe the exact operations
performed by the optimizer to complete the statement.

Select from
Capture on Repository
source
Server

SQL
Explain Get run-
plan time
statistics

Analyze
objects Hints

Figure 8 — A process for optimizing SQL

The Explain plan is rather cryptic — to decipher and really understand it, one needs
significant experience and training. However, understanding the Explain plan is key to
being capable of tuning the statement and improving its performance. The better the tool
you have to understand the Explain plan, the easier it is to achieve the best optimization
SQL Development Guidelines 14 White Paper
possible. After understanding the optimization plan, it’s easy to pinpoint the problem
areas: full table scans, Cartesian joins and so on.

Figure 9 — Oracle’s Explain plan with a “little” help from Unicenter® SQL-Station® Plan
Analyzer® for Oracle

After the how, you will need to understand the why. For example, why did the optimizer choose to
ignore/use a specific index? In this stage, you will need to have access to concise information on
the objects referenced in the SQL: tables, views, indexes, clusters and their statistics. Be on the
watch for tables and indexes that have not been analyzed, indexes not being used or indexes that
are used but are useless (because of low selectivity ratio, for example).
As important as the previous steps — test it! Once the plan seems reasonable, run the statement
and gather all the statistics you can and make an assessment if it is still reasonable. And make
sure to test it in an environment similar to your deployment environment: donít run the SQL against
a table with 25 rows when the production table will have one million rows. The results are likely to
be slightly different.
One of the most powerful facilities provided by the Oracle engine is the ability to use
hints. Hints are the ultimate solution for forcing the optimizer to use an optimization
plan, different than the default that the developer finds or expects to perform better. For
example, force the usage of a specific index that has not been selected by the optimizer,
or force a specific type of join. Hints are extremely powerful and extremely delicate at the
same time, since they bypass the optimizer. The main challenge with hints is
understanding them and finding the one most appropriate to your statement. Oracle
adds new hints with every release, and it’s difficult to keep track of all of them. Another

SQL Development Guidelines 15 White Paper

challenge with hints is their syntax, which is similar to a comment — any minor typing
error will cause the hint to be ignored (treated as a comment).

Figure 10 — Adding Hints in sub queries (Unicenter® SQL-Station® Plan Analyzer® for
Oracle Hint Wizard)

With all this richness of options and solutions, the key is to be able to implement the statements
that perform best in your own specific environment. Again, having the right tools really makes a
difference. Performing all the steps mentioned above will require an unreasonable amount of
time using standard Oracle tools. Therefore, there is a high risk that these best practices will be
ignored in the rush to deliver the application on schedule.

Maintain the Performance in Production

The tuning process is never completed, even after the deployment of the application in
production. Some SQL statements may have escaped the review process, some others
may have been tuned wrong or changes in the data or the Oracle version could modify
the optimization plans.
Again, solutions exist to deal with these dynamics, but they require a combination of the
correct practices and the right tools to support them.
As an output of the development stage and pre-deployment tuning process, a repository
with the selected optimization plans and their statistics should be created. This is the
baseline for comparing and troubleshooting any degradation in performance, as well as
an easily accessible repository for summary reports. With this baseline, whenever an

SQL Development Guidelines 16 White Paper

upgrade in Oracle is evaluated, SQL statements can be tested in the new system and
the results and optimization plans compared with the data about the production version
available in the repository.
The production system also needs to be monitored on a regular basis for performance
degradation. In addition, whenever a problem is reported, the offending SQL needs to be
captured, identified, analyzed and tuned for best performance. The tuning process is not
different from the one described above as part of the proactive tuning. And with a
complete repository, it will be easy to identify a missing index, or a change in the SQL
statement, overwhelming proof to counter the proverbial “I didn’t change anything”
statement.
And again, tools! A repository, a capture facility that easily filters top I/O or memory
users, reports that will identify missing indexes, unused indexes and so on, are all
invaluable in keeping your application’s performance under control.

Figure 11 — Identify Top Resource Consumers (Unicenter SQL-Station Plan Analyzer

for Oracle)

SQL Development Guidelines 17 White Paper

Utilizing Computer Associates’ Unicenter® SQL-Station® for
PL/SQL Best Practices

Synopsis
Computer Associates International, Inc. (CA) is the industry leader in eBusiness
Database Management solutions. With Unicenter® SQL-Station® for Oracle, CA provides
the most complete and valuable offering in the marketplace for Oracle database
programmers.
Following is a brief description of the way in which those tools provide solutions to the
pains felt by organizations and individuals in the field of Oracle SQL and PL/SQL
programming.

History
CA with its vast expertise in databases, perceived the value and importance of tools for
database programming in the Oracle environment. As early as 1995, Computer
Associates decided to enter the market of tools for database server-side programming.

Best Practices for PL/SQL Programming

Unicenter SQL-Station was designed to address the requirements of modern database
server-side programming and provide solutions for the whole development life cycle.
Most of the requirements enumerated in the first part of this paper are provided by
Unicenter SQL-Station:
• Easy implementation and support for programming best practices through automatic
code generation, PL/SQL coding templates, easy documentation and support for
coding style through the premier Windows programming editor.
• Comprehensive IDE that incorporates:
- Catalog Browser for navigating database catalogs.
- Table, procedure and function Lookup Wizards with drag-and-drop in the editing
environment.
- Report Wizards that generate detailed object and schema information.
- Query window with lightning-fast execution environment.
- Best-of-breed code editor.
- PL/SQL coding assistance through Wizards and Coding Templates.
- Testing facilities with an automated execution engine for any server-side object
or on demand queries.
- Debugging, with the best server-side PL/SQL debugger.
- Change management support for third-party CM tools through integration with
any SCC-compliant change and configuration management tool (such as PVCS,
Microsoft Visual SourceSafe, Computer Associates’ AllFusion™ Harvest Change
Manger).

SQL Development Guidelines 18 White Paper

 - Database-aware version control and object management in code library residing
in the database with Unicenter SQL-Station Code Manager for Oracle.
- Premier Oracle SQL tuning and optimization with Unicenter SQL-Station Plan
Analyzer for Oracle.
• Pre-built, reusable library of functions to standardize coding and hide complexity of
routine, commonly used operations such as formatting, error and exception handling
and array manipulation.

Change Management for Database Objects

Unicenter SQL-Station Code Manager for Oracle supports the whole range of
requirements for change management:
• Catalog Browser provides easy, visual access to database objects on multiple
database servers simultaneously.
• A central Code Library is the storage for the database objects.
• Any object in the library can be checked-out and checked-in, revisions are
automatically kept and documented.
• Unlimited-size scripts can be easily imported and automatically separated into
separate entities.
• Drag-and-drop eases deployment or import of objects.
• Projects tie together units of work and deployment.
• Automatic deployment is triggered by clicking a button at the project level, or objects
can be consolidated in one script for further manipulation.

Application Performance Improvement

Unicenter SQL-Station Plan Analyzer for Oracle is the in-house expert for tuning Oracle
SQL. The Unicenter SQL-Station Plan Analyzer for Oracle component guides the user
through a comprehensive tuning process that enables any site to ensure that the
performance of their client/server applications will not be slowed down by un-tuned SQL.
In addition to the tuning process that should be an integral part of the development
process, Unicenter SQL-Station Plan Analyzer for Oracle provides advanced capture
facilities for identifying the SQL that slows down the server. After identifying a problem
SQL statement, the same tuning process is readily available so that the problem can be
quickly fixed.
Some of the benefits provided by Unicenter SQL-Station Plan Analyzer for Oracle:
• The strong expertise of Computer Associates’ engineers in the field of SQL tuning is
incorporated in the Unicenter SQL-Station Plan Analyzer for Oracle component:
every step is supported with easy to understand plain English explanations and
valuable advice.
• The Plan Explain features of Unicenter SQL-Station Plan Analyzer for Oracle are
unmatched. All the steps are visualized, animated, explained in plain English,
indented and color-coded for easy understanding and easy focus on problem areas.

SQL Development Guidelines 19 White Paper

• For every step in the optimization plan the user has immediate access to a wealth of
information on all the objects statistics and Oracle utilities. The user can quickly
identify tables of indexes that have not been analyzed and can run the Analyze
utility. An index creation wizard is also available for generating new indexes.
• Multiple optimization plans can be tested and compared with a powerful GUI
metaphor. Unicenter SQL-Station Plan Analyzer for Oracle will execute the SQL
under the various optimization plans and will gather all the relevant statistics
accurately. The results are then color-coded and presented graphically for easy
identification of the best performing plan.
• The Hints Wizard brings the power of all the Oracle optimization hints. Every hint is
explained and the wizard generates the selected hint automatically and with the
correct syntax.
• The Unicenter SQL-Station Plan Analyzer for Oracle Repository keeps track of all
the SQL that has been optimized and is invaluable in change management and
detection. Extinct and unused indexes are reported; plans that have changed since
their optimization are easily identified.
• Check JOIN facility visualizes JOIN statements using a ER metaphor and flags
various errors in the logic providing users with an automatic FIX option
• The Turbo Tuner feature will automatically generate optimized SQL statements, with
push-button ease, to replace existing un-tuned SQL. No tuning experience required
on the part of the user.

Conclusion
It has been estimated that 80% of database application performance issues are SQL
related. As companies are becoming more reliant upon their data assets, it is imperative
that data retrieval performance meets essential service levels. However, the initial
design and programming of the database code that performs the retrieval can be
complex, especially to those without expert SQL and or PL/SQL programming skills.
Once databases and applications are deployed in production, their code still has to be
managed and optimized.

The highly intuitive Graphical User Interface and Integrated Development Environment
provided by Unicenter SQL-Station streamlines complex day-to-day tasks in addition to
enabling easy adherence to programming standards and guidelines. Unicenter
SQL-Station is a solution no Database Developer should be without.

Information in this document is provided “AS IS” without warranty of any kind, and is subject to change without notice by
CA, which assumes no responsibility for any errors or claims herein.
© 2004 Computer Associates International, Inc. (CA). All trademarks, trade names, service marks and logos referenced
herein belong to their respective companies.

SQL Development Guidelines 20 White Paper