There are two forms of code documentation: external and internal. External documentation is descriptive information about a program which is written and stored separately from the program itself. Internal documentation, also known as inline documentation or comments, is placed within the program itself, either at the program level or the statement level.
The best kind of internal documentation derives from your programming style. If you apply [my] guidelines, you will be able to write code which is, to a great extent, self-documenting.

Best practice for documentation is:

1. Write code in a style that is self-documenting.
2. To the extent that is not possible, then keep the documentation internal to the program itself, in the form of comments.
3. Only if that is also not possible, should you resort to external documentation. In that case keep the external documentation easily accessible by URL and state that URL inside the program comments (and/or display in the application front end).

Ideally, the only external documentation needed is the high level overview containing just:

1. Server name(s)
2. Database name(s)
3. Owner username(s)
4. Details of where to find password(s) – e.g. full path details of a KeePass encrypted file.
5. Any helpful visio-style diagrams

The most important set of comments is this initial set – and this should appear in every piece of code you write:

CREATE OR REPLACE PROCEDURE myowner.myprocedure AS
/***************************
|| Name :
|| Author :
|| Date :
|| Purpose :
|| Change History :
||     date author refno description
***************************/

Of those fields, author is the most important.

Counter-intuitively, simple short programs actually need that header info more than long programs – because you can more often work out the purpose of long programs by reading through their code.

Focus on the why, not the what.

Packages should have these comments in the package body, not the package header, because the body is more often modified and contains the most code.

Views need commented just as much as pl/sql. But their comments need to go after the select keyword:

create or replace [materialized] view myowner.myview as select
/***************************
|| Name :
|| Author :
|| Date :
|| Purpose :
|| Change History :
***************************/

Triggers and functions also should be commented with the some format. As should any SQL script files and shell script files.

For SQL script files, set doc off first to avoid having the comments echoed out to screen every time the script is run:

set doc off
/***************************
|| Name :

Shell scripts should follow the same comment format as sql, except for ‘#’ symbols:

##############################
# Name :
# Author :
# Date :
# Purpose :
# Change History :
##############################

PHP files also should have the same initial comment block, except marking lines with * is more standard for php:

/***************************
* Name :
* Author :
* Date :
* Purpose :
* Change History :
***************************/

Functions and subroutines, whether in php, shell, or pl/sql package bodies, should each get their own introductory comment block – although without the change history, because that is best maintained in the overall initial comment block.

Oracle Forms screens should all have that same initial comment block placed in their when-new-form-instance trigger. If necessary, add the when-new-form-instance trigger purely to contain that comment block. And again each program unit within the form would also get its own introductory comment block.

alter session set nls_date_format = 'Dy DD-Mon-YYYY AD' ;
select sysdate, to_date('01-JAN-4712 BC','DD-MON-YYYY AD'), to_date('30-DEC-9999 AD','DD-MON-YYYY AD') from dual ;

Without encountering this error:

ORA-01841: (full) year must be between -4713 and +9999, and not be 0
01841. 00000 – “(full) year must be between -4713 and +9999, and not be 0″
*Cause: Illegal year entered
*Action: Input year in the specified range

But for processes running from cron, I found I had to additionally make the below changes (this is on old version: 32 bit Linux 2.4.21-27.ELsmp Red Hat Enterprise Linux AS release 3 (Taroon Update 4) – maybe not needed for newer versions).

vi /etc/init.d/crond

Add lines like:

ulimit -Hu 131072  # new line Jul 2011
ulimit -Su 131072  # new line Jul 2011
ulimit -Hn 262144  # new line Jul 2011
ulimit -Sn 262144  # new line Jul 2011

These should be the first commands in that file.

Restart cron with:

/etc/init.d/crond restart

Not relevant for cron, but file /etc/profile is loaded at login and may have been edited to contain ulimit settings – if so those lines would need changed or removed for normal (non cron) logins.

Thanks to Michael Heiming for this.

SQL> select password from dba_users where username = 'MYUSER';

PASSWORD
------------------------------
086FAA387C794B46

SQL> alter user MYUSER identified by mypassword ;

User altered.

SQL> conn MYUSER/mypassword
Connected.
SQL> alter user MYUSER identified by values '086FAA387C794B46';

User altered.

SQL> sho user
USER is "MYUSER"

The above works for versions up to 10g. For 11g, instead use:

SQL> set long 9999
SQL> select dbms_metadata.get_ddl ('USER', 'MYUSER') from dual ;

Source: Laurent Schneider.

SQL> alter system set pga_aggregate_target=1g comment='Andrew Fraser 13-May-2010 was 390m'  scope=spfile sid='*' ;

alter session set nls_date_format='Dy DD-Mon-YYYY HH24:MI:SS';

Then in Oracle SQL Developer, right click on the table or object in question, select ‘open‘, and look at the ‘details‘ tab.

Or alternatively still in SQL, look at the created column:

select object_name, created from user_objects order by 2;

That is for objects owned by you. For objects owned by others:

select object_name, created from all_objects order by 2;

Note that the column ‘last_ddl_time’ is not as useful as it sounds, since even operations like GRANTs on the table update the ‘last_ddl_time’.