Oracle PL/SQL Quick Reference

 
PL/SQL Block Structure

DECLARE --Optional

  --Variables, Cursors, User-defined exceptions

BEGIN --Mandatory

  --SQL statements

  --PL/SQL statements

EXCEPTION --Optional

  --Actions to perform when errors occur

END; --Mandatory

 

PL/SQL Block Type

Anonymous               Procedure               Function

[DECLARE]               PROCEDURE name          FUNCTION name

                        IS                      RETURN datatype                                                         IS

BEGIN                   BEGIN                   BEGIN

  --statements            --statements            --statements

                                                  RETURN value;

[EXCEPTION]             [EXCEPTION]             [EXCEPTION]

END ;                   END ;                   END ;

 

Declaring PL/SQL Variables

identifier [CONSTANT] datatype [NOT NULL]

   [:=|DEFAULT expr];

 

Assigning Values to Variables

identifier := expr;

Types of Variables

PL/SQL variables:

Scalar
Composite
Reference
LOB(Large OBjects)


Non-PL/SQL variables: Bind or host variables

Used to pass run time values out of the PL/SQL block back to the Host environment


 

Base Scalar Datatypes

VARCHAR2(maximum_length)      BOOLEAN           CHAR[(maximum_length)]

DATE                         LONG              LONG RAW    

BINARY_INTEGER                PLS_INTEGER       NUMBER(precision,scale)

TIMESTAMP

The %TYPE Attribute

Identifier Table_name.column_name%TYPE ;

Identifier Variable_name%TYPE ;

 

Composite Datatypes

INDEX BY TABLE          RECORD      NESTED TABLE      VARRAY

 

LOB Datatypes

CLOB        BLOB        BFILE             NCLOB

 

Creating Bind Variables

VARIABLE variable_name dataype

 

Displaying Bind Variables

PRINT [variable_name]

NOTE: To reference a bind variable in PL/SQL, you must prefix it's name with colon (:)

Commenting Code

--prefix single-line comments with two dashes

/* Place muti-line comment between the symbols */

 

SELECT Statements in PL/SQL

SELECT {column_list|*}

INTO {variable_name[,variable_name]...

      |record_name}

FROM table

[WHERE condition];

NOTE: The INTO clause is must and queries must return one and only one row. A CURSOR can be used to retrieve more than one row.

 

Implicit Cursor Attributes for DML statements

SQL%ROWCOUNT

SQL%FOUND

SQL%NOTFOUND

SQL%ISOPEN

 

Control Structures

IF Statement                              Basic Loop

IF condition THEN                         LOOP

   statements;                               statements;

[ELSIF condition THEN                        ...

   statements;]                              EXIT [WHEN condition];

[ELSE                                     END LOOP;

   statements;]

END IF;

 

FOR Loop                                  WHILE Loop

FOR counter IN [REVERSE]                  WHILE condition LOOP

   Lower_bound..upper_bound LOOP             statement1;

   statement1;                               statement2;

   statement2;                               ...

   ...                                    END LOOP;

END LOOP;

 

CASE

CASE selector

   WHEN expression1 THEN result1

   WHEN expression2 THEN result2

   ...

   WHEN expressionN THEN resultN

   [ELSE resultN+1]

END;

Creating a PL/SQL Record

TYPE type_name IS RECORD

(field_declaration[,field_declaration]...) ;

identifier type_name ;

 

Where field_declaration is:

field_name {field_type|variable%TYPE|

table.column%TYPE|table%ROWTYPE}

[[NOT NULL] {:=|DEFAULT} expr]

 

Referencing Fields in the Record

record_name.field_name

 

Declaring Records with the %ROWTYPE Attribute

DECLARE

record_name       reference%ROWTYPE

 

Creating a PL/SQL Table (INDEX BY Table)

TYPE type_name IS TABLE OF

{column_type|variable%TYPE|table.column%TYPE

|variable%ROWTYPE} [NOT NULL]

[INDEX BY BINARY_INTEGER];

identifier type_name ;

 

Referencing a PL/SQL table

pl_sql_table_name(primary_key_value)

Using PL/SQL Table Method

table_name.method_name[(parameters)]

 

PL/SQL Table Methods

EXITS(n)    COUNT       FIRST       LAST        PRIOR(n)

NEXT(n)     EXTEND(n,i)             TRIM        DELETE

