Oracle SQL Maintenance Concepts

8/6/2019 Oracle SQL Maintenance Concepts

1/22

Oracle

SQL and PL/SQL

Development and Maintenance

Concepts


2/22

SQL Development Guidelines White Paper

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) ------------------------------------------ 4Supporting the Development Life cycle ------------------------------------------------------------ 4

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

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

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

Required Automated Solutions----------------------------------------------------------------------- 9Access to Database Objects -------------------------------------------------------------------------- 9Source Code Repository ------------------------------------------------------------------------------10Object Granularity and Version Control -----------------------------------------------------------10Deployment-----------------------------------------------------------------------------------------------11Dependency Analysis----------------------------------------------------------------------------------12Security ----------------------------------------------------------------------------------------------------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 UNICENTERSQL-STATIONFOR PL/SQLBEST 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


3/22

SQL Development Guidelines 1 White Paper

Executive Summary

Database programming has recently become more of a distinct discipline among othertypes of programming. Within this distinct discipline, Oracle the predominantdatabase server has specific programming considerations, such as a dedicated

programming language PL/SQL, significant control over the optimization process andmore. In Oracle shops, an increasing number of developers, traditionally isolated fromdatabase specifics, have been exposed to database programming as a result ISmanagement feels the need for establishing programming standards and guidelines.

In this paper we discuss the need for a set of programming guidelines for Oracle andsuggest a framework for creating a customized, specific standard within organizations.We chose to address elements that are unique to database programming, and refrainedfrom discussing usage of Rapid Application Development tools with databases. Thiswhite paper focus on server-side programming and PL/SQL because we believe thatthese techniques are usually omitted or ignored in the corporate standards. It is also ourstrong recommendation that these techniques should be promoted throughout theenterprise for improving both the quality and the performance of applications.

The other two topics which are covered in detail are change management of databaseobjects and proactive tuning of SQL statements. Change management is a key elementin any application development process, and we find it relatively immature in databaseobjects and database programming. Performance is a major concern with anyclient/server application, but not enough is done in the development stages to ensurethe best results upon release to production. Our experience proves that proactive SQLtuning during early development stages is extremely effective in generating applicationswith good overall performance.

Figure 1 Database related activities in the development life cycle.

Unfortunately, the state of tools for SQL tuning and PL/SQL development lags behindmore popular programming environments, with Oracle Corporation traditionally focusedmore on applications and less on development tools. We provide our vision of the ideal

Ana lys is an d design D eploym entDevelopment

Physical

Model

Logical

Model

Modeling

Coding

Tuning

Maintenance, Change Management

Testing and Debugging

Embedded SQL

Server-side logic

(PL/SQL )


4/22


development tools required to implement our recommendations, and take a closer lookat the Unicenter SQL-Station suite.

We do not cover the topic of logical and physical database design since they are closerto the analysis and design stages of application development than to the actualimplementation 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 ofbusiness rules in Oracle (stored procedures and database triggers) is programmed inPL/SQL. Furthermore, PL/SQL is the language of preference in Oracle client-sideapplication development tools, and PL/SQL is also internally used in Oraclesdevelopment process. Oracle Corporation seems to further develop and stand behindPL/SQL in the new releases of Oracle, and it is clear that PL/SQL is here to stay as thelanguage of preference for writing Oracle database and application logic.

PL/SQL is a powerful extension of Oracles SQL and is tightly integrated with it. PL/SQLempowers database programmers with a rich set of language constructs, enabling themto deliver better multi-platform Oracle database applications more quickly.

Server-side code is a generic name for those objects of code that execute on thedatabase server, such as stored procedures, database triggers and functions. The namedifferentiates these objects from client-side code, which includes objects of code thatexecute on the client, and within this context, on the application server. The ability toexecute code within the confines of the database server is not a new concept, as it hasbeen around since database triggers were first supported. The value of server-side codeis 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 thanexpected based on the analysis of its benefits.

Developing server-side code in Oracle requires writing programs in PL/SQL. PL/SQL isvery rich in features and supports numerous advanced programming techniques,including basic concepts of object-oriented programming. So why is there a slowadoption rate? One of the key bottlenecks is the learning curve: feature rich usuallymeans difficult to learn. The other major reason lies in the lack of modern developmenttools for PL/SQL.

To summarize, server-side code is undoubtedly highly recommended in client/serverapplications. In Oracle 7 and 8, server-side code is written in PL/SQL, a languagedifferent from most other languages, being a hybrid between a procedural language andSQL. 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 maintainand modify. This section will attempt to shed some light on solutions and approaches tothis challenge.

Naturally, the first steps for producing effective code start with proper logical andphysical database design. The scope of the current paper does not include thosestages, although we do feel that there are significant benefits from ER modeling toolsthat assist in visualizing and manipulating object relationships.


5/22


PL/SQL Programming Standards

The challenges of coding in PL/SQL start with the very basics: thorough knowledge ofthe language and its constructs. PL/SQL is by no means a lean language, nor is it assimple as C. It is packed with features and options and therefore not easily mastered. Asif 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 programminglanguage, used in conjunction with the client-side development language(s) eitherVisual C++, Visual Basic, PowerScript or Java. One of the drawbacks of PL/SQLscomplexity is the fact that programmers tend to use only basic constructs and primitivefeatures of the language. Most developers never get the chance to learn the moreadvanced features.

The solutions to these challenges are a combination of good training practices, solidprogramming standards and excellent development tools.

Training

Training is essential. Any organization planning to develop in Oracles PL/SQL must

have a good training program. PL/SQL is not self-explanatory or intuitive enough to letprogrammers pick it up as they go the consequences will be illiteracy in PL/SQL, a20% 40% utilization of the power of the language and poorly written code.

Programming Standards

Programming standards are as important as good training procedures. Creating andenforcing coding standards with PL/SQL, as with any other programming language, willensure higher quality code that is easier to read, understand, maintain and reuse. Theset of standards suitable to a specific organization should include a mix of existingcoding practices, advice from experienced PL/SQL developers, good programmingpractices 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 guidelineslocation in the module, mandatory contents, style and soon.

Coding style and indentation rules.

Upper/lower case usage rules.

Naming conventions for objects, variables, arguments, exceptions, constants andso on.

Variable naming, typing and declaration formatting rules (and do not forget todiscuss anchored data types).

Coding SQL statements within PL/SQL.

Templates and coding rules for all the recommended control structures (cursors, ifstatements, loops and so on).


6/22


7/22


Navigating database catalogs

Dealing with database programming has some of its own specific requirements, and these shouldnot be ignored when evaluating tools. The ideal IDE should allow the developer to navigate thedatabase catalog, as the equivalent of the file system in conventional client-side environments,and preferably support simultaneous access to multiple database servers in your distributedenvironment. 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

Figure 2 Exploring the database catalog (Unicenter SQL-StationCatalog Browser)


8/22


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

Accessing Object Information in the Catalog

Oracles 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 columnnames, procedures and functions, and prototypes can be placed at the programmers fingertipswhile 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 availableboth 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 easyand fast access to the database to view values, make modifications and maybe populatesmall test tables with data. The developer should be able to code and execute queriesagainst 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)


9/22


Editing

When the editor is evaluated, SQL Plus cannot pass the test a real interactive editorfor programmers is needed. Developers are used to syntax highlighting, enhancedsearch and replace, working with blocks of code, formatting and so on. Most advancedPL/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 describedhere.

PL/SQL Coding Assistance

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

DebuggingWhen evaluating debugging facilities, usingprintf(or the PL/SQL equivalenttheDBMS_OUTPUT package) should not be regarded as a feasible solution. Programmingtools in the 1990s allow developers to step through statements while debugging, setbreakpoints, view and modify variable values, automatically detect dependencies and soon. Debugging can take as much as a third of the development phase; so expediting thedebugging process has a significant impact on application delivery, not to mentionquality.


10/22


Figure 4 Stepping through the code in debug mode (Unicenter SQL-StationDebugger for Oracle)

Change Management and Version Control

Robust version control and configuration management is critical in a complexdevelopment environment, which includes multi-tier applications accessingheterogeneous databases and staged deployment of database server-side code fromdevelopment through test to production. The ability to check code objects in and out isalso critical to support team development and reuse.

Tuning

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

essential to the success of client/server applications.


11/22


Change Management for Database Objects

Overview

Database objects, including both data objects (tables, indexes and views) and codeobjects (stored procedures and triggers) are an important element of a completeclient/server application. Very much like other application elements, these objects needto be managed and controlled, and should follow the same rules of change andconfiguration management as the rest of the application.

Traditional source control and configuration management tools do not address databaseobjects well. This section will present the major challenges related to managing andcontrolling database objects, and suggests desired functions from an idealsoftwarepackage.

Current Methods

The source control tools normally available to DBAs and project managers are limitedand rudimentary. They do not follow familiar version control metaphors, nor do they takeadvantage of information or supporting data available from the RDBMS itself, such asthe catalog.

Usually, DBAs will combine DDL commands for creating tables and indexes into longand difficult to manage scripts. This can create significant difficulties, including thefollowing:

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 hardto manage.

Required Automated Solutions

Automated tools should address the pains stated above, and facilitate a manageableand controllable environment in the area of database objects. Following are some detailsregarding 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 notreadily accessible to developers making them different than program source filesresiding on the file system. Easy access to objects is a key requirement, especially inteam development environments, where code sharing and reusability play such animportant role.

Automation in this area should imitate tools available in web and client/serverenvironments, with additional support for operating on the database server. An ideal toolshould provide the same access options and metaphors that are available with tools


12/22


outside the database developers use File Manager or Explorer to access objects inthe file system, they should have similar navigation tools for the database catalogs. Indistributed environments, multiple databases and heterogeneous database types shouldall 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 databaseobjects are developed in a test environment and later deployed into one or moreproduction 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 propersharing and reusability of code, enforcement of security, version control, definition offixes, releases and versions.

Object Granularity and Version Control

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


13/22


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 inthe 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 fieldand some logic modification in a trigger. Without version control at the object level, what are theoptions? Making a change in the script that defines the whole database would likely be too time andresource intensive. In a more likely scenario, a developer will pull out the code for the constraint andthe trigger, perform the changes by hand, hopefully test and deploy the changes, and then modifythe big script to maintain consistency. The application development world has dealt with thepotential 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 changeto theproduction system that affects only several entities, is completely reversible, and can be automaticallydeployed to the production environment. The assigned developers will checkoutthe affected entities,so that nobody else can modify them at the same time. They will modify the code, use testing anddebugging features available in the integrated development environment, and then checkthe entitiesback in. In this scenario, if something goes wrong, the previous version or versions are still availablein a repository so that the change can be reverted. Moreover, a revision history of each object shouldbe available, with a timestamp and proper documentation of the modification. Another necessaryfeature for this vision to become a reality is a comparefacility that will highlight the differencesbetween any two revisions. And to complete the process, the whole change will be packaged in anamed and documented change-unitorprojectentity, so that either rollback (For example, revertingto the previous version) or commit (For example, deployment to production) can be performed in onelogical 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 stepin deployment is defining the deployment unit. The deployment unitis a project or sub-


14/22


project that is self-contained. A project can consist of one item (such as a table or astored procedure), or numerous items related to a change (such as a combination of modifiedtables, triggers, packages and so on). In the project definition the project manager should be ableto define the items belonging to it, document the purpose of the package and identify deploymenttargets. The deployment target concept is important, because tens or hundreds of servers mayhost 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 ofdatabase servers, such as the help-desk servers or the sales servers. Then, by clicking on aDeploy button an automated deployment mechanism is triggered that deploys the objects to oneor more servers.

Figure 7Automatic 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 toanother 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, thereforeautomatic dependency analysis is very useful in the deployment process to ensuresuccessful object deployment in the correct order.


15/22


Security

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

Application Performance Improvement Proactive SQL Tuning

It is estimated that 60 80% of performance problems in client/server applications areassociated with SQL that has not been properly tuned. As an obvious conclusion, themost 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 beone of the mandatory steps in product development, to be performed well in advance ofapplication deployment. Tuning SQL in Oracle is a difficult, tedious task that requiresextensive experience and expertise. The reason for this is the wealth of options availableto programmers in affecting Oracles optimization plans: selecting optimization modes,using different SQL coding techniques for obtaining equivalent results and an everincreasing 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 userscould 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 areprimarily concerned with getting the correct information from the database, not with theexistence of indexes or alternate access paths.

The first rule in establishing best practices for server-side code is therefore awarenessof performance and optimization plans. Even if the application seems to function asexpected and the project is behind schedule, never bypass checking the SQL forperformance! SQL reviews should be an integral part of the overall application reviewprocess, supported by a well-documented set of coding rules and the presence of asenior DBA and appropriate supporting tools.

Following is a sample questionnaire to be used during the SQL review process. This isby no means a complete list, but can serve as a starting point in compiling such acomprehensive list:

Parse phase is/should be combined with execute phase? (If statement is executedmultiple times, its preferable to separate and assume that most executions will usethe already parsed statement from the SGA. If statement cannot be shared, itspreferable 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 theyallow for sharing whenever a constant is used, the memory kept for that statementcannot be shared. On the other hand, sometimes using constants changes theoptimization plan, based on index statistics available to the optimizer.)


16/22


Statement uses standard coding conventions and optimization mode? Anydifferences, such as capitalization, prevent cursors from being shared.

Update statements use array binding? (Array binding significantly reduces networktraffic.)

Is the size for array fetching optimal?

Statement contains correlated sub query? If so, consider using nested select, usuallya better performer for batch applications.

Statement uses HAVING clause? Consider replacing with WHERE clause ifpossible. (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 willcause 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 withWHERE clause.

Statement/cursor likely to be used by other modules? Consider creating server-sideobject (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 deeperinto Oracle optimization plans and their understanding. The Oracle optimizer can

generate Explain plans for each statement those plans describe the exact operationsperformed by the optimizer to complete the statement.

Explain

plan

Get run-

time

statistics

Analyze

objects

Capture on

Server

Select from

source Repository

SQL

Hints

Figure 8 A process for optimizing SQL

The Explain plan is rather cryptic to decipher and really understand it, one needssignificant experience and training. However, understanding the Explain plan is key tobeing capable of tuning the statement and improving its performance. The better the toolyou have to understand the Explain plan, the easier it is to achieve the best optimization


17/22


possible. After understanding the optimization plan, its easy to pinpoint the problemareas: full table scans, Cartesian joins and so on.

Figure 9 Oracles 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 toignore/use a specific index? In this stage, you will need to have access to concise information onthe objects referenced in the SQL: tables, views, indexes, clusters and their statistics. Be on thewatch for tables and indexes that have not been analyzed, indexes not being used or indexes thatare 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 statementand gather all the statistics you can and make an assessment if it is still reasonable. And makesure to test it in an environment similar to your deployment environment: dont run the SQL againsta table with 25 rows when the production table will have one million rows. The results are likely tobe 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 optimizationplan, different than the default that the developer finds or expects to perform better. Forexample, 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 thesame time, since they bypass the optimizer. The main challenge with hints isunderstanding them and finding the one most appropriate to your statement. Oracleadds new hints with every release, and its difficult to keep track of all of them. Another


18/22


challenge with hints is their syntax, which is similar to a comment any minor typingerror 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 statementsthat perform best in your own specific environment. Again, having the right tools really makes adifference. Performing all the steps mentioned above will require an unreasonable amount oftime using standard Oracle tools. Therefore, there is a high risk that these best practices will beignored 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 inproduction. Some SQL statements may have escaped the review process, some othersmay 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 thecorrect practices and the right tools to support them.

As an output of the development stage and pre-deployment tuning process, a repositorywith the selected optimization plans and their statistics should be created. This is thebaseline for comparing and troubleshooting any degradation in performance, as well asan easily accessible repository for summary reports. With this baseline, whenever an


19/22


upgrade in Oracle is evaluated, SQL statements can be tested in the new system andthe results and optimization plans compared with the data about the production versionavailable in the repository.

The production system also needs to be monitored on a regular basis for performancedegradation. 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 notdifferent from the one described above as part of the proactive tuning. And with acomplete repository, it will be easy to identify a missing index, or a change in the SQLstatement, overwhelming proof to counter the proverbial I didnt change anythingstatement.

And again, tools! A repository, a capture facility that easily filters top I/O or memoryusers, reports that will identify missing indexes, unused indexes and so on, are allinvaluable in keeping your applications performance under control.

Figure 11 Identify Top Resource Consumers (Unicenter SQL-Station Plan Analyzerfor Oracle)


20/22


Utilizing Computer Associates UnicenterSQL-Station for

PL/SQL Best Practices

Synopsis

Computer Associates International, Inc. (CA) is the industry leader in eBusinessDatabase Management solutions. With Unicenter SQL-Station for Oracle, CA providesthe most complete and valuable offering in the marketplace for Oracle databaseprogrammers.

Following is a brief description of the way in which those tools provide solutions to thepains felt by organizations and individuals in the field of Oracle SQL and PL/SQLprogramming.

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, ComputerAssociates 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 databaseserver-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 byUnicenter SQL-Station:

Easy implementation and support for programming best practices through automaticcode generation, PL/SQL coding templates, easy documentation and support forcoding 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 editingenvironment.

- 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 objector on demand queries.

- Debugging, with the best server-side PL/SQL debugger.

- Change management support for third-party CM tools through integration withany SCC-compliant change and configuration management tool (such as PVCS,Microsoft Visual SourceSafe, Computer Associates AllFusion Harvest ChangeManger).


21/22


- Database-aware version control and object management in code library residingin the database with Unicenter SQL-Station Code Manager for Oracle.

- Premier Oracle SQL tuning and optimization with Unicenter SQL-Station PlanAnalyzer 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 handlingand array manipulation.

Change Management for Database Objects

Unicenter SQL-Station Code Manager for Oracle supports the whole range ofrequirements for change management:

Catalog Browser provides easy, visual access to database objects on multipledatabase servers simultaneously.

A central Code Library is the storage for the database objects.

Any object in the library can be checked-outand checked-in, revisions areautomatically kept and documented.

Unlimited-size scripts can be easily imported and automatically separated intoseparate 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 objectscan 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 OracleSQL. The Unicenter SQL-Station Plan Analyzer for Oracle component guides the userthrough a comprehensive tuning process that enables any site to ensure that theperformance 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 developmentprocess, Unicenter SQL-Station Plan Analyzer for Oracle provides advanced capturefacilities for identifying the SQL that slows down the server. After identifying a problemSQL statement, the same tuning process is readily available so that the problem can bequickly 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 isincorporated in the Unicenter SQL-Station Plan Analyzer for Oracle component:every step is supported with easy to understand plain English explanations andvaluable advice.

The Plan Explain features of Unicenter SQL-Station Plan Analyzer for Oracle areunmatched. All the steps are visualized, animated, explained in plain English,indented and color-coded for easy understanding and easy focus on problem areas.


22/22


For every step in the optimization plan the user has immediate access to a wealth ofinformation on all the objects statistics and Oracle utilities. The user can quicklyidentify tables of indexes that have not been analyzed and can run the Analyzeutility. 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 SQLunder the various optimization plans and will gather all the relevant statisticsaccurately. The results are then color-coded and presented graphically for easyidentification of the best performing plan.

The Hints Wizard brings the power of all the Oracle optimization hints. Every hint isexplained and the wizard generates the selected hint automatically and with thecorrect syntax.

The Unicenter SQL-Station Plan Analyzer for Oracle Repository keeps track of allthe SQL that has been optimized and is invaluable in change management anddetection. Extinct and unused indexes are reported; plans that have changed sincetheir optimization are easily identified.

Check JOIN facility visualizes JOIN statements using a ER metaphor and flagsvarious errors in the logic providing users with an automatic FIX option

The Turbo Tuner feature will automatically generate optimized SQL statements, withpush-button ease, to replace existing un-tuned SQL. No tuning experience requiredon the part of the user.

Conclusion

It has been estimated that 80% of database application performance issues are SQLrelated. As companies are becoming more reliant upon their data assets, it is imperativethat data retrieval performance meets essential service levels. However, the initial

design and programming of the database code that performs the retrieval can becomplex, 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 bemanaged and optimized.

The highly intuitive Graphical User Interface and Integrated Development Environmentprovided by Unicenter SQL-Station streamlines complex day-to-day tasks in addition toenabling easy adherence to programming standards and guidelines. UnicenterSQL-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 byCA, which assumes no responsibility for any errors or claims herein.

2004 Computer Associates International, Inc. (CA). All trademarks, trade names, service marks and logos referencedherein belong to their respective companies.

Documents

Oracle SQL Maintenance Concepts