Guarantee Application Success Steven Feuerstein PL/SQL Evangelist, Quest Software

Obsessed with PL/SQL... Three courses in programming -1979-1980 Oracle pre-sales - 1987-1992 First book published - 1995 PL/SQL Evangelist, Quest Software 2001-Present Oracle PL/SQL Programming 5th Edition Book Signing Wednesday 15:45 Quest Booth Copyright 2008 Steven Feuerstein Copyright 2000-2008 Steven Feuerstein - Page 1

Welcome to My Obsession PL/SQL Obsession http://www.toadworld.com/sf Take advantage of all the resources available at PL/SQL Obsession. Standards, presentations, videos, puzzles, code... You have my permission to use all these materials to do internal trainings and to build your own applications. But remember: this code is generally not production ready. You must test them and modify them to fit your needs. filename_from_demo_zip.sql 2 Copyright 2008 Steven Feuerstein

What makes an application successful? That is the whole point of what we do, correct? And if our applications are successful, we are successful. It seems like the answer to this question should be obvious. But is it? Copyright 2008 Steven Feuerstein Page 3

How do we make our users happy? We make sure that the application... Is correct. The application should do what the user specified. Is fast enough to avoid user frustration and keep users productive. Is maintainable. As user requirements change, the application must change along with it without high cost. Copyright 2008 Steven Feuerstein Page 5

How do we achieve CORRECT, FAST (enough) and MAINTAINABLE? There is only way to prove that an application is correct: we test it. A lot. test Proactive: apply key optimization features test Reactive: stress/load test; isolate and remove bottlenecks. Establish, follow, verify best practices. Build and run regression tests. test Copyright 2008 Steven Feuerstein Page 6

"Regression" Test why is it called that? You've probably all heard of this kind of test. Why call it "regression" test? It is supposed to verify that your code has not regressed, gone backwards. If it worked in version 1.3, it really should work in version 1.4. How could this happen? I use (and need) that function key every day! Well, to be honest, we make changes and we really have no idea what the impact is. Sorry! Copyright 2008 Steven Feuerstein Page 7

Correct Applications are Tested Applications Testing is absolutely fundamental to successful applications. So why don't we test more thoroughly? Testing is hard work, in any and every language at least if we do it manually. For thorough testing, you should expect to have to write at least 10 lines of test code for every line of application code that needs testing! Testing is boring. We are not creating code or writing interesting algorithms and we are spoiled. Copyright 2008 Steven Feuerstein Page 8

Manual Testing is a Dead End If we write test code ourselves and stare at the screen until we are "sure" our code "works", we will never break out of the vicious cycle: We work long, hard hours yet always fall behind. Copyright 2008 Steven Feuerstein Page 9

Automation is Key to Thorough Testing There is really only one practical solution: automate code testing as fully as possible. It is, after all, precisely what we do to help our users. Automation allows us to... Find more bugs Repeat our tests Put regression tests in place Integrate testing into the development process. Copyright 2008 Steven Feuerstein Page 10

Options for automated testing of PL/SQL dbfit Based on the FitNesse platform, a tabular scripting approach, implemented in Java. utplsql and its variants Open-source framework, part of the xunit family. Essentially, "Junit for PL/SQL" PL/Unit and PLUTO are utplsql variants. SQL Developer 2.1 Unit testing integrated into the editor Quest Code Tester for Oracle Dedicated automated testing tool Copyright 2008 Steven Feuerstein Page 11

Successful Application are Fast (Enough) Applications This is the best understood leg of the tripod. Quest Software and others offer a number of tools to automate the tuning of SQL, and to stress test your code. Beyond that, it is critically important that you take advantage of key performancerelated features of PL/SQL. Copyright 2008 Steven Feuerstein Page 12

Key PL/SQL Performance Features The optimizing compiler Never set optimization level below 2. Collections Oracle's array-like structures, the foundation for most performance-related features of PL/SQL FORALL and BULK COLLECT Improve performance of multi-row SQL operations by an order of magnitude or more. The Oracle11g Function Result Cache Fantastic new declarative mechanism for data caching 11g_frc*.* Copyright 2008 Steven Feuerstein Page 13

Successful Applications are Maintainable Applications The code we write will be in use for years, perhaps decades. We should have all learned a big lesson from Y2K. The cost of maintaining an application can easily exceed the cost of initially building the application. It is critical that we pay attention not only to meeting the initial delivery deadline, but also to reducing the cost of changing the application over time. Copyright 2008 Steven Feuerstein Page 14

Steps to more maintainable code Build (and maintain) regression tests. Establish strong foundation of standards upon which code will be built. If everyone writes code their own way, the software is much harder to understand. Make it easy to follow standards. Don't just leave standards inside documents. Help developers establish new habits based on the standards. Verify that the standards were followed. If you don't check to make sure standards are followed, they will be ignored. Copyright 2008 Steven Feuerstein Page 15

What should be standardized? Don't start a new application until you have set standards in these areas... Basic coding standards and naming conventions. How to handle and log errors How, when and where to write SQL statements Copyright 2008 Steven Feuerstein Page 16

Basic coding conventions & naming standards Visit PL/SQL Obsession and select "PL/SQL Standards" to download a variety of suggested standards. Most important... Apply standards consistently and as comprehensively as possible. Check to make sure that standards are being followed. I will come back to this later. Copyright 2008 Steven Feuerstein Page 17