PL/SQL Table of Records

TYPE table_name_type IS TABLE OF table_name%ROWTYPE

INDEX BY BINARY_INTEGER ;

table_name table_name_type ;

 

Referencing a Table of Records

table_name(index).field

 

Cursor

Declaring the Cursor in Declaration Section

CURSOR cursor_name IS select_statement ;

record_name cursor_name%ROWTYPE ;

 

Opening and Closing the Cursor

OPEN cursor_name ;

CLOSE cursor_name ;

 

Fetching Data from the Cursor

FETCH cursor_name

INTO [variable1(,variable2,...)

    |record_name] ;

 

Explicit Cusor Attributes

cursor_name%ISOPEN

cursor_name%NOTFOUND

cursor_name%FOUND

cursor_name%ROWCOUNT

 

Cursor FOR Loops

FOR record_name IN cursor_name LOOP

   statement1;

   statement2;

   ...

END LOOP;

 

Cursor FOR Loops Using Subqueries

FOR record_name IN (subqueries) LOOP

statement1

...

END LOOP ;

 

Cursors with Parameters

CURSOR cursor_name [(cursor_parameter_name datatype

[,...])]

IS select_statement

[FOR UPDATE [OF column_reference][NOWAIT]];

 

Parameter Name

cursor_parameter_name [IN] datatype [{:=|DEFAULT}expr]

 

Openning with Parameters

OPEN cursor_name(cursor_parameter_name[,...]);

 

Cursor FOR Loops with parameters

FOR record_name IN cursor_name(cursor_parameter_name

[,...]) LOOP

   statement1;

   statement2;

   ...

END LOOP;

 

WHERE CURRENT OF clause

UPDATE|DELETE ... WHERE CURRENT OF cursor_name ;

 

Predefined Exceptions

NO_DATA_FOUND

TOO_MANY_ROWS

INVALID_CURSOR

ZERO_DIVIDE

DUP_VAL_ON_INDEX

 

Exception

Trapping Exceptions

EXCEPTION

   WHEN exception1 [OR exception2 ...] THEN

statement1 ;

statement2 ;

...

   [WHEN exception3 [OR exception4 ...] THEN

statement1 ;

statement2 ;

...]

   [WHEN OTHERS THEN

statement1 ;

statement2 ;

...]

 

Declaring Non-Predefined Oracle Sever Exception

DECLARE

   exception EXCEPTION ;

   PRAGMA EXCEPTION_INIT(exception, error_number) ;

 

Referencing the declared Non-predefined execption

BEGIN

   ...

EXCEPTION

   WHEN exception THEN

statement1 ;

...

END ;

Trapping User-Defined Exceptions

DECLARE

   exception EXCEPTION ;

BEGIN

   ...

   IF SQL%NOTFOUND THEN

RAISE exception ;

   END IF ;

   ...

EXCEPTION

   WHEN exception THEN

statement1 ;

...

END ;

Functions for Trapping Exceptions

SQLCODE           return error code

SQLERRM           return error message

 

RAISE_APPLICATION_ERROR procedure(Executable/Exception

Section)

RAISE_APPLICATION_ERROR ( error_number,

  message [, {TRUE|FALSE}]) ;

error_number      between -20000 to -20999

message           string up to 2,048 bytes long

TRUE              placed on the stack of previous errors.

FALSE             replaces all previous errors

 

Oracle SQL Tuning Tips

consideration when writing an SQL statement is that it returns a correct result. The second is that it be the most efficient for a given situation.  You can use many different SQL statements to achieve the same result. It is often the case that only one statement will be the most efficient choice in a given situation.

Remember that processing SQL is a sequence of Parse (syntax check and object resolution), Execution (required reads and writes), and Fetch (row results retrieved, listed, sorted, and returned). SQL “tuning” consists, quite simply, of reducing one or more of them.

Note: generally Parse is the greatest time and resource hog. Parse overhead can be minimized by the use of Procedures, Functions, Packages, Views, etc.

Inadequate performance can have a significant cost impact on your business. A poor performing system and application can result in customer dissatisfaction, reduced productivity, and high costs. It is absolutely critical that the system’s performance is operating at its peak levels.

Following are some general tips that often increase SQL statement efficiency. Being general they may not apply to a particular scenario.

• Tuning SQL should only be done after your code is working correctly. Be aware that there is an inevitable tug-of-war between writing efficient SQL and understandable SQL.
• Ensure repeated SQL statements are writtenabsolutely identicallyto facilitate efficient reuse: re-parsing can often be avoided for each subsequent use of an identical statement.
  Writing best practices: all SQL verbs in upper-case i.e. SELECT; separate all words with a single space; all SQL verbs begin on a new line; SQL verbs aligned right or left within the initial verb; set and maintain a table alias standard; use table aliases and when a query involves more than one table prefix all column names with their aliases. Whatever you do, be consistent.
• o Use bind variables: The values of bind variables do not need to be the same for two statements to be considered identical. Bind variables are not substituted until a statement has been successfully parsed.
• o Use standard approach to table aliases. If two identical SQL statements vary because an identical table has two different aliases, then the SQL is different and will not be re-use or shared.
• o Use table aliases and prefix all column names by their aliases when more than one table is involved in a query. This reduces parse time and prevents future syntax errors if someone adds a column to one of the tables with same name as a column in another table. (ORA-00918: COLUMN AMBIGUOUSLY DEFINED)
• Code the query as simply as possible i.e. no unnecessary columns are selected, no unnecessary GROUP BY or ORDER BY.
  It is the same or faster to SELECT by actual column name(s). The larger the table the more likely the savings.
  Use:
  SELECT customer_id, last_name, first_name, street, city FROM customer;
  Rather than,
  SELECT * FROM customer;
• Beware of WHERE clauses which do not use indexes at all. Even if there is an index over a column that is referenced by a WHERE clause included in this section, Oracle will ignore the index. All these WHERE clause can be re-written to use an index while returning the same values. In other words, Do not perform operations on database objects referenced in the WHERE clause:
  Use:
  SELECT client, date, amount FROM sales WHERE amount > 0;
  Rather than:
  SELECT client, date, amount FROM sales WHERE amount != 0;
  ———————————————
  Use:
  SELECT account_name, trans_date, amount FROM transaction WHERE account_name LIKE ‘CAPITAL%’;
  Rather than:
  SELECT account_name, trans_date, amount FROM transaction WHERE SUBSTR(account_name,1,7)=‘CAPITAL’;
  ———————————————
  Use:
  SELECT account_name, trans_date, amount FROM transaction WHERE amount > 0;
  Rather than:
  SELECT account_name, trans_date, amount FROM transaction WHERE amount NOT=0;
  ———————————————
  Use:
  SELECT account_name, trans_date, amount FROM transaction WHERE amount < 2000;
  Rather than:
  SELECT account_name, trans_date, amount FROM transaction WHERE amount + 3000 < 5000;
  ———————————————
  Use:
  SELECT account_name, trans_date, amount FROM transaction WHERE account_name = ‘AMEX’ AND account_type = ‘A’;
  Rather than:
  SELECT account_name, trans_date, amount FROM transaction WHERE account_name|| account_type=‘AMEXA’;
• Don’t forget to tune views. Views are SELECT statements and can be tuned in just the same way as any other type of SLECT statement can be. All tuning applicable to any SQL statement are equally applicable to views.
• Avoid including a HAVING clause in SELECT statements. The HAVING clause filters selected rows only after all rows have been fetched. Using a WHERE clause helps reduce overheads in sorting, summing, etc. HAVING clauses should only be used when columns with summary operations applied to them are restricted by the clause.
  Use:
  SELECT city FROM country WHERE city!= ‘Vancouver’ AND city!= ‘Toronto’; GROUP BY city;
  Rather than:
  SELECT city FROM country GROUP BY city HAVING city!= ‘Vancouver’ AND city!= ‘Toronto’;
• Minimize the number of table lookups (subquery blocks) in queries, particularly if our statements include subquery SELECTs or multicolumn UPDATEs.
  Use:
  SELECT emp_name FROM emp WHERE (emp_cat, sal_range) = (SELECT MAX(category), MAX(sal_range) FROM emp_categories) AND emp_dept = 0020;
  Rather than:
  SELECT emp_name FROM emp WHERE emp_cat=(SELECT MAX(category) FROM emp_categories) AND emp_range = (SELECT MAX(sal_range) FROM emp_categories) AND emp_dept = 0020;
• When writing a sub-query (a SELECT statement within the WHERE or HAVING clause of another SQL statement):
• o Use a correlated (refers to at least one value from the outer query) sub-query when the return is relatively small and/or other criteria are efficient i.e. if the tables within the sub-query have efficient indexes.
• o Use a non-correlated (does not refer to the outer query) sub-query when dealing with large tables from which you expect a large return (many rows) and/or if the tables within the sub-query do not have efficient indexes.
• o Ensure that multiple sub-queries are in the most efficient order.
• o Remember that rewriting a sub-query as a join can sometimes increase efficiency.
• When doing multiple table joins consider the benefits/costs for each of EXISTS, IN, and table joins. Depending on your data one or another may be faster.
  Note: IN is usually the slowest.
  Note: When most of the filter criteria are in the sub-query IN may be more efficient; when most of the filter criteria are in the parent-query EXISTS may be more efficient.
  The following queries return the employee names from each department in department category ‘A’:
  SELECT emp_name FROM emp E WHERE EXISTS (SELECT ‘X’ FROM dept WHERE dept_no = E.dept_no AND dept_cat = ‘A’);
  ———————————————
  SELECT emp_name FROM emp E WHERE dept_no IN (SELECT dept_no FROM dept WHERE dept_no = E.dept_no AND dept_Cat = ‘A’);
  ———————————————
  SELECT emp_name FROM dept D, emp E WHERE E.dept_no = D.dept_no AND D.dept_cat = ‘A’;
• Where possible use EXISTS rather than DISTINCT, to avoid full table scan as DISTINCT operator causes Oracle to fetch all rows satisfying the table join and then sort and filter out duplicate values. EXISTS is a faster alternative, because the Oracle optimizer realizes when the subquery has been satisfied once, there is no need to proceed further and the next matching row can be fetched.
  Use:
  SELECT S.id, S.description FROM small_table S WHERE EXISTS (SELECT NULL FROM big_table B WHERE B.id = S.id);
  Rather than:
  SELECT DISTINCT S.id, S.description FROM small_table S, big_table B
  WHERE S.id = B.id;
• Where possible use a non-column expression (putting the column on one side of the operator and all the other values on the other). Non-column expressions are often processed earlier thereby speeding the query.
  Use:
  WHERE SALES < 1000/(1 + n);
  Rather than:
  WHERE SALES + (n * SALES) < 1000;
• Where possible use UNION ALL rather than using UNION. The UNION clause forces all rows retuned by each portion of the UNION to be sorted and merged and duplicates to be filtered out before the first row is returned. A UNION ALL simply returns all rows including duplicates and does not have to perform any sort, merge or filter. If your tables are mutually exclusive(include no duplicate records), or you don’t care if duplicates are returned, the UNION ALL is much more efficient.
  USE:
  SELECT acct_num, balance_amt FROM debit_transactions WHERE tran_date = ’31-DEC-95′
  UNION ALL
  SELECT acct_num, balance_amt FROM credit_transactions WHERE tran_date = ’31-DE -95′;
  Rather than:
  SELECT acct_num, balance_amt FROM debit_transactions WHERE tran_date = ’31-DEC-95′
  UNION
  SELECT acct_num, balance_amt FROM credit_transactions WHERE tran_date = ’31-DE -95′;
• Consider using DECODE to avoid having to scan the same rows repetitively or join the same table repetitively. Note, DECODE is not necessarily faster as it depends on your data and the complexity of the resulting query. Also, using DECODE requires you t change your code when new values are allowed in the field.
  USE:
  SELECT COUNT(DECODE(status,’Y',’X',NULL)) Y_count,
  COUNT(DECODE(status,’N',’X',NULL)) N_count
  FROM emp WHERE emp_name LIKE ‘SMITH%’;
  Raher than:
  SELECT COUNT(*) FROM emp WHERE status = ‘Y’ AND emp_name LIKE ‘SMITH%’;
  ———————
  SELECT COUNT(*) FROM emp WHERE status = ‘N’ AND emp_name LIKE ‘SMITH%’;
• Oracle automatically performs simple column type conversions(or casting) when it compares columns of different types. Depending on the type of conversion, indexes may not be used. Make sure you declare your program variables as the same type as your Oracle columns, if the type is supported in the programming language you are using.
  Use:
  SELECT emp_no, emp_name, sal FROM emp WHERE emp_no = ’123′;
  HERE if emp_no indexed numeric, then after implicit conversion query will be:
  SELECT emp_no, emp_name, sal FROM emp WHERE emp_no = TO_NUMBER(’123′);
  Thus, index is used in this case.
  Don’t use:
  SELECT emp_no, emp_name, sal FROM emp WHERE emp_type = 123;
  HERE if emp_type is indexed varchar2, then after implicit conversion query will be:
  SELECT emp_no, emp_name, sal FROM emp WHERE TO_NUMBER(emp_type) = 123;
  Thus, index will not be used in this case.
• The most efficient method for storing large binary objects, i.e. multimedia objects, is to place them in the file system and place a pointer in the DB.
• B-Tree Indexes do not store entries for NULL, so IS NULL is not indexable, but IS NOT NULL is indexable and thus if a huge table contains very few not null values then you should go for B-Tree indexes. On the other hand bitmap indexes support IS NULL condition.
  SELECT * FROM big WHERE status IS NOT NULL; (Use B-tree index in this case)
• Avoid using functions on indexed columns unless a function-based index is created; as it leads to full table scan even though index exists on the column.

Avoid using the following:

• Boolean operators >, <, >=, <=, IS NULL, IS NOT NULL
• NOT IN, !=
• Like ‘%pattern’, not exists
• Calculations on unindexed columns or (use union instead)
• Having (use a WHERE clause instead when appropriate)

Do use the following:

• Enable aliases to prefix all columns
• Place indexed columns higher in the WHERE clause
• Use SQL Joins instead of using sub-queries
• Make the table with the least number of rows, the driving table, by making it first in the FROM clause

Other important points for SQL Tuning

• Establish a tuning environment that reflects your production database
• Establish performance expectations before you begin
• Always Design and develop with performance in mind
• Create Indexes to support selective WHERE clauses and join conditions
• Use concatenated indexes where appropriate
• Consider indexing more than you think you should, to avoid table lookups
• Pick the best join method
• Nested loops joins are best for indexed joins of subsets
• Hash joins are usually the best choice for “big” joins
• Pick the best join order
• Pick the best “driving” table
• Eliminate rows as early as possible in the join order
• Use bind variables. Bind variables are key to application scalability
• Use Oracle hints where appropriate
• Compare performance between alternative syntax for your SQL statement
• Consider utilizing PL/SQL to overcome difficult SQL tuning issues
• Consider using third party tools to make the job of SQL tuning easier

Performing these steps is easy and provides a tremendous benefit and performance boost. Follow these simple steps and you can increase your system performance.

Using SQL*Plus

SQL*Plus is a command-line tool that provides access to the Oracle RDBMS.

SQL*Plus enables you to:

• Enter SQL*Plus commands to configure the SQL*Plus environment
• Startup and shutdown an Oracle database
• Connect to an Oracle database
• Enter and execute SQL commands and PL/SQL blocks
• Format and print query results

SQL*Plus is available on several platforms. In addition, it has a web-based user

interface, iSQL*Plus.

SQL*Plus is a client terminal software allowing users to interact with Oracle server to manipulate data and data structures. Users type in SQL statements in SQL*Plus that send statements to Oracle server. Oracle server then validates and executes the statements on its databases. The query results are returned to SQL*Plus and displayed to the user.  Besides sending SQL statements to the server, SQL*Plus also saves them into a local buffer and allow users to view and change the statements. The following figure illustrates the process.

After you login into SQL*Plus, at the SQL prompt, you can begin typing any SQL command. Upon hitting return (i.e., enter key) the SQL prompt will change to line number prompts. When you are finished typing a command, type / or RUN to execute the SQL command. Also, a semicolon at the end of the SQL command will execute the command immediately after hitting return. In addition to SQL commands, /, and RUN, you can also executes SQL*Plus file commands.

SQL*PLUS Commands Quick Reference

Below table shows, SQL*Plus commands available in the command-line interface. Not all commands or command parameters are shown.

SQL*Plus file command allow you to execute commands (or programs) stored in an external file, input or output data from/to a file, and save SQL commands typed during current session.

Some SQL*Plus file commands are:

• SAVE filename. This allows you to save buffer contents into a file.
• START filename. This allows you to execute a batch of SQL statements stored in a file.
• SPOOL filename. This allows you save SQL statements together with their outputs to a file.
• GET filename. This retrieve a file and places it into the buffer.
• @ filename. This allows you to execute a PL/SQL procedure(s) stored in a file.

Recall that the previously executed commands (in current SQL*Plus session) are stored in the local buffer. One way to change an SQL statement in the buffer is by using the line editor. The following are a list of line edit commands.

• LIST or L–Lists the contents of the buffer
• LIST n or L n–Lists the contents of line number n in the buffer and makes the line current
• LIST * or L *–Lists the current line
• LIST m n–Lists the range from m to n line
• Append text or A text–Adds to the end of the current line (e.g., “A ,” adds a comma to the end of line
• INPUT or I–Adds one or more lines after the current line so you can begin adding the text.
• CHANGE /text–Deletes text from the current line
• CHANGE /oldtext/newtext–Replaces oldtext with newtext in the current line
• DEL — Deletes the current line

Besides line editor, you can also use the vi editor if you are a fan of Unix editor!.

To invoke the vi editor, type Edit at the SQL Prompt.   Multiple SQL commands can be typed in vi editor. End each SQL command (except the last one) with a semicolon. After exiting notepad, type Start to run all of the commands.

Run SQL statements in a batch

To run SQL commands in a batch, you can put all your SQL commands into a text file and execute these commands in this file in SQL*PLUS.

• Use your favorite editor to type in your SQL queries into a text file.

For Example,

$ more table.sql
DROP TABLE employee
/

commit
/

CREATE TABLE employee (
empno INTEGER NOT NULL,
name VARCHAR2(50) NOT NULL,
sal REAL NOT NULL,
primary key (empno));
/

INSERT INTO employee VALUES (1, ‘Jack’, 6000);
INSERT INTO employee VALUES (2, ‘Tom’,  6000);
INSERT INTO employee VALUES (3, ‘John’, 6000);
INSERT INTO employee VALUES (4, ‘Jane’, 6000);
/

UPDATE employee SET sal=500 WHERE name=’Jack’
/

CREATE INDEX test_index on employee(sal)
/
$

• Connect into SQL*Plus, and run the batch of commands. For example, assume that you name the SQL file as table.sql.

SQL> START table.sql;

Output results

• You can record your SQL command outputs to a file for output or editing purpose.

SQL> SPOOL <your file name>

For example,

SQL> SPOOL myoutput.out

All SQL commands and their outputs after this command are written into the file myoutput.out that by default is stored in the current working directory where you invoked SQL*Plus.

• To end recording, use the following command:

SQL> SPOOL OFF

DUAL and select the current time

DUAL is the dummy table, mostly used to view the results from functions and calculations. The built-in function SYSDATE returns a DATE value containing the current date and time on your system. (Note Oracle is a client-server architecture and SQL*Plus is the client. SYSDATE gives you the time of the Unix system which you telnet in. It may NOT be the time of Oracle server unless you telnet into the machine running Oracle server.)

For example,

SQL> SELECT TO_CHAR(SYSDATE , 'Dy DD-Mon-YYYY HH24:MI:SS') as "Current Date/Time" FROM DUAL;;

Result:

Current Time

------------------------------------------------------------------------

Mon 15-July-2002 10:01:29

• TO_CHAR is a function to format a value.
• DUAL is built-in relation in Oracle which serves as a dummy relation to put in the FROM clause when nothing else is appropriate. For example, try “SELECT 2+2 FROM DUAL;”
• To format a number attribute to a dollar format, use the column <attribute> format <format>:

       SQL> COLUMN salary FORMAT $999,999

• To indicate the displayed width of a character string attribute, use the column <attribute> format <A’format>. For example, set the width of the name attribute to 8 characters.

       SQL> COLUMN name FORMAT A8

If a name is longer than 8 characters, the remaining is displayed at the second line (or several lines)

• The set command can be used to change the default number of lines per page (14) and the number of characters per line (80).

For example, to set the number of lines per page to 60, use the following command:

   SQL> SET PAGESIZE 60

• All formatting remain active until they are cleared or reset or after you exit from SQL*Plus.

   SQL> CLEAR COLUMN

• If you forget a specific SQL command you could enter

SQL> HELP <the SQL command>;

You could also find out all commands by entering:

SQL> HELP menu;

• Sometimes when you get something fuzzy, you  can try the following

SQL> SET SERVEROUTPUT ON
SQL> SET ARRAYSIZE 1