Standardize: How to Handle and Log Errors We don't like to deal with the negative, so we tend to avoid or minimize focus on exception management. Big mistake! It's very important to... Take full advantage of PL/SQL's error management features. Communicate problems in a consistent way to both users and support. Make it easy for developers to quickly and easily handle and log errors. Copyright 2008 Steven Feuerstein Page 18

Use a Shared Error Manager All developers should use the same mechanism to raise, handle, log errors. Many groups have built their own. If you need one... Quest Error Manager, available from www.toadworld.com/sf Logger from Oracle's samplecode on OTN Copyright 2008 Steven Feuerstein Page 19

How, When and Where to Write SQL Yes, that sounds about right, doesn't it? Imagine writing PL/SQL programs and not writing any SQL statements... Does that sound painful? I think it sounds wonderful! Copyright 2008 Steven Feuerstein Page 20

What's so bad about SQL? There's nothing wrong with SQL. The problem is with where, when and how we write SQL in our applications. Everyone has naming conventions and no one has any rules for SQL. Very strange... Stop taking SQL for granted. It is the source of many problems and challenges. Every SQL statement you write is a hard-coding that is worse than a hard-coded literal value! Copyright 2008 Steven Feuerstein Page 21

Set Rules for Writing SQL If you don't control how SQL is written, you will not be able to easily optimize and maintain your code. Use Bryn Check out Bryn Llewellyn's white paper "Doing SQL in PL/SQL: Best and Worst Practices" available on the Oracle Technology Network. Generally, apply the same principle to SQL that you should everything else in your code: Copyright 2008 Steven Feuerstein Page 22

Hide SQL Behind a Data Access Layer Protect application code from change. Prepare to take advantage of new features Like the Oracle11g function result cache. Improve productivity and code quality. Application Code Intermediate Layer Order Table Item Table Copyright 2008 Steven Feuerstein Page 23

Verify standards are being followed It's not enough to set rules, you need to check the code afterwards for compliance. Choose from any and all of the following: Peer/team code review (manual) Queries against various data dictionary views Compile-time warnings PL/Scope IDE- based analysis tools Copyright 2008 Steven Feuerstein Page 24

Peer / Team Code Review No critical code should make it to production unless another human being looks it over. You could go "extreme": Pair Programming of XP Team meetings to review code help in many ways... Share knowledge about applications and programs within Technology expertise is shared as senior developers point out other/better ways to do things Reading of code often can uncover "deep" bugs and better algorithms. Copyright 2008 Steven Feuerstein Page 25

Handy Data Dictionary views for PL/SQL ALL_SOURCE Source code of all accessible programs ALL_PROCEDURES Information about every subprogram you can execute ALL_ARGUMENTS Information about every argument of every subprogram you can execute ALL_PLSQL_OBJECT_SETTINGS Compile-time settings of PL/SQL program units Copyright 2008 Steven Feuerstein valstd.* show_all_arguments.* Copyright 2000-2008 Steven Feuerstein - Page 26

Compile-time warnings framework Enable warnings and the compiler will give you feedback on the quality of your code.. Review the PLW category in the Error Messages manual to see which warnings are most important to you. Use the Oracle11g version if at all possible. ALTER SESSION SET plsql_warnings = 'enable:all enable:all'; ALTER SESSION SET plsql_warnings = 'enable:06002', 'enable:performance enable:performance', 'ERROR:05005'; Copyright 2008 Steven Feuerstein Page 27

Compiler time warnings an example Check for unreachable end code. SQL> CREATE OR REPLACE PROCEDURE unreachable_code IS 2 x NUMBER := 10; 3 BEGIN 4 IF x = 10 THEN 5 x := 20; 6 ELSE 7 x := 100; -- unreachable code 8 END IF; 9 END unreachable_code; 10 / SP2-0804: Procedure created with compilation warnings SQL> show err Errors for PROCEDURE UNREACHABLE_CODE: LINE/COL ERROR -------- ------------------------------------- 7/7 PLW-06002: Unreachable code plw*.sql Copyright 2008 Steven Feuerstein Page 28

PL/Scope Oracle11g A compiler-driven tool that collects information about identifiers and makes it available through a data dictionary view. Use PL/Scope to answer questions like: Where if a variable assigned a value in a program? What variables are declared inside a given program? Which programs call another program (that is, you can get down to a subprogram in a package)? Find the type of a variable from its declaration. Copyright 2008 Steven Feuerstein Page 29

Some PL/Scope examples Enable gathering of PL/Scope data. ALTER SESSION SET plscope_settings='identifiers:all' Verify PL/Scope setting for a program. SELECT plscope_settings FROM user_plsql_object_settings WHERE NAME = 'PACK1' AND TYPE = 'PACKAGE BODY' Identify all declarations for the specified set of programs whose names do not start with "L_". SELECT name, signature, tyhpe FROM user_identifiers WHERE name NOT LIKE 'L\_%' ESCAPE '\' ' AND USAGE = 'DECLARATION' AND object_name LIKE '&1' 11g_plscope.sql 11g_plscope_amis.sql Copyright 2008 Steven Feuerstein Page 30

IDE-Integrated Code Analyzers Automatically check code against a set of rules and recommendations. Toad and SQL Navigator offer CodeXpert, which is largely driven by ideas in my Oracle PL/SQL Best Practices book. Copyright 2008 Steven Feuerstein Page 31

Guarantee Application Success You need to... Prove correctness don't just hope and pray. Make sure it is fast enough. Write readable, maintainable code. We can do all of this, but only if we... Think about the future. Don't just code for today. Take full advantage of PL/SQL's features. Automate the testing process. Ask our managers to protect us from deadline pressures. Copyright 2008 Steven Feuerstein Page 32