Ed Stevens, DBA

Allocation of extents in multi-file tablespaces

Ed Stevens — Wed, 01 Feb 2012 19:17:16 +0000

A recurring question I see has to do with the allocation of extents in tablespaces with multiple data files. The question is, does oracle completely fill one data file before beginning to use the next, or does it use the files in a balanced, round-robin fashion? Various resources give conflicting answers. A few years ago I put together a test to discover for myself how Oracle handles this. I’ve pulled that test (which was originally run on Oracle 9.2) out of my archives and tried it again on 11.2. Here are the results and observations along the way.

First, we’ll create a tablespace with three small datafiles, create a table, and populate it to force multiple extents.


SQL> create SMALLFILE tablespace bubba_ts
  2      datafile '/ora01/oradata/ORCL/bubbatbs_01.dbf'
  3         size 1m
  4         autoextend off,
  5       '/ora01/oradata/ORCL/bubbatbs_02.dbf'
  6         size 1m
  7         autoextend off,
  8       '/ora01/oradata/ORCL/bubbatbs_03.dbf'
  9         size 1m
 10         autoextend off
 11       EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K;

Tablespace created.

SQL> create user bubba
  2       identified by bubbapw
  3       default tablespace bubba_ts
  4       temporary tablespace temp
  5       quota unlimited on bubba_ts;

User created.

SQL> --
SQL> create table bubba.rowid_test
  2       (
  3       key_col number,
  4       big_col1 char(2000),
  5       big_col2 char(2000),
  6       big_col3 char(2000)
  7       );

Table created.

SQL> --
SQL> BEGIN
  2  for i in 1..100 loop
  3     insert into bubba.rowid_test
  4        values (i,
  5        'xxxxx',
  6        'xxxxx',
  7        'xxxxx'
  8        );
  9  end loop;
 10  END;
 11  /

PL/SQL procedure successfully completed.

Fig. 1

Next, we’ll simply look at where each row was created. The list is lengthy, but as you scroll down, it becomes apparent that Oracle used the files in a ’round-robin’ fashion.

SQL> declare
  2    r   rowid;
  3    i   number := 1;
  4    v_file_name dba_data_files.file_name%type;
  5  begin
  6
  7    for p in (
  8   select rowid
  9     from bubba.rowid_test
 10   ) loop
 11
 12    select file_name
 13    into v_file_name
 14    from dba_data_files
 15    where file_id = dbms_rowid.rowid_to_absolute_fno(p.rowid, 'BUBBA', 'ROWID_TEST');
 16
 17
 18    dbms_output.put_line('row no: ' || i ||'  file    : ' || v_file_name);
 19
 20   i := i+1;
 21    end loop;
 22  end;
 23  /
row no: 1  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 2  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 3  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 4  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 5  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 6  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 7  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 8  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 9  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 10  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 11  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 12  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 13  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 14  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 15  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 16  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 17  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 18  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 19  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 20  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 21  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 22  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 23  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 24  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 25  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 26  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 27  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 28  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 29  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 30  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 31  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 32  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 33  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 34  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 35  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 36  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 37  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 38  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 39  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 40  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 41  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 42  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 43  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 44  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 45  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 46  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 47  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 48  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 49  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 50  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 51  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 52  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 53  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 54  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 55  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 56  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 57  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 58  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 59  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 60  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 61  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 62  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 63  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 64  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 65  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 66  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 67  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 68  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 69  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 70  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 71  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 72  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 73  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 74  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 75  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 76  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 77  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 78  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 79  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 80  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 81  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 82  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 83  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 84  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 85  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 86  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 87  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 88  file    : /ora01/oradata/ORCL/bubbatbs_03.dbf
row no: 89  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 90  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 91  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 92  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 93  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 94  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 95  file    : /ora01/oradata/ORCL/bubbatbs_01.dbf
row no: 96  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 97  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 98  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 99  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 100  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
PL/SQL procedure successfully completed.

Fig. 2

And finally, another check of simply the extents allocation. Again, it is easy to see the round-robin usage/allocation pattern

SQL> select e.extent_id,
  2      e.file_id,
  3      f.file_name
  4  from dba_extents e,
  5    dba_data_files f
  6  where e.owner = 'BUBBA'
  7  and   e.segment_name = 'ROWID_TEST'
  8  and   e.file_id = f.file_id
  9  order by e.extent_id
 10  ;

 EXTENT_ID    FILE_ID FILE_NAME
---------- ---------- -----------------------------------
 0                  8 /ora01/oradata/ORCL/bubbatbs_01.dbf
 1                  9 /ora01/oradata/ORCL/bubbatbs_02.dbf
 2                 10 /ora01/oradata/ORCL/bubbatbs_03.dbf
 3                  8 /ora01/oradata/ORCL/bubbatbs_01.dbf
 4                  9 /ora01/oradata/ORCL/bubbatbs_02.dbf
 5                 10 /ora01/oradata/ORCL/bubbatbs_03.dbf
 6                  8 /ora01/oradata/ORCL/bubbatbs_01.dbf
 7                  9 /ora01/oradata/ORCL/bubbatbs_02.dbf
 8                 10 /ora01/oradata/ORCL/bubbatbs_03.dbf
 9                  8 /ora01/oradata/ORCL/bubbatbs_01.dbf
10                  9 /ora01/oradata/ORCL/bubbatbs_02.dbf
11                 10 /ora01/oradata/ORCL/bubbatbs_03.dbf
12                  8 /ora01/oradata/ORCL/bubbatbs_01.dbf
13                  9 /ora01/oradata/ORCL/bubbatbs_02.dbf

14 rows selected.

SQL> --

Fig. 3

However, notice that when I created the tablespace, I used “EXTENT MANAGEMENT LOCAL UNIFORM SIZE”. Let’s change that to “EXTENT MANAGEMENT AUTOALLOCATE” and observe the difference:

SQL> create SMALLFILE tablespace bubba_ts
  2      datafile '/ora01/oradata/ORCL/bubbatbs_01.dbf'
  3         size 1m
  4         autoextend off,
  5       '/ora01/oradata/ORCL/bubbatbs_02.dbf'
  6         size 1m
  7         autoextend off,
  8       '/ora01/oradata/ORCL/bubbatbs_03.dbf'
  9         size 1m
 10         autoextend off
 11       EXTENT MANAGEMENT LOCAL autoallocate;

Tablespace created.

Fig. 4

After repeating the same data load procedure as before, the queries to see the usage pattern now show we’ve only used one datafile:

SQL> declare
  2    r   rowid;
  3    i   number := 1;
  4    v_file_name dba_data_files.file_name%type;
  5  begin
  6
  7    for p in (
  8   select rowid
  9     from bubba.rowid_test
 10   ) loop
 11
 12    select file_name
 13    into v_file_name
 14    from dba_data_files
 15    where file_id = dbms_rowid.rowid_to_absolute_fno(p.rowid, 'BUBBA', 'ROWID_TEST');
 16
 17
 18    dbms_output.put_line('row no: ' || i ||'  file    : ' || v_file_name);
 19
 20   i := i+1;
 21    end loop;
 22  end;
 23  /
row no: 1  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 2  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 3  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 4  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 5  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 6  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 7  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 8  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 9  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 10  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 11  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 12  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 13  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 14  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 15  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 16  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 17  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 18  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 19  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 20  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 21  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 22  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 23  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 24  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 25  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 26  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 27  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 28  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 29  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 30  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 31  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 32  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 33  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 34  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 35  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 36  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 37  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 38  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 39  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 40  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 41  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 42  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 43  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 44  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 45  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 46  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 47  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 48  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 49  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 50  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 51  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 52  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 53  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 54  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 55  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 56  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 57  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 58  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 59  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 60  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 61  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 62  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 63  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 64  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 65  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 66  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 67  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 68  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 69  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 70  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 71  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 72  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 73  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 74  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 75  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 76  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 77  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 78  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 79  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 80  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 81  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 82  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 83  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 84  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 85  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 86  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 87  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 88  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 89  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 90  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 91  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 92  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 93  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 94  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 95  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 96  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 97  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 98  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 99  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf
row no: 100  file    : /ora01/oradata/ORCL/bubbatbs_02.dbf

PL/SQL procedure successfully completed.

SQL> /*
SQL> =========================================== */
SQL> --
SQL> col file_name for a35
SQL> select e.extent_id,
  2      e.file_id,
  3      f.file_name
  4  from dba_extents e,
  5    dba_data_files f
  6  where e.owner = 'BUBBA'
  7  and   e.segment_name = 'ROWID_TEST'
  8  and   e.file_id = f.file_id
  9  order by e.extent_id
 10  ;

 EXTENT_ID    FILE_ID FILE_NAME
---------- ---------- -----------------------------------
         0          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
         1          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
         2          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
         3          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
         4          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
         5          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
         6          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
         7          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
         8          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
         9          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
        10          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
        11          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
        12          9 /ora01/oradata/ORCL/bubbatbs_02.dbf
        13          9 /ora01/oradata/ORCL/bubbatbs_02.dbf

14 rows selected.

Fig. 5

Conclusions

So, in this case, as in most things dealing with databases in general and Oracle in particular, the answer is “It depends”. At least with the variables I was controlling for, it depends on if the tablespace is defined as UNIFORM extents, or AUTOALLCOATE extents. I have not explored the behavior with dictionary managed tablespaces simply because they were rendered obsolete by the use of locally managed tablespaces. Anyone still using dictionary managed tablespaces needs to be more concerned about migrating to locally managed than how oracle manages those obsolete structures.

Exploring password lifetime and grace period

Ed Stevens — Mon, 16 Jan 2012 16:22:48 +0000

Some time back I began to get an odd complaint from some of my end users. It seems that when they connected to the Oracle database, they received a warning that their password was about to expire, and yet never – even after the password grace period had passed – received a prompt to change their password.

Normal and expected behavior would have been for them to start receiving this message when they reached their expiry date and continue to receive it until they reached the end of the grace period, at which time they would be forced to enter a new password. So why were they never prompted/forced for a new password? A check of a typical account showed they had an EXPIRY_DATE of null. I thought this was odd, but being pressed for time, simply expired the account (ALTER USER joe ACCOUNT EXPIRE;), had the user change passwords, and checked that they had a new, valid EXPIRY_DATE. Thinking I had the fix, I ran a script to expire all users with an EXPIRY_DATE of null, and moved on.

Then a couple of months later one of my primary users again mentioned that he was being warned about an expiring password, but never prompted to change. Since I knew for a fact I had fixed this problem for him (he was my test case) I decided to dig a bit deeper. What I found was that under normal circumstances, the first time a user connects after reaching their EXPIRY_DATE, their status changes from OPEN to EXPIRED(GRACE), and EXPIRY_DATE is reset to sysdate + grace period. If the grace period is default/unlimited, sysdate + grace period means the new EXPIRY_DATE will be null. Now when the user connects, Oracle sees his status is EXPIRED(GRACE), so triggers the warning, but the comparison of sysdate to EXPIRY_DATE (null) never evaluates to TRUE, so never triggers the forcing of a password change.

While I always knew in general terms what PASSWORD_LIFETIME and PASSWORD_GRACE_TIME were all about, I had never really thought through all the implications of the relationships, especially if one was set and the other defaulted. So allow me to put up a clear demonstration:

I’ll start with a base line and demonstrate normal, expected behavior. Then I’ll recreate my problem and show how it plays out in terms of the user account status and dates. My test system is Oracle 11.2 Enterpirse, running on Oracle Linux 5 under VMworkstation on my Win 7 Home Premium laptop. I can “accelerate” time forward to reach expiration dates by simply having the root user change the system time.

First, set the default profile. I’ll set the lifetime and grace period differently so that we can see which one is working to set new EXPIRY_DATEs:

[oracle@vmlnxsrv01 sql]$ sqlplus system/halftrack

SQL*Plus: Release 11.2.0.1.0 Production on Mon Jan 16 08:50:56 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter profile DEFAULT limit
  2     PASSWORD_LIFE_TIME 2
  3     PASSWORD_GRACE_TIME 3;

Profile altered.

SQL>

Fig. 1

Next, create a user, check his account, and also check the current date

SQL> drop user joe;

User dropped.

SQL> create user joe identified by joe;

User created.

SQL> grant create session to joe;

Grant succeeded.

SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from dba_users
  6  where username='JOE'
  7  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      OPEN            18-JAN-2012 08:51:50 16-JAN-2012 08:51:50

1 row selected.

SQL>

Fig. 2

Just as expected, EXPIRY_DATE is two days from today, so Joe should be able to connect with no surprises:

SQL> conn joe/joe
Connected.
SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from user_users
  6  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      OPEN            18-JAN-2012 08:51:50 16-JAN-2012 08:53:01

1 row selected.

SQL>

Fig. 3

Now let’s set the clock forward to the EXPIRY_DATE and have Joe connect again

[oracle@vmlnxsrv01 sql]$ sqlplus joe/joe

SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 18 08:00:19 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from user_users
  6  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      OPEN            18-JAN-2012 08:51:50 18-JAN-2012 08:00:35

1 row selected.

SQL>

Fig. 4

So it appears we have to go PAST the EXPIRY_DATE (down to the second) to trigger anything:

[oracle@vmlnxsrv01 sql]$ sqlplus joe/joe

SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 18 08:52:22 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

ERROR:
ORA-28002: the password will expire within 3 days

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from user_users
  6  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      EXPIRED(GRACE)  21-JAN-2012 08:52:22 18-JAN-2012 08:52:28

1 row selected.

SQL>

Fig. 5

Notice that joe was allowed to connect, but received a warning. Also notice that his status has change to EXPIRED(GRACE), and the EXPIRY_DATE has changed to sysdate + grace period (3 days).

Now let’s move forward past the new EXPIRY_DATE.

[oracle@vmlnxsrv01 sql]$ sqlplus joe/joe

SQL*Plus: Release 11.2.0.1.0 Production on Sat Jan 21 09:00:27 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

ERROR:
ORA-28001: the password has expired

Changing password for joe
New password:
Retype new password:
Password changed

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from user_users
  6  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      OPEN            23-JAN-2012 09:00:32 21-JAN-2012 09:00:59

1 row selected.

SQL>

Fig. 6

Joe is prompted for a new password, his status is set back to OPEN, and EXPIRY_DATE is set to sysdate + password lifetime (2 days) All is well with the world.

Now let’s set the grace period to unlimited and run the test again.

[oracle@vmlnxsrv01 sql]$ sqlplus system/halftrack

SQL*Plus: Release 11.2.0.1.0 Production on Mon Jan 23 09:07:16 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter profile DEFAULT limit
  2     PASSWORD_LIFE_TIME 2
  3     PASSWORD_GRACE_TIME unlimited;

Profile altered.

SQL> drop user joe;

User dropped.

SQL> create user joe identified by joe;

User created.

SQL> grant create session to joe;

Grant succeeded.

SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from dba_users
  6  where username='JOE'
  7  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      OPEN            25-JAN-2012 09:07:20 23-JAN-2012 09:07:20

1 row selected.

SQL> conn joe/joe
Connected.
SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from user_users
  6  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      OPEN            25-JAN-2012 09:07:20 23-JAN-2012 09:07:20

1 row selected.

SQL>

Fig. 7

Move the date to a point after current EXPIRY_DATE, and test Joe again

[oracle@vmlnxsrv01 sql]$ sqlplus joe/joe

SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 25 09:08:29 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

ERROR:
ORA-28011: the account will expire soon; change your password now

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from user_users
  6  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      EXPIRED(GRACE)                       25-JAN-2012 09:08:47

1 row selected.

SQL>

Fig. 8

Notice a couple of things in this test.

First, while the account status is “EXPIRED(GRACE)” (just like the earlier scenario), since there was no specific grace period, there was nothing to set EXPIRY_DATE to, except NULL.

Second, the message changed from “ORA-28002: the password will expire within n days” to “ORA-28011: the account will expire soon; change your password now”. And since the EXPIRY_DATE is null, we can never reach a point where the difference between sysdate and EXPIRY_DATE will be any different than it is now. The user will get this message until either the DBA forces it expired, or until he changes his password on his own.

Let’s have the DBA do it

[oracle@vmlnxsrv01 sql]$ sqlplus system/halftrack

SQL*Plus: Release 11.2.0.1.0 Production on Wed Jan 25 09:10:16 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter user joe password expire;

User altered.

SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from dba_users
  6  where username='JOE'
  7  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      EXPIRED         25-JAN-2012 09:10:20 25-JAN-2012 09:10:20

1 row selected.

SQL>

Fig. 9

So now the account status is simply ‘EXPIRED”. Next time joe connects, he has to change his password:

SQL> conn joe/joe
ERROR:
ORA-28001: the password has expired

Changing password for joe
New password:
Retype new password:
Password changed
Connected.
SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from user_users
  6  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      OPEN            27-JAN-2012 09:11:28 25-JAN-2012 09:11:32

1 row selected.

SQL>

Fig. 10

Now I’ll change the system date to force Joe back into limbo

[oracle@vmlnxsrv01 sql]$ sqlplus joe/bob

SQL*Plus: Release 11.2.0.1.0 Production on Fri Jan 27 09:58:19 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

ERROR:
ORA-28011: the account will expire soon; change your password now

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from user_users
  6  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      EXPIRED(GRACE)                       27-JAN-2012 09:58:24

1 row selected.

SQL> password
Changing password for JOE
Old password:
New password:
Retype new password:
Password changed

SQL> select  username
  2  ,       account_status
  3  ,       expiry_date
  4  ,       sysdate
  5  from user_users
  6  ;

USERNAME ACCOUNT_STATUS  EXPIRY_DATE          SYSDATE
-------- --------------- -------------------- --------------------
JOE      OPEN            29-JAN-2012 10:00:05 27-JAN-2012 10:00:10

1 row selected.

SQL>

Fig. 11

Lessons Learned

I learned several lessons from this exercise. And the most important lessons had more to do with human failings than technology.

Lesson One

First, no matter how much you think you understand something, when presented with a problem, you should always read and research the actual error message. If I had done that, I would have seen this:

[oracle@vmlnxsrv01 ~]$ oerr ORA 28011
28011, 00000, "the account will expire soon; change your password now"
// *Cause:   The user's account is marked for expiry; the expiry period
//           is unlimited.
// *Action:  Change the password or contact the DBA.
[oracle@vmlnxsrv01 ~]$

Fig. 12

Of course that would have still left me wondering why the expiry period was unlimited. Which leads to lesson #2

Lesson Two

No matter how well you think you understand something, it never hurts to review the documentation – AGAIN!

If I had heeded that lesson, I would have looked up CREATE PROFILE in the SQL Reference Manual, and found this nugget:

PASSWORD_LIFE_TIME Specify the number of days the same password can be used for authentication. If you also set a value for PASSWORD_GRACE_TIME, the password expires if it is not changed within the grace period, and further connections are rejected. If you do not set a value for PASSWORD_GRACE_TIME, its default of UNLIMITED will cause the database to issue a warning but let the user continue to connect indefinitely.

Note that the above is from the 10.2 SQL Reference. My production database is running 10.2.0.5. In setting up this demo I was using my personal test database, which is running 11.2, and in working out some anomalies, discovered that the behavior changed from 10.2 to 11.2. Specifically, the default value of PASSWORD_GRACE_TIME changed from UNLIMITED in 10g to 7 days in 11g. See the Oracle® Database 2 Day + Security Guide, “Using the Default Security Settings”. See http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_install_config.htm#TDPSG60066

Lesson Three

No matter how well you think you know your own system, always double check any settings or values involved in the problem at hand. I have no idea how my PASSWORD_GRACE_TIME got set to DEFAULT (which is UNLIMITED on my production 10g system). But until I made a point of checking it, I was shooting in the dark to get to the bottom of the problem.

Exploring the LOCAL_LISTENER parameter

Ed Stevens — Sat, 30 Jul 2011 22:18:54 +0000

In my previous post ORA-12514: TNS:listener does not currently know of service I mentioned the role of the initialization parm LOCAL_LISTENER in dynamic registration of the database instance to the listener. Now I’d like to deliver on my promise to explore that piece of the puzzle.

To quickly recap that post, there are two methods by which a listener comes to know of a database instance. In Oracle terminology, this is referred to as “registering with the listener.”

Static Instance Registration

The first – and older – method is static registration. In this method, the instance is listed in the SID_LIST section of the listener’s configuration file, “listener.ora”. Such a registration would show in the listener.ora like this:

[oracle@lnxsrv01 admin]$ cat listener.ora
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /ora00/app/oracle/product/11.2.0/db_1)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (GLOBAL_DBNAME=OKLACITY)
      (ORACLE_HOME = /ora00/app/oracle/product/11.2.0/db_1)
      (SID_NAME = OKLACITY)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = lnxsrv01.vmdomain)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
    )
  )
[oracle@lnxsrv01 admin]$

Fig. 1

And that static registration shows up in the listener status with a status of UNKNOWN:

[oracle@lnxsrv01 admin]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:20:48

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=lnxsrv01.vmdomain)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date                28-JUL-2011 20:20:42
Uptime                    0 days 0 hr. 0 min. 5 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /ora00/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Listener Log File         /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary...
Service "OKLACITY" has 1 instance(s).
  Instance "OKLACITY", status UNKNOWN, has 1 handler(s) for this service...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
[oracle@lnxsrv01 admin]$

Fig. 2

At Fig. 2, line 24, the status is UNKNOWN because there is no mechanism to guarantee that the specified instance even exists. The listener just assumes that the instance will be there when a connect request is received. In fact, my database was down when I took the status shown in Fig. 2.

Dynamic Instance Registration

With version 9.0 Oracle introduced the concept of dynamic registration. With this, it was no longer necessary to list the database instance in the listener.ora file. Instead, the database instance could contact the listener directly and register itself. We can observe the result of that in the listener status. First, I’ll “remove” my listner.ora by renaming it, then restart the listener and see what it says about itself. The listener is quite capable of running without a listner.ora file at all. It will simply start and run with all default values.

[oracle@lnxsrv01 admin]$ lsnrctl stop

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:21:56

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=lnxsrv01.vmdomain)(PORT=1521)))
The command completed successfully
[oracle@lnxsrv01 admin]$ mv listener.ora listener.sav
[oracle@lnxsrv01 admin]$ lsnrctl start

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:22:26

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Starting /ora00/app/oracle/product/11.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Log messages written to /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1521)))

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date                28-JUL-2011 20:22:26
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1521)))
The listener supports no services
The command completed successfully
[oracle@lnxsrv01 admin]$

Fig. 3

So we can see in Fig. 3, line 35 that the listener has started but supports no services. If we try to connect at this point we will get the ora-12514:

C:\>tnsping oklacity

TNS Ping Utility for 32-bit Windows: Version 11.2.0.1.0 - Production on 28-JUL-2
011 20:23:43

Copyright (c) 1997, 2010, Oracle.  All rights reserved.

Used parameter files:
C:\app\oracle\product\11.2.0\client_1\network\admin\sqlnet.ora


Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = lnxsrv01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = OKLACITY)))
OK (20 msec)

C:\>sqlplus scott/tiger@oklacity

SQL*Plus: Release 11.2.0.1.0 Production on Thu Jul 28 20:23:53 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

ERROR:
ORA-12514: TNS:listener does not currently know of service requested in connect
descriptor

Fig. 4

In Fig. 4, line 1, a tnsping proves that our tnsnames resolution is correct. But at line 23 we see that an actual attempt to connect to the service proves the listener doesn’t know anything about the service ‘OKLACITY’.

Now let’s start the instance and check again:

[oracle@lnxsrv01 admin]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Thu Jul 28 20:25:31 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  849530880 bytes
Fixed Size                  1347480 bytes
Variable Size             637534312 bytes
Database Buffers          205520896 bytes
Redo Buffers                5128192 bytes
Database mounted.
Database opened.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@lnxsrv01 admin]$
[oracle@lnxsrv01 admin]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:26:38

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date                28-JUL-2011 20:22:26
Uptime                    0 days 0 hr. 4 min. 12 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1521)))
Services Summary...
Service "OKLACITY" has 1 instance(s).
  Instance "OKLACITY", status READY, has 1 handler(s) for this service...
Service "OKLACITYXDB" has 1 instance(s).
  Instance "OKLACITY", status READY, has 1 handler(s) for this service...
The command completed successfully
[oracle@lnxsrv01 admin]$

Fig. 5

In Fig. 5 we observe that once the instance is started (line 9), when we re-check the listener (line 23) it now knows of service “OKLACITY”, with a status of READY (line 44). This obviously did not come from listener.ora as I had removed that file. Notice also that, unlike the static registration, this time the status is READY. The listener knows the instance is ready because the instance itself told the listener it was ready. And we can prove it by establishing a connection from a remote system:

C:\>sqlplus scott/tiger@oklacity

SQL*Plus: Release 11.2.0.1.0 Production on Thu Jul 28 20:26:49 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

Fig. 6

The LOCAL_LISTENER initialization parameter

So we’ve seen that the listener is able to start up and successfully handle connection requests without a listener.ora configuration file. It does this by using all defaults (including the listener name and port) and the database instance is able to register itself with the listener.

How does the instance know how to contact the listener in order to register itself? It uses the initialization parameter LOCAL_LISTENER. From the Oracle® Database Reference 11g Release 2 (11.2) we read

LOCAL_LISTENER specifies a network name that resolves to an address or address list of Oracle Net local listeners

Let’s see what my instance says about that …

SQL> show parameter local_listener

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
local_listener                       string
SQL>

Fig. 7

OK, so the instance is supposed to use LOCAL_LISTENER to locate the listener so that it (the instance) can register itself with the listener. But I don’t have LOCAL_LISTENER set to anything. Well, it so happens that LOCAL_LISTENER has a default value that dovetails nicely with the default settings of the listener. Again, from the Reference manual:

Default value: (ADDRESS = (PROTOCOL=TCP)(HOST=hostname)(PORT=1521)) where hostname is the network name of the local host.

I’ve seldom found a good reason NOT to run the listener with anything other the default name and port, but some people insist, and that’s when we need to adjust LOCAL_LISTENER to match up. So let’s set up a test case.

First, I’ll set my listener to use a non-default port. Notice I’ve also removed the SID_LIST section entirely.

[oracle@lnxsrv01 admin]$ cat listener.ora
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = lnxsrv01.vmdomain)(PORT = 1522))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
    )
  )
[oracle@lnxsrv01 admin]$ lsnrctl start

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:30:53

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Starting /ora00/app/oracle/product/11.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 11.2.0.2.0 - Production
System parameter file is /ora00/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Log messages written to /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date                28-JUL-2011 20:30:53
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /ora00/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Listener Log File         /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
The listener supports no services
The command completed successfully
[oracle@lnxsrv01 admin]$

Fig. 8

At this point my listener is up, listening on the non-default port of 1522 and knows of no services. With a default setup, I should be able to connect to the database and force a registration. Remember that at this point, my listener is using the non-default port of 1522, while the database is still trying to contact the listener on the default port of 1521.

[oracle@lnxsrv01 admin]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Thu Jul 28 20:31:50 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system register;

System altered.

SQL>

Fig. 9

I had expected this to return an error, but as you can see, it did not. I also could find no related errors in the alert log. But, as expected, the instance is not registered with the listener:

[oracle@lnxsrv01 admin]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:32:45

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date                28-JUL-2011 20:30:53
Uptime                    0 days 0 hr. 1 min. 52 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /ora00/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Listener Log File         /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
The listener supports no services
The command completed successfully
[oracle@lnxsrv01 admin]$

Fig. 10

In order to enable the instance to register with the non-default listener, we need to set LOCAL_LISTENER to an appropriate value. Remember from the documentation that “LOCAL_LISTENER specifies a network name that resolves to an address or address list of Oracle Net local listeners”. So let’s set it:

[oracle@lnxsrv01 admin]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Thu Jul 28 20:33:23 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system set LOCAL_LISTENER='(ADDRESS = (PROTOCOL=TCP)(HOST=lnxsrv01)(PORT=1522))' scope=both;

System altered.

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@lnxsrv01 admin]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:34:12

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date                28-JUL-2011 20:30:53
Uptime                    0 days 0 hr. 3 min. 19 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /ora00/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Listener Log File         /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary...
Service "OKLACITY" has 1 instance(s).
  Instance "OKLACITY", status READY, has 1 handler(s) for this service...
Service "OKLACITYXDB" has 1 instance(s).
  Instance "OKLACITY", status READY, has 1 handler(s) for this service...
The command completed successfully
[oracle@lnxsrv01 admin]$

Fig. 11

So by setting LOCAL_LISTENER to the values appropriate for the listener, it is again able to contact the listener and register its services.

Did it occur that the setting of LOCAL_LISTENER looks a lot like an entry in tnsnames.ora? Remember that the description of LOCAL_LISTENER “specifies a network name that resolves to an address …” (emphasis mine). As a matter of fact, we can use a tnsnames entry instead of hardcoding the address in LOCAL_LISTENER. To do this, we need to create a special entry in the tnsnames.ora file on the server, then set LOCAL_LISTENER to point to that entry. Unlike the usual tnsnames entry that points to a database service, this entry will point to the listener itself. (By the way, it is often said that the tnsnames.ora file is used only by client processes. This use of tnsames by the database instance is no exception. At this point the instance is acting in the role of a client, just as it does when using a database link to access data on another database.)

Let’s create the tnsnames entry, and test it with tnsping. I’ll add the entry FUBAR for this.

[oracle@lnxsrv01 admin]$ cat tnsnames.ora
# tnsnames.ora Network Configuration File: $ORACLE_HOME/network/admin

FUBAR =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = lnxsrv01.vmdomain)(PORT = 1522))
    )
  )

OKLACITY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = lnxsrv01.vmdomain)(PORT = 1522))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = OKLACITY)
    )
  )
[oracle@lnxsrv01 admin]$ tnsping fubar

TNS Ping Utility for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:37:00

Copyright (c) 1997, 2010, Oracle.  All rights reserved.

Used parameter files:


Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = lnxsrv01.vmdomain)(PORT = 1522))))
OK (10 msec)
[oracle@lnxsrv01 admin]$

Fig. 12

In reality I’d want to make the tnsnames alias something more meaningful, but here I wanted to use a name that would that would very obviously NOT be some reserved or default “magic” value. Notice that since FUBAR is used to locate the listener itself (rather than the services of a database instance) we do not need to include the CONNECT_DATA section.

Now that we have a tnsnames entry that points specifically to the listener, let’s prove it out.

First, we set LOCAL_LISTENER to reference the tnsnames.ora entry:

[oracle@lnxsrv01 admin]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Thu Jul 28 20:40:03 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system set local_listener='FUBAR' scope=both;

System altered.

SQL> show parameter local_listener

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
local_listener                       string      FUBAR
SQL>

Fig. 13

Next, I’ll restart the listener, in order to flush the current registrations and start clean.

SQL> !lsnrctl stop

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:41:19

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
The command completed successfully

SQL>
SQL> !lsnrctl start

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:41:48

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Starting /ora00/app/oracle/product/11.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 11.2.0.2.0 - Production
System parameter file is /ora00/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Log messages written to /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date                28-JUL-2011 20:41:48
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /ora00/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Listener Log File         /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
The listener supports no services
The command completed successfully

Fig. 14

Finally, I’ll force a registration of the instance, then recheck the listener status.

SQL> alter system register;

System altered.

SQL>
SQL> !lsnrctl status

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 28-JUL-2011 20:42:49

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date                28-JUL-2011 20:41:48
Uptime                    0 days 0 hr. 1 min. 1 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /ora00/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Listener Log File         /ora00/app/oracle/diag/tnslsnr/lnxsrv01/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lnxsrv01.vmdomain)(PORT=1522)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary...
Service "OKLACITY" has 1 instance(s).
  Instance "OKLACITY", status READY, has 1 handler(s) for this service...
Service "OKLACITYXDB" has 1 instance(s).
  Instance "OKLACITY", status READY, has 1 handler(s) for this service...
The command completed successfully

SQL>

Fig. 15

Conclusion

I’ve shown how it is possible for the listener to operate without the use of the listener.ora configuration file. I have also shown how the database instance registers itself with the listener with both default and non-default settings, and how the instance uses the LOCAL_LISTENER initialization parameter and the tnsnames.ora file to locate the listener for self-registration.

At this point I have covered just about the entire range of TNS configuration items that cause the vast majority of Oracle database connection issues. In previous posts I covered the “configuration chain” from the initial client connection request, through the network routing, through the listener, to the database instance. In this post I have shown the configuration issues that lead to the listener knowing what database instances it is supposed to be able to service. Hopefully, this series will be of help to those faced with the original question, “Why can’t I connect to my database?”

Create your own test system

Ed Stevens — Thu, 02 Jun 2011 16:29:32 +0000

I often see people afraid to try even the simplest of tasks on their Oracle databases, asking “Can I ?” When it is suggested they try for themselves and see what happens, the common excuse is “I don’t have a test system.”

Every oracle professional (or student) should have their own private computer lab. I’m assuming in this day and age anyone in this category already has their own computer. Starting from there, you should do the following:

1 – Go to vmware.com and download VMplayer. VMware freely distributes this so your cost so far is zero. If you are willing to invest about US$185 in your career, buy VMworkstation instead. It will give you some additional management features above what VMplayer has. Either product will allow you to create virtual machines on your personal computer.

1a – Install the VM product

2 – Go to oracle.com and download Oracle Enterprise Linux. Oracle freely distributes this, only charging if you want a support contract. As they also provide a free public yum server for distribution of most packages, even a support contract is not needed for your personal use.

2a – using your vmproduct and your downloaded linux, create a virtual linux machine.

3 – Go to oracle.com and download whatever db or related product you want. The terms of the oracle license agreement allow you the full use of any product for personal study.

By doing the above I have a full computer lab running on my Windows 7 laptop, for a total cost of US$185 – and even that cost was because I chose to upgrade my VM from VMplayer to VMworkstation. In this lab I have two linux servers running a DataGuard configuration, and a Windows Server 2003 server running a standalone Oracle database. Due to processing constraints I wouldn’t want more than 3 virtual servers actually running at one time but I can certainly have more virtual machines with various configurations defined and waiting. The only limit there would be the disk space necessary for the VM’s.

I also don’t expect blazing performance but that is not the purpose. What is the purpose is to have my own test system available at any time to test whatever configuration and or commands I want to test, with zero risk of damaging a production system. (And don’t forget that for your developers, the “test” system is production!)

There was a bit of a learning curve getting the initial setup working the way I wanted, but that learning experience gave me some additional knowledge in networking and systems administration. I developed several shell and sql scripts to easily reproduce an installation from the ground up.

By using VMworkstation snaphots I can always restore the entire virtual server to a point in time prior to some experiment or test gone wrong, so there is no reason to fear breaking something.

So quit complaining about not having a test system and go build your own! No excuses!

But I want to store the date in format …..

Ed Stevens — Thu, 07 Apr 2011 13:09:44 +0000

Taking a breather from my exploration of TNS connection issues, I’d like to take a quick romp through the use (and MIS-use) of date formatting. There are no deep mysteries revealed here, and everything is quite well documented. But judging from traffic on OTN forums, it appears this is an area that leaves a lot of confusion. I will try to address those points of confusion directly, and provide examples that will, hopefully, clarify the documentation by connecting some of the dots that people seem to miss.

A very frequent question on OTN is some variation on this:

I have a column, birthdate, that looks like 23-Mar-2011. How do I get Oracle to store the date in the format 2011/03/23?

And the short answer is, “you don’t.”

Invariably, when people ask this type of question what they really want is to be able to display the date in their chosen format. They don’t understand that (1) a column defined as a DATE stores the data in Oracle’s internal format and (2) that column can be displayed in any number of formats in spite of (actually, because of) that internal format.

Using proper data type

In order to understand “you don’t” store the date in whatever-format-you-say, you have to understand the concept of DATA TYPE. (I’ll save the rant for a separate post).

Almost all programming languages have mechanisms for declaring the TYPE of data we are dealing with. The data type defines

the possible values for that type,
the operations that can be done on that type, and
the way the values of that type are stored.

It occurs to me that the definition of a data “type” sounds similar to the definition of an object in object oriented programming – even though data typing has been around much longer that OOP. Oracle has a rich set of data types, all documented in the SQL Reference Manual.

Think about the power this simple concept brings to programming. If I treat everything as a character string, there is nothing to keep me from saying my birthday is “fred”. Or that your salary is “fubar”. There is no way to give you a raise by computing “emp_sal *5″, because internally there is no functional difference between “50000″ and “get a pink slip”. Or if I declare the column DAY_OF_BIRTH as a NUMBER, there is nothing to keep me from saying my birthday is 1, or 999999999999. Or entering numbers that look like dates, but certainly don’t get treated like dates, and have no integrity as dates.

In my first drafts of this post I spent quite a bit of time at this point making the case for using the proper data type (DATE) for dates. For the sake of brevity I’ll defer that discussion to another post. For now let’s just assume that your date data is properly typed as DATE, and discuss how to deal with that to get the results you want.

The DATE and TIMESTAMP in Oracle

When a column is declared as a DATE or TIMESTAMP, Oracle stores that data in an internal format that is very efficient for dealing with a very large range of dates and times. Dan Morgan has a more through explanation of the details of this internal format at http://psoug.org/reference/datatypes.html. What’s important for us to know is that 1) the data is stored in Oracle’s format, not ours and 2) it includes both date and time. For DATE the time component is down to the second, but not fractions of seconds. TIMESTAMP can store date and time down to billionths of seconds (9 decimal places).

NLS_DATE_FORMAT

When people say Oracle isn’t storing the date in the format they wanted, what is really happening is Oracle is not presenting the date in the character string format they expected or wanted.

When a data element of type DATE is selected, it must be converted from its internal, binary format, to a string of characters for human consumption. The conversion of data from one type to another is known as known a “conversion”, “type casting” or “coercion”. In Oracle the conversion between dates and character strings is controlled by the NLS_DATE_FORMAT model. The NLS_DATE_FORMAT can be set in any of several different locations, each with its own scope of influence.

The weakest setting of NLS_DATE_FORMAT is in the database initialization parameters. The reason I say this is the weakest setting is because it is overridden by several other settings, and does NOT override any settings itself. Setting NLS_DATE_FORMAT in the initialization parameters will be good only until it is overridden by setting it somewhere else, like . . .

Setting it as an OS environment variable on the client machine. In unix that is “export NLS_DATE_FORMAT=somevalue”. In Windows it can be set either the SYSTEM ENVIRONMENT VARIABLES or at the command prompt in a command session. I’d think it could also be set in the registry (see http://support.microsoft.com/kb/104011) but I’ve not been able reproduce it. Between setting it at the system environment variables and at the command prompt, the command prompt setting will take precedence.

I won’t spend any time explaining or demonstrating how to set it at the OS because this is, in turn, overridden by . . .

Setting it at the oracle client session level: ALTER SESSION SET NLS_DATE_FORMAT=somesetting. That, in turn, is overridden by

Use of the to_date and to_char functions at the individual sql statement.

Considering the long chain of overriding settings, you should never depend on a setting outside of your own immediate control. That means you will always do one of the following:

1) ALTER SESSION SET NLS_DATE_FORMAT=’whatever format model you want’;
or
2) Proper use of TO_CHAR and TO_DATE at the individual sql statement

I prefer the second, so there is never any ambiguity or question when looking at an individual SQL statement.

Just to drive home the point, let’s demonstrate the various settings. I’ll create a table with a single DATE column, insert a single row, then repeatedly select that row after altering the session value of NLS_DATE_FORMAT.

SQL> create table mytest (birthdate date);

Table created.

SQL> insert into mytest values (sysdate);

1 row created.

SQL> select * from mytest;

BIRTHDATE
---------
06-APR-11

1 row selected.

SQL> alter session set nls_date_format='yyyy/mm/dd';

Session altered.

SQL> select * from mytest;

BIRTHDATE
----------
2011/04/06

1 row selected.

SQL> alter session set nls_date_format='dd/mm/yy hh:mi:ss';

Session altered.

SQL> select * from mytest;

BIRTHDATE
-----------------
06/04/11 08:43:48

1 row selected.

SQL> alter session set nls_date_format='dd/mm/yyyy hh24:mi:ss';

Session altered.

SQL> select * from mytest;

BIRTHDATE
-------------------
06/04/2011 20:43:48

1 row selected.

SQL>

The datetime functions

There is a second method of controlling the format of a selected DATE data element. Even a session level setting of NLS_DATE_FORMAT can be overridden by use of the datetime functions TO_CHAR and TO_DATE at the individual sql statement. This explicit control cannot be overridden by anything else. That is why it is my preferred method, and the one I press on anyone I am training.

The to_date function takes a character string and a description of that string to return a DATE. It is most commonly used when inserting or updating a date. More on that later.

The second datetime function is to_char. It takes a DATE and a format string to return a character string representation of the date, formatted according to the format string. This format string is formed exactly the same as when setting NLS_DATE_FORMAT.

At this point some people may still be harboring the notion that what I did with ALTER SESSION SET NLS_DATE_FORMAT was somehow altering the data in the table (in spite of what ALTER SESSION really means) but this next example should make it crystal clear that we are simply formatting the data for presentation.

SQL> select birthdate bday1,
  2         to_char(birthdate,'yyyy/mm/dd') bday2,
  3         to_char(birthdate,'dd/mm/yy hh:mi:ss') bday3,
  4         to_char(birthdate,'dd/mm/yyyy hh24:mi:ss') bday4
  5  from mytest;

BDAY1     BDAY2      BDAY3             BDAY4
--------- ---------- ----------------- -------------------
06-APR-11 2011/04/06 06/04/11 08:43:48 06/04/2011 20:43:48

1 row selected.

Datetime format elements

The string of characters defining the format we want for the character representation of the date (the “format model”) is made up of “format elements”. They are fully documented in the SQL Reference Manual, under “Format Models“. Just for fun, let’s play around with some of the lesser used elements.

SQL> -- D returns Day of week (1-7). Depends on the NLS territory of the session.
SQL> select to_char(birthdate,'yyyy/mm/dd hh24:mi:ss') bd1,
  2         to_char(birthdate,'D') bd2
  3  from mytest;

BD1                 B
------------------- -
2011/04/06 20:43:48 4

1 row selected.

SQL> -- DAY returns Name of day.  Is case sensitive
SQL> select to_char(birthdate,'DAY') bd2,
  2         to_char(birthdate,'Day') bd3
  3  from mytest;

BD2       BD3
--------- ---------
WEDNESDAY Wednesday

1 row selected.

SQL> -- DDD returns Day of year (1-366)
SQL> select to_char(birthdate,'DDD') bd2
  2  from mytest;

BD2
---
096

1 row selected.

SQL> -- DY Abbreviated name of day, case sensitive
SQL> select to_char(birthdate,'DY') bd2,
  2         to_char(birthdate,'Dy') bd3
  3  from mytest;

BD2 BD3
--- ---
WED Wed

1 row selected.

SQL> -- IW Week of year (1-52 or 1-53) based on the ISO standard
SQL> select to_char(birthdate,'IW') bd2
  2  from mytest;

BD
--
14

1 row selected.

SQL> -- RM Roman numeral month (I-XII; January = I)
SQL> select to_char(birthdate,'RM') bd2
  2  from mytest;

BD2
----
IV

1 row selected.

SQL> -- YEAR Year, spelled out, case sensitive
SQL> select to_char(birthdate,'YEAR') bd2,
  2         to_char(birthdate,'Year') bd2
  3  from mytest;

BD2                                        BD2
------------------------------------------ ------------------------------------------
TWENTY ELEVEN                              Twenty Eleven

1 row selected.

SQL> -- we can even insert text of our choosing:
SQL> select to_char(birthdate,'"I was born in " YEAR') bd2
  2  from mytest;

BD2
---------------------------------------------------------
I was born in  TWENTY ELEVEN

1 row selected.

SQL>

Inserting data with to_date

Up to this point we have only discussed SELECTing data. Everything we’ve talked about applies in reverse with the to_date function. This function takes a character string and a format model describing that character string, and returns an internal date format. It is used for INSERTing and UPDATEing data as it is stored in a table. From what you’ve seen to this point, a quick example should make it clear.

SQL> truncate table mytest;

Table truncated.

SQL> insert into mytest values (to_date('20110506','yyyymmdd'));

1 row created.

SQL> insert into mytest values (to_date('01-JAN-1953','dd-MON-yyyy'));

1 row created.

SQL> insert into mytest values (to_date('05/04/63 13:23:47','mm/dd/yy hh24:mi:ss'));

1 row created.

SQL> select to_char(birthdate,'dd-Mon-yyyy hh24:mi:ss')
  2  from mytest;

TO_CHAR(BIRTHDATE,'D
--------------------
06-May-2011 00:00:00
01-Jan-1953 00:00:00
04-May-2063 13:23:47

3 rows selected.

Conclusion

Hopefully by this point you will see that storing data as a date and presenting that data in a result set are two different things. A couple of final points need to be made.

First, the to_char function is used to convert from a date to a character string. It makes no sense to give it a character string as an input argument. Conversely, the to_date function converts a character string to a date. It makes no sense to give it a date (datatype) as an arguement, yet we often see something like this:

sql> select to_date(sysdate) from dual;

Second, when designing a table, one should always use the appropriate data type for the type of data being stored. Dates and times are stored in datetime columns, numbers are stored in numeric columns. I’ll write more on that later. Film at eleven.

ORA-12514: TNS:listener does not currently know of service

Ed Stevens — Sun, 20 Mar 2011 00:02:01 +0000

In previous posts I have explored various reasons why a client process might not be able to connect to an Oracle database. In “Help! I can’t connect to my database” I presented an overview of the process used by sqlnet to convert a connection request to a network connection descriptor and deliver that request to a listener capable of servicing the request. I followed that with two posts going into more depth on the types of problems that can prevent the request from reaching the host server. Now I would like to look at the next possible problem in the sequence, in particular “ORA-12514: TNS:listener does not currently know of service requested in connect descriptor”.

For this demonstration I will generate the error then go through the standard analysis and solution. After that, I will explore some of the interesting factors that flow from this.

The Error

The vast majority of the time, this error results from an incorrectly specified connect descriptor in the tnsnames.ora file. Let’s look at a very typical example then diagnose and fix it. After that we will dig in to how the listener comes to know of a service name.

C:\>sqlplus scott/tiger@vlnxora1

SQL*Plus: Release 10.2.0.4.0 - Production on Tue Mar 15 18:47:26 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ORA-12514: TNS:listener does not currently know of service requested in connect
descriptor

Enter user-name:
C:\>

Fig. 1

Of course the very first thing anyone should do when confronted with an Oracle error is to check the official description. There are many sources on the web, but I like to start with ‘oerr’ utility on the server ..

[oracle@vmlnx01 admin]$ oerr ora 12514
12514, 00000, "TNS:listener does not currently know of service requested in connect descriptor"
// *Cause:  The listener received a request to establish a connection to a
// database or other service. The connect descriptor received by the listener
// specified a service name for a service (usually a database service)
// that either has not yet dynamically registered with the listener or has
// not been statically configured for the listener.  This may be a temporary
// condition such as after the listener has started, but before the database
// instance has registered with the listener.
// *Action:
//  - Wait a moment and try to connect a second time.
//  - Check which services are currently known by the listener by executing:
//    lsnrctl services
//  - Check that the SERVICE_NAME parameter in the connect descriptor of the
//    net service name used specifies a service known by the listener.
//  - If an easy connect naming connect identifier was used, check that
//    the service name specified is a service known by the listener.
//  - Check for an event in the listener.log file.

Fig. 2

The error is pretty self-explanatory: “listener does not currently know of service requested in connect descriptor”. So how do we know exactly what service was “requested in connect descriptor”?

First, do a sanity check by looking at the tnsnames.ora file.

C:\>type C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN\tnsnames.ora
vlnxora1 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = vmlnx01)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = fubar)
    )
  )

C:\>

Fig. 3

In Fig. 3, line 8 we see that we should be requesting SERVICE_NAME = fubar. In our discussion of ORA-12154 I described how we might not be using the tnsnames.ora we thought we were. At this point we know what SERVICE_NAME we should be using. We can use tnsping to confirm this.

C:\>tnsping vlnxora1

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 15-MAR-2
011 19:02:39

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = fubar)))
OK (0 msec)

C:\>

Fig. 4

Fig. 4, line 13 shows that we are requesting a connection to service ‘fubar’. Don’t be fooled by the good return code. As we saw in “tnsping – what it is, what it isn’t“, tnsping only goes as far as confirming there is a listener at the specified ip address and port. It says nothing about any services the listener knows about. The presence of SERVCICE_NAME in the feedback is simply the result of showing the entire connect descriptor.

Now that we know what service name was actually requested, we need to check what the listener knows about. Examining the listener configuration file, listener.ora, could give some clues but it is not the whole story. In fact, the listener can be started without any listener.ora file at all. The only sure way to tell what the listener knows about is to ask it directly, with the lsnrctl command:

[oracle@vmlnx01 ~]$ lsnrctl status

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 15-MAR-2011 19:11:49

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Start Date                15-MAR-2011 18:45:24
Uptime                    0 days 0 hr. 26 min. 25 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))
Services Summary...
Service "vlnxora1" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1XDB" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1_XPT" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
The command completed successfully
[oracle@vmlnx01 ~]$

Fig. 5

This listener knows about three service names (vlnxora1, vlnxora1XDB, and vlnxora1_XPT), all associated with the instance ‘vlnxora1’. (The XDB and XTP services are for special use – we can ignore them for general connection problems.) The vast majority of the time, that’s all the debugging we need to do. We know that we should be requesting a connection to service ‘vlnxora1’ instead of ‘fubar’. Since that request comes from the client, we have to fix tnsnames.ora

C:\>type C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN\tnsnames.ora
vlnxora1 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = vmlnx01)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = vlnxora1)
    )
  )

C:\>sqlplus scott/tiger@vlnxora1

SQL*Plus: Release 10.2.0.4.0 - Production on Tue Mar 15 19:14:41 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

Fig. 6

We see in Fig. 6, line 12 that we have made the necessary correction in tnsnames.ora. The subsequent connection request is successful (fig. 6, line 18), thus validating our analysis and corrective action.

Registering the service with the listener

So how did the listener come to know about service “vlnxora1” in the first place? There are two methods by which a service is registered with the listener – “static” and “dynamic”. We’ll discuss each in turn.

Static registration

Static registration is accomplished by configuring the SID_LIST section of the listener.ora file.

[oracle@vmlnx01 admin]$ cat listener.ora
# listener.ora Network Configuration File: /ora00/app/oracle/product/10.2.0/db_1/network/admin/listener.ora

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /ora00/app/oracle/product/10.2.0/db_1)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (GLOBAL_DBNAME=myfubardb)
      (ORACLE_HOME = /ora00/app/oracle/product/10.2.0/db_1)
      (SID_NAME = fubar)
    )
    (SID_DESC =
      (GLOBAL_DBNAME=vlnxora1)
      (ORACLE_HOME = /ora00/app/oracle/product/10.2.0/db_1)
      (SID_NAME = vlnxora1)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = vmlnx01.vmdomain)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
    )
  )

[oracle@vmlnx01 admin]$

Fig. 7

In Fig. 7 we see three SIDs listed: PLSExtProc, fubar, and vlnxora1 (lines 7,14, and 19). Checking the status of the listener, we get

[oracle@vmlnx01 admin]$ lsnrctl status

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 16-MAR-2011 18:27:25

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=vmlnx01.vmdomain)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Start Date                16-MAR-2011 18:25:56
Uptime                    0 days 0 hr. 1 min. 28 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /ora00/app/oracle/product/10.2.0/db_1/network/admin/listener.ora
Listener Log File         /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "myfubardb" has 1 instance(s).
  Instance "fubar", status UNKNOWN, has 1 handler(s) for this service...
Service "vlnxora1" has 2 instance(s).
  Instance "vlnxora1", status UNKNOWN, has 1 handler(s) for this service...
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1XDB" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1_XPT" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
The command completed successfully
[oracle@vmlnx01 admin]$

Fig. 8

Notice the entry for service “myfubardb” (fig. 8, line 25) maps back to “(GLOBAL_DBNAME=myfubardb)” (fig 7, line 12) and is related to instance “fubar”, which maps to fig 7, line 14). Further, notice that its status is UNKNOWN. This status of UNKNOWN is the indication that this registration came from the SID_LIST section of listener.ora. It is unknown because the listener doesn’t make a check to see if there is an instance named “fubar” broadcasting a service name of “myfubardb”. The listener is just saying “if you ask for a connection to “myfubardb”, I’ll see what I can do to service it.” In fact, I have no database named “fubar” or “myfubardb”.

Notice also that service “vlnxora1” has two instances, one unknown, and one READY. Like myfubardb, the UNKNOWN vlnxora1 comes from listener.ora (fig. 7, line 19); the READY instance comes from the database having registered with the listener (dynamic registration).

Again, for our current discussion, we can ignore the services vlnxora1XDB and vlnxora1_XTP. These have special internal uses for Oracle.

For the remainder of the discussion, I am going to completely remove listener.ora, then restart the listener so that it has no static registrations and is running with all default values:

[oracle@vmlnx01 admin]$ rm listener.ora

[oracle@vmlnx01 admin]$ ls -l listener.ora
ls: listener.ora: No such file or directory

[oracle@vmlnx01 admin]$ lsnrctl stop

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 16-MAR-2011 18:44:43

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
The command completed successfully
[oracle@vmlnx01 admin]$ lsnrctl start

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 16-MAR-2011 18:44:49

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Starting /ora00/app/oracle/product/10.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Log messages written to /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Start Date                16-MAR-2011 18:44:49
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))
The listener supports no services
The command completed successfully
[oracle@vmlnx01 admin]$

Fig. 9

With no static registration the listener will start with all default values and support no services until a pmon process registers itself.

Dynamic registration

Dynamic registration is accomplished when the pmon process of the database instance contacts the listener and requests registration. This occurs at instance startup, and every few minutes during the life of the instance.

There are three initialization parms that affect what service name(s) pmon will register with the listener:

DB_NAME

SERVICE_NAMES

DB_DOMAIN

You should look up each one in the Reference Manual and read the descriptions. (Click on the links) Notice particularly in the description of SERVICE_NAMES the following:

If you do not qualify the names in this parameter with a domain, Oracle qualifies them with the value of the DB_DOMAIN parameter. If DB_DOMAIN is not specified, then no domain will be applied to the non-qualified SERVICE_NAMES values.

There is another interaction that is not spelled out in the Reference Manual, but mentioned in the Net Services Administrator’s Guide:

The service name defaults to the global database name, a name comprising the database name (DB_NAME parameter) and domain name (DB_DOMAIN parameter)

Since neither DB_DOMAIN nor SERVICE_NAMES are required parameters, let’s start with an instance with neither of those set, then start observing how service names get constructed with various settings. For each iteration I will do the following:

1) alter an initialization parm
2) bounce the database (some of the parms require it. To keep things clean and consistent, I’ll do it for all of them)
3) restart the listener, to flush the old registrations
4) force a new registration
5) show the listener status, with the results of the new registration
6) show the values of all three parms, for comparison

[oracle@vmlnx01 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Wed Mar 16 19:17:57 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system set service_names='' scope=spfile;

System altered.

SQL> alter system set db_domain='' scope=spfile;

System altered.

SQL> @doit
SQL> startup force
ORACLE instance started.

Total System Global Area  285212672 bytes
Fixed Size                  1267068 bytes
Variable Size             138414724 bytes
Database Buffers          142606336 bytes
Redo Buffers                2924544 bytes
Database mounted.
Database opened.
SQL> !lsnrctl stop

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 16-MAR-2011 19:18:52

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
The command completed successfully

SQL> !lsnrctl start

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 16-MAR-2011 19:19:01

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Starting /ora00/app/oracle/product/10.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Log messages written to /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Start Date                16-MAR-2011 19:19:01
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))
The listener supports no services
The command completed successfully

SQL> alter system register;

System altered.

SQL> !lsnrctl status

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 16-MAR-2011 19:19:01

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Start Date                16-MAR-2011 19:19:01
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))
Services Summary...
Service "vlnxora1" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1XDB" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1_XPT" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
The command completed successfully

SQL> show parameter db_name;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_name                              string      vlnxora1
SQL> show parameter service_names;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string
SQL> show parameter db_domain;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_domain                            string
SQL>

Fig. 10

In Fig. 10, at lines 91,93 and 95, we see three service names. All three are associated with the instance “vlnxora1” and derived their name from the initialization parameter “db_name”.

Next, we add a simple service name. While normal practice might be to make it the same as the db_name, I’ll make it different so that we can trace it to the end result. Remember, it is quite acceptable to have multiple service_names, which we will get to in a moment.

SQL> alter system set service_names='edstevens' scope=spfile;

System altered.

SQL> @doit
---- snip repetitive commands and output ----
SQL> !lsnrctl status

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 16-MAR-2011 19:22:06

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Start Date                16-MAR-2011 19:22:06
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))
Services Summary...
Service "edstevens" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1XDB" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1_XPT" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
The command completed successfully

SQL> show parameter db_name;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_name                              string      vlnxora1
SQL> show parameter service_names;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string      edstevens
SQL> show parameter db_domain;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_domain                            string
SQL>

Fig. 11

Now we see that all of the service names derived from db_name are still in place, but we have also added one derived from service_names (Fig. 11, line 27)

Next we set db_domain

SQL> alter system set db_domain='acme.com' scope=spfile;

System altered.

SQL> @doit
---- snip repetitive commands and output ----
SQL> !lsnrctl status

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 16-MAR-2011 19:24:01

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Start Date                16-MAR-2011 19:24:01
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))
Services Summary...
Service "edstevens.acme.com" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1.acme.com" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1XDB.acme.com" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1_XPT.acme.com" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
The command completed successfully

SQL> show parameter db_name;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_name                              string      vlnxora1
SQL> show parameter service_names;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string      edstevens
SQL> show parameter db_domain;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_domain                            string      acme.com
SQL>

Fig. 12

Notice that all service names – those derived from db_name as well as the one derived from service_names – have the value of db_domain appended to them.

Next we add a second service name, this one qualified with a second domain name. Not something you’d normally do, but useful for demonstrating the interaction of the parameters

SQL> alter system set service_names='edstevens,wiley.coyote.com' scope=spfile;

System altered.

SQL> @doit
---- snip repetitive commands and output ----
SQL> !lsnrctl status

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 16-MAR-2011 19:27:07

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Start Date                16-MAR-2011 19:27:07
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))
Services Summary...
Service "edstevens.acme.com" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1.acme.com" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1XDB.acme.com" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "vlnxora1_XPT.acme.com" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
Service "wiley.coyote.com" has 1 instance(s).
  Instance "vlnxora1", status READY, has 1 handler(s) for this service...
The command completed successfully

SQL> show parameter db_name;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_name                              string      vlnxora1
SQL> show parameter service_names;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string      edstevens,wiley.coyote.com
SQL> show parameter db_domain;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_domain                            string      acme.com
SQL>

Fig. 13

As before, all of the unqualified service names derived from db_name and service_names have been qualified with the value of db_domain. But notice that we have a new service name (Fig. 13, line 35) from the second value supplied from service_names. Since this was fully qualified in the service_names initialization parm, the value of db_domain was not applied.

Conclusion

We have explored the relationship between the connect descriptor issued by the client and the services supported by the listener, as well as the factors that control what services the listener supports. In the concluding post in this series, I will discuss how the database locates the listener in order to register its services – the LOCAL_LISTENER initialization parameter.

Film at eleven …

ORA-12545

Ed Stevens — Sat, 05 Mar 2011 21:08:56 +0000

Introduction

Continuing our discussion of “Why can’t I connect to my database”, I want to focus on “ORA-12545: Connect failed because target host or object does not exist”.

To recap what we’ve covered so far, when an oracle client requests a connection to a database, it has to provide a “connect identifier”, which sqlnet then translates to a “connect descriptor”. The connect descriptor specifies the transport protocol (usually tcp), the ip address of the database server, the port being used by the listener, and the service name the database has registered with the listener. This name resolution is usually done by looking up the connect identifier in the client’s tnsnames.ora file, though there are other methods available as well. Failure to find an entry from which to derive the connect descriptor will result in an ORA-12154: TNS:could not resolve the connect identifier specified, which I delved into here.

If sqlnet is able to determine the connect descriptor, the next step of the process is to pass that information to the OS’s network layer to be routed to the specified IP address. It is problems at this point that we will focus on in today’s discussion.

Setup

For this demonstration, I am using an Oracle 10.2.0.4 client on Windows XP, connecting to an Oracle 10.2.0.4 database on Oracle Enterprise Linux 5. Name resolution is through tnsames.ora, which looks like this:

# tnsnames.ora Network Configuration File: C:\oracle\product\10.2.0\client_1\network\admin\tnsnames.ora
#===========================
fred =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = vmlnx01)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = vlnxora1)
    )
  )

(By the way, I like to use “fred” as an alias name in demonstrations because it should be obvious that it is a totally artificial name that doesn’t have any inherent relationship to anything. As in the above tnsnames example, in a production system I would use the service name (vlnxora1) as the connect identifier, but in demonstrations I want the distinction to be crystal clear.)

The key information we are focusing on is the “HOST = vmlnx01″ on line 6.

First, let’s make a good connection to prove that everything is working correctly, then we will break it.

C:\>sqlplus scott/tiger@fred

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Mar 5 09:45:17 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

Case #1

We know that in order for a message to be routed across a network, we need an ip address. This is like placing a telephone call. If I want to call Moe, I can’t just pick up my phone and dial “Moe”. The telephone company switchboards don’t know anything about Moe. There has to be some mechanism to translate “Moe” to 1-555-123-4567. Likewise the network routers don’t know anything about “vmlnx01″. For your telephone you would have some sort of directory to tell you what Moe’s number is. In a corporate environment, you probably have a DNS server to tell the network stack that “vmlnx01″ is 192.168.160.101. The other mechanism, and the one that trumps a DNS lookup, is a file on the client, named simply “hosts”. On unix, this will be at /etc/hosts. On my Windows XP machine it is at C:\WINDOWS\system32\drivers\etc\hosts. Given Microsoft’s propensity for reshuffling the deck with each new release of Windows, I can’t promise that is where the file should be located on your machine!

My hosts file looks like this:

127.0.0.1 localhost
192.168.160.101 vmlnx01 vmlnx01.vmdomain

For those not familiar with this file, the format is

ipaddress alias1 alias2 .... aliasN

All hosts files should have the same first line, equating ip address 127.0.0.1 to the alias “localhost”. All other entries typically have two aliases, one with the unqualified server name, the other with the fully qualified servername.domain. That is by convention and for everyone’s convenience, but the fact is these are just aliases for the ip address, and like any alias can actually be anything you want. I will demonstrate that after taking care of the business at hand.

At this point, we know that we told the network to route our request to ‘vmlnx01′, and by using the local hosts file, it was able to translate ‘vmlnx01′ to ’192.168.160.101′. Let’s fix it so that it can’t make that translation, and see what results. We will do that by removing the entry for vmlnx01 from the hosts file:

127.0.0.1 localhost
192.168.160.101 fubar.vmdomain fubar

Then test:

C:\>sqlplus scott/tiger@fred

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Mar 5 10:13:45 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ORA-12545: Connect failed because target host or object does not exist

And we have our error. Please notice that we did NOT touch our tnsnames.ora file, which we’ve already proven to be good. This error is simply oracle reporting what the OS network returned. Of course, since it resulted from a mis-match between the HOST parameter in tnsnames and the entries in the hosts file, the proper fix is could be in either file. It is often suggested to avoid this problem by hard-coding the IP address in the tnsnames (HOST=192.168.160.101), but I consider that to be a hack taken by those who do not understand how net name resolution works. It is certainly poor practice to hard-code an IP address any place an alias can be used. Just think of the problems caused by hard-coded IP addresses when the network administrator restructures the net.

This particular error is exactly analogous to “ORA-12154: TNS:could not resolve the connect identifier specified”. With that error, sqlnet couldn’t find a tnsnames entry for “fred” to translate to a connect descriptor; with this error, the OS network layer couldn’t find a hosts entry for ‘vmlnx01′ to translate to an ip address.

Case #2

For our next trial, let’s restore the proper alias to the hosts file, but equate it to a bogus ip address.

C:\>type C:\WINDOWS\system32\drivers\etc\hosts
127.0.0.1 localhost
192.168.160.201 vmlnx01 vmlnx01.vmdomain

C:\>ping -n 1 192.168.160.201

Pinging 192.168.160.201 with 32 bytes of data:

Request timed out.

Ping statistics for 192.168.160.201:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

C:\>sqlplus scott/tiger@fred

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Mar 5 10:25:27 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ORA-12170: TNS:Connect timeout occurred

Enter user-name:

A slightly different error, sqlnet simply reporting what was returned by the OS network layer. Compare to the result of the ‘ping’ on line 5.

Case #3

One more test. We will restore the hosts to its pristine condition, then shut down the db server and test.

C:\>type C:\WINDOWS\system32\drivers\etc\hosts
127.0.0.1 localhost
192.168.160.101 vmlnx01 vmlnx01.vmdomain

C:\>ping -n 1 192.168.160.101

Pinging 192.168.160.101 with 32 bytes of data:

Request timed out.

Ping statistics for 192.168.160.101:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

C:\>sqlplus scott/tiger@fred

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Mar 5 13:08:47 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ORA-12170: TNS:Connect timeout occurred

Enter user-name:

Of course, having a “correct” ip address in hosts, but the target server down, is really no different that an “incorrect” ip address to start with.

Case #4

I would like to do one more test to serve as the lead-in to the next few posts, dealing with problems on the db server rather than the client. For this test, the server is up, but the listener has been shut down.

[oracle@vmlnx01 ~]$ lsnrctl stop

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 05-MAR-2011 13:19:27

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=vmlnx01.vmdomain)(PORT=1521)))
The command completed successfully
[oracle@vmlnx01 ~]$

And repeating the test

C:\>ping -n 1 192.168.160.101

Pinging 192.168.160.101 with 32 bytes of data:

Reply from 192.168.160.101: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.160.101:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

C:\>sqlplus scott/tiger@fred

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Mar 5 13:23:04 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ORA-12541: TNS:no listener

Enter user-name:

Conclusion

Along with the previous posts in this series, this covers the TNS and network configurations that can be controlled completely on the client side. We have touched on a couple of server-side issues. Future posts will dig into that side of the equation. I will also take a side road to explore the hosts file in more detail.

“Film at eleven . . .”

tnsping – what it is, what it isn’t

Ed Stevens — Sun, 27 Feb 2011 22:48:03 +0000

Before continuing our exploration of various tns connection errors, let’s take a quick look at the oracle utility ‘tnsping’. We’ll see what it does, what it doesn’t do, and explode a few myths along the way.

The tnsping utility is used to determine if a service on an Oracle Net network can be reached. A complete description of its use is found in the Net Services Administrators Guide, located with the rest of the Oracle documentation at tahiti.oracle.com. TNSPING serves, for sqlnet, much the same purpose as does ‘ping’ for the underlying network stack.

Let’s take a look at a simple case. Given this entry in my tnsnames.ora . . .

C:\>type C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN\tnsnames.ora
# tnsnames.ora Network Configuration File: C:\oracle\product\10.2.0\client_1\net
work\admin\tnsnames.ora
# Generated by Oracle configuration tools.
#===========================
larry =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = vmlnx01)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = vlnxora1)
    )
  )


C:\>

. . . let’s run some tests.

C:\>tnsping larry

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 27-FEB-2
011 16:21:22

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = vlnxora1)))
OK (20 msec)

And we think, “Aha!” I can connect! Well, maybe. Maybe not. I’ll get to that later. First, let’s look at what all we can learn from what we see here.

C:\>tnsping larry

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 27-FEB-2
011 14:46:56

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = vlnxora1)))
OK (20 msec)

C:\>

The first thing we learn, from line 3, is that we are running Oracle client 10.2.0.4. Note that this is the version of the client, not the database. They do not have to be the same, and this tells us only about the client.

C:\>tnsping larry

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 27-FEB-2
011 14:46:56

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = vlnxora1)))
OK (20 msec)

C:\>

From lines 8-9, we see that the network parameter file (sqlnet.ora) used by this client is at C:\oracle\product\10.2.0\client_1\network\admin. This is also a very strong indication that the tnsnames.ora file is also located in that directory. However, there are other influences on the location of tnsnames.ora. See my post on that subject, here.

C:\>tnsping larry

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 27-FEB-2
011 14:46:56

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = vlnxora1)))
OK (20 msec)

C:\>

From line 11, we see that we are using the TNSNAMES adapter to resolve the alias. (The alias was ‘vlnxora1′). This adapter was chosen based on the value of the NAMES.DIRECTORY_PATH parameter in the sqlnet.ora file.

C:\>tnsping larry

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 27-FEB-2
011 14:46:56

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = vlnxora1)))
OK (20 msec)

C:\>

Lines 12 and 13 show us how sqlnet resolved the alias, or “connect identifier”, into a connect descriptor. We see that the request was routed using the tcp network protocol (PROTOCOL = TCP), to server vlmnx01 (HOST = vmlnx01), and placed at that server on port 1521. This information was gathered from the tnsnames.ora entry for ‘larry’, shown above.

And from line 14 we see that the response time was 20 milliseconds. Well, not quite. According to the Net Administrators Guide, tnsping “displays an estimate of the round trip time” (emphasis mine).

We also see that it requested a connection to (SERVICE_NAME = vlnxora1). Or did it? What does the listener show?

[oracle@vmlnx01 admin]$ lsnrctl status

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 27-FEB-2011 15:27:35

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Start Date                27-FEB-2011 15:27:26
Uptime                    0 days 0 hr. 0 min. 9 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /ora00/app/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmlnx01.vmdomain)(PORT=1521)))
The listener supports no services
The command completed successfully
[oracle@vmlnx01 admin]$

Hmm. Line 20 says “The listener supports no services”. How can this be? Wasn’t our tnsping successful? What does a real connection request do?

C:\>sqlplus scott/tiger@vlnxora1

SQL*Plus: Release 10.2.0.4.0 - Production on Sun Feb 27 15:32:18 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ORA-12514: TNS:listener does not currently know of service requested in connect
descriptor

Of course the listener “does not currently know of service requested”. At the moment, the listener does not know of any services at all. By the way, I made sure the listener did not know of any services. My listener relies on dynamic database registration, and I had stopped the database before starting this test. Not only does the listener not know of any services, there is no database running at all. I could just as easily specified SERVICE_NAME=FUBAR, or SERVICE_NAME=BTZLFLX and received the same result.

And if the listener is not running at all? Let’s stop the listener . . .

[oracle@vmlnx01 ~]$ lsnrctl stop

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 27-FEB-2011 15:40:41

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
The command completed successfully

[oracle@vmlnx01 ~]$ lsnrctl status

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 27-FEB-2011 15:40:50

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
TNS-12541: TNS:no listener
 TNS-12560: TNS:protocol adapter error
  TNS-00511: No listener
   Linux Error: 111: Connection refused
[oracle@vmlnx01 ~]$

. . .then test tnsping again

C:\>tnsping larry

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 27-FEB-2
011 15:42:27

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = vlnxora1)))
TNS-12541: TNS:no listener

As we would expect, tnsping reports that there is no listener.

Conclusion

While tnsping is a very useful tool for diagnosing a variety of connection problems, we must be very clear about one important point: it tells us absolutely nothing about the state of a database instance. This is not a shortcoming of tnsping. We just need to understand that it is a tool for diagnosing sqlnet issues, and sqlnet is not the database.

ora-12154/tns-03505

Ed Stevens — Sun, 27 Feb 2011 02:03:23 +0000

Continuing the discussion of “why can’t I connect to my database?”, I’d like to focus on one particular error – ora-12154. For this discussion and demonstration we will use Oracle’s sqlplus command processor as our client, but the principles apply to any client program that uses sqlnet to connect to the database.

There are actually several mechanisms for connecting to an Oracle database, but by far the most common is via the Oracle Call Interface (OCI), passing the connect request via Oracle’s Transparent Network Substrate (TNS), commonly referred to as “sqlnet”.

Hardly a day goes by that someone doesn’t post a problem on OTN, reporting they are getting an ora-12154 trying to connect to their database. And invariably they are sent on a wild goose chase, checking everything that can go wrong anywhere along the network stack. And yet, ora-12154 means one thing, and one thing only: The client side of sqlnet could not find the specified connect identifier. Period. And the official description of the error, returned by the Oracle utility “oerr” spells it out:

[oracle@vmlnx01 ~]$ oerr ora 12154
12154, 00000, "TNS:could not resolve the connect identifier specified"
// *Cause:  A connection to a database or other service was requested using
// a connect identifier, and the connect identifier specified could not
// be resolved into a connect descriptor using one of the naming methods
// configured. For example, if the type of connect identifier used was a
// net service name then the net service name could not be found in a
// naming method repository, or the repository could not be
// located or reached.

Or more succinctly: “A connection … was requested using a connect identifier (which) could not be resolved into a connect descriptor.” So what is the connect identifier? Let’s take the classic, textbook example of a simple client connection request:

c:> sqlplus scott/tiger@orcl

By the rules Oracle uses to parse the command line, the “@” symbol is used to mark the beginning of the connect identifier. So in this example, the connect identifier is “orcl”, and an ora-12154 means an entry for “orcl” could not be resolved to a “connect descriptor” – the IP address, port number, and service name necessary to properly route the request across the network to the Oracle listener. There are several methods available to make this name resolution, but by far the most common is the use of “local naming” – the tnsnames.ora file. This file serves no other purpose, so you should have it fixed firmly in your mind that it is used only by the client process. The only reason this file exists on the database server is because the server can also run client processes.

With this preliminary information out of the way, let’s dig in and see how many ways we can create (and conversely, fix) an ora-12154. Let’s first look at a good configuration, then we’ll start taking it apart. My database is running on an Oracle Enterprise Linux server, while my client is running on my laptop, under Windows XP-Pro. My tnsnames.ora looks like this:

# tnsnames.ora Network Configuration File: C:\oracle\product\10.2.0\client_1\net
work\admin\tnsnames.ora
# Generated by Oracle configuration tools.
#===========================
mytestdb =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = vmlnx01)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = vlnxora1)
    )
  )

Make a connection to the database, just to show that everything is in order.

C:\>sqlplus scott/tiger@mytestdb

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Feb 26 15:14:38 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

Right out of the textbook! So what could go wrong, to generate an ora-12154?

Wrong naming method

The first thing sqlnet has to do is determine what naming method is being used – exactly how it is to resolve the connect identifier to an IP address, port, and service name. To do this, it looks in the file ‘sqlnet.ora’ (on the client machine, of course!) for the parameter NAMES.DIRECTORY_PATH. If we intend to use local naming, we must set this parameter appropriately:

NAMES.DIRECTORY_PATH= (TNSNAMES)

(Note: the string ‘TNSNAMES’ as a value for this parameter is not the name of the file. It is the name of the method to be used for name resolution. The name of the file used for this method is always tnsnames.ora.)

Let’s set it to some other value (albeit a valid one) . . .

C:\>type C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN\sqlnet.ora
# sqlnet.ora Network Configuration File: C:\oracle\product\10.2.0\client_1\netwo
rk\admin\sqlnet.ora

SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (LDAP)

. . . and observe the behavior

C:\>sqlplus scott/tiger@mytestdb

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Feb 26 15:27:46 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ora-12154: TNS:could not resolve the connect identifier specified

In this example, we told sqlnet to use LDAP naming services to resolve the connect identifier, but LDAP is not available in my test environment, thus it was not able to resolve “mytestdb”. Lesson: If you want to use local naming, you must specify such in the SQLNET.AUTHENTICATION_SERVICES parameter in the client’s sqlnet.ora file. Let’s fix the problem, then move on:

C:\>type C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN\sqlnet.ora
# sqlnet.ora Network Configuration File: C:\oracle\product\10.2.0\client_1\netwo
rk\admin\sqlnet.ora

SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES)

C:\>sqlplus scott/tiger@mytestdb

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Feb 26 15:52:33 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

Can’t locate tnsames.ora

The entire subject of locating tnsnames.ora was covered in “Help! I can’t connect to my database (part duex)“. For now, I will create the simplest means of not being able to locate the file – I’ll rename it to something else . . .

C:\>cd C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN

C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN>ren tnsnames.ora tnsnames.sav

C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN>dir tnsnames.ora
 Volume in drive C has no label.
 Volume Serial Number is 04C2-AD70

 Directory of C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN

File Not Found

C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN>

. . . and observe the result:

C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN>sqlplus scott/tiger@mytestdb

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Feb 26 15:57:14 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ora-12154: TNS:could not resolve the connect identifier specified

Of course, we fix it by providing a (valid) tnsnames.ora file:

C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN>ren tnsnames.sav tnsnames.ora

C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN>sqlplus scott/tiger@mytestdb

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Feb 26 15:58:37 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

Can’t find connect descriptor in tnsnames.ora

We’ve told sqlnet to use tnsnames, and we’ve made sure sqlnet can find tnsnames.ora. But what if the connect identifier we provide cannot be found in the tnsnames.ora? And more importantly, what can cause it to not be found?

Of course, the simplest reason would be that we just gave it the wrong string. In our example file (shown above), we had a single entry, with the connect identifier of ‘mytestdb’. If we provide a different connect identifier it will, of course fail – again with ora-12154:

C:\>sqlplus scott/tiger@fubar

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Feb 26 16:05:48 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ora-12154: TNS:could not resolve the connect identifier specified

But there is another factor that comes into play at this point. There is an optional parameter that can be set in sqlnet.ora that we have not yet discussed. Before looking in tnsnames.ora, sqlnet will check to see if the parameter NAMES.DEFAULT_DOMAIN has been set. If it has, it’s value will be appended to the connect descriptor supplied by the user – before searching tnsames.ora for the result. Let’s add that parameter to our existing sqlnet.ora . . .

C:\>type C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN\sqlnet.ora
# sqlnet.ora Network Configuration File: C:\oracle\product\10.2.0\client_1\netwo
rk\admin\sqlnet.ora

SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES)
NAMES.DEFAULT_DOMAIN=acme.com

. . . and observe the result

C:\>sqlplus scott/tiger@mytestdb

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Feb 26 16:13:42 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ora-12154: TNS:could not resolve the connect identifier specified

There are two ways to fix this error. Obviously, we can revert back to our previous configuration by removing the NAMES.DEFAULT_DOMAIN parameter from sqlnet.ora. The other would be to add the domain name to the entry in tnsnames.ora.

C:\>type C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN\tnsnames.ora
# tnsnames.ora Network Configuration File: C:\oracle\product\10.2.0\client_1\net
work\admin\tnsnames.ora
#===========================
mytestdb.acme.com =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = vmlnx01)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = vlnxora1)
    )
  )

C:\>sqlplus scott/tiger@mytestdb

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Feb 26 16:30:57 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

tns-03505

That pretty well covers every means of creating an ora-12154 when using local naming. What about the tns-03505 error? Actually, tns-3505 is exactly the same error as ora-12154, with all the same causes and resolutions. The only difference I’ve been able to discover is that tns-03505 is produced when using the ‘tnsping’ utility. Why Oracle chose to code tnsping this way I don’t know, and I’ve been unable to find definitive documentation on this difference but my own testing bears it out.

Using sqlplus . . .

C:\>sqlplus scott/tiger@fubar

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Feb 26 16:44:33 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

ERROR:
ora-12154: TNS:could not resolve the connect identifier specified

Enter user-name:

And using tnsping . . .

C:\>tnsping fubar

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 26-FEB-2
011 16:44:42

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora

tns-03505: Failed to resolve name

C:\>

(Thanks to Sybrand Bakker for pointing out this distinction).

I will discuss ‘tnsping’, it’s use, what it does and does not do, in another post.

This’n'that

There is one often overlooked ‘gotcha’ in all this. Remember that when sqlnet is parsing out the connect string, it uses the ‘@’ sign as a meta-character to mark the beginning of the connect descriptor. So if we have this:

c:>sqlplus scott/tiger@orcl

everything is just fine. But suppose there is an ‘@’ sign someplace unexpected. What happens if someone constructs a complex password that includes it?

c:> sqlplus scott/P@ssW0rd@orcl

In this case, sqlnet will take the ‘P’ as the password, and take ‘ssW0rd@orcl’ as the connect descriptor. By now, you can guess the result.

Conclusion

In this post I have attempted to demonstrate every possible cause of an ora-12154 error, as relates to use of tnsnames.ora, for address resolution of a connect descriptor. There is one overriding factor here that should be obvious from the very description of the error, regardless of the naming method used: ora-12154 is a client side problem. It has absolutely nothing to do with anything on the server. It has nothing to do with the listener; it has nothing to do with the database. If you are faced with a ora-12154, you can monkey around with your database and/or listener “until the cows come home” and you will not solve your problem.

Stay tuned for more discussion of sqlnet connection problems.

Help! I can’t connect to my database (part duex)

Ed Stevens — Wed, 16 Feb 2011 19:31:11 +0000

Basic Client TNS (sqlnet) configuration

Continuing the discussion of “Why can’t I connect to my database?”, I want to dig deeper into each of the potential errors in order of their possible occurrence. That will be a rather lengthy journey, so I want to start with the configuration of TNS on the client side of the connection. Since the vast majority of connection problems are presented by people using Windows as the client, all examples here will be from a Windows perspective. What a shame! Unix is actually much simpler …

Before plunging into the details of connecting to a database, we need to know the key configuration files used by TNS on the client, and how to locate them – or more accurately, how TNS locates them! There are two of these files, named “sqlnet.ora” and “tnsnames.ora”. Technically, sqlnet.ora is not required, because every essential parameter it can contain has a default value. So sqlnet.ora may not even exist on your system, but I consider it best practice to create it with key information – even if it is default values – just to remove any ambiguity when troubleshooting a problem. Full documentation of every parameter in sqlnet.ora can be found in the Net Services Reference, found with the rest of the Oracle documentation set at tahiti.oracle.com. One would also be well advised to spend some time in the Net Services Administrator’s Guide, paying attention to how the sqlnet architecture relates to the standard network OSI stack.

Of course, the TNS software needs to know how to locate these files, and has two methods of doing so. The first is to look in the default location, which is %ORACLE_HOME%\network\admin. So if you have

ORACLE_HOME=C:\oracle\product\10.2.0\client_1

your sqlnet config files will be located in C:\oracle\product\10.2.0\client_1\network\admin. If you have performed multiple installations of Oracle, you have probably created multiple ORACLE_HOME directories and so would have multiple copies of the sqlnet config files – one for each ORACLE_HOME.

This default location of ORACLE_HOME\network\admin can be overridden by use of the environment variable TNS_ADMIN. For example, if you have

TNS_ADMIN=c:\oranet

TNS will try to find the configuration files in c:\oranet. Only if they are not found there will it look in the default location.

So how does TNS even determine the value of ORACLE_HOME and/or TNS_ADMIN? In a proper operating system (any *nix system) it would simply check the environment variables assigned to that process. But since we’re dealing here with Windows, we also have to check the registry. So let’s look at some examples to see the effect of various settings. We can check the result by using the Oracle utility ‘tnsping’. I won’t go into the details of tnsping here. Suffice it to say that one of the things it does (almost as an aside) is report where it found sqlnet.ora. It also shows the address information it got from tnsnames.ora. We can use those two bits of information to see exactly which copy of a file it is using.

Here’s the setup. I have a laptop running Windows XP-Pro. On it I have installed a standard Oracle 10.2 client, with ORACLE_HOME established at C:\oracle\product\10.2.0\client_1. This is my working client setup that I use every day at the office. For this demo, I’m going to simulate a second ORACLE_HOME by creating C:\oracle\product\10.2.0\client_2\network\, and two directories outside of ORACLE_HOME, c:\oranet\admin_3 and c:\oranet\admin_4.

First, let’s look at my current setup. Checking the registry (HKLM\software\oracle) we see that ORACLE_HOME is set to c:\oracle\product\10.2\client_1

And checking the environment at the command line, we see there is NOT a setting for ORACLE_HOME, leaving the registry as the only influencing factor.

C:\> echo %ORACLE_HOME%
%ORACLE_HOME%

Now, let’s see what tnsping says about where it finds the config files:

C:\>tnsping vlnxora1

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 15-FEB-2
011 18:27:09

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = vlnxora1)))
OK (40 msec)

C:\>

The key thing to observe here is the lines

Used parameter files:
C:\oracle\product\10.2.0\client_1\network\admin\sqlnet.ora

This tells us which sqlnet.ora file was found and used. We see that in this case, TNS was looking for its configuration files exactly where we expected – %ORACLE_HOME%\network\admin. Also notice in line 13, “SERVICE_NAME = vlnxora1″. In my setup, that service name is unique to the tnsnames file at that location. So we can know that both the sqlnet.ora and tnsnames.ora files were located at the same place.

Now let’s try some overrides. We’ll set ORACLE_HOME as an environment variable at the command prompt and try it:

C:\>set ORACLE_HOME=C:\oracle\product\10.2.0\client_2

C:\>echo %ORACLE_HOME%
C:\oracle\product\10.2.0\client_2

C:\>tnsping vlnxora1

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 16-FEB-2
011 10:40:52

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oracle\product\10.2.0\client_2\network\admin\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = vlnxora2)))
TNS-12557: TNS:protocol adapter not loadable

C:\>

Now we see that ORACLE_HOME in the registry (client_1) was overridden by the value in the environment – client_2. Don’t worry about the TNS-12557 error. That is a result of the fact that ORACLE_HOME now points to a directory that has no binaries — remember I just set it up as a test for locating sqlnet.ora and tnsnames.ora. It is not a fully functional ORACLE_HOME.

TNS_ADMIN

Next let’s introduce the TNS_ADMIN variable. Just like ORACLE_HOME, it can be set in the registry, or in the command processor environment. For our next test, we’ll use the registry. Here I’ve added TNS_ADMIN to HKLM\software\oracle

Testing again:

C:\>tnsping vlnxora1

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 16-FEB-
011 10:53:31

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
c:\oranet\admin_3\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = vlnxora3)))
TNS-12557: TNS:protocol adapter not loadable

C:\>

We see that the setting of TNS_ADMIN in the registry overrides ORACLE_HOME in both the registry and the command processor environment.

As one last test, we will add TNS_ADMIN to the command processor environment. This is on top of all of our previous settings:

C:\>set TNS_ADMIN=C:\oranet\admin_4

C:\>echo %TNS_ADMIN%
C:\oranet\admin_4

C:\>tnsping vlnxora1

TNS Ping Utility for 32-bit Windows: Version 10.2.0.4.0 - Production on 16-FEB-2
011 10:57:12

Copyright (c) 1997,  2007, Oracle.  All rights reserved.

Used parameter files:
C:\oranet\admin_4\sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = vmlnx01)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = vlnxora4)))
TNS-12557: TNS:protocol adapter not loadable

C:\>

And we see that once again the environment setting overrides the registry, and TNS_ADMIN overrides ORACLE_HOME.

Conclusion

The above demonstrations reveal the various settings that control how TNS locates its configuration file (sqlnet.ora) and name resolution file (tnsnames.ora) on a Windows client. It should also be noted that the same rules apply in a *nix environment, except that there is no registry; in a unix environment, all of the settings are controlled by the environment variables. So unix will have far fewer variables to consider when trying to troubleshoot a connection problem.

I started to do some further testing to see how TNS would handle a situation where one of the files was not in the preferred location. Needless to say, with two files to be located, two variables to indicate the location (ORACLE_HOME and TNS_ADMIN) and two places those variables could be defined (registry and session environment), the possible combinations explode geometrically. Life is too short.

This still leaves the question of whether or not to introduce the TNS_ADMIN setting. The answer, like most everything is …. “it depends”. If you have a simple client installation with a single ORACLE_HOME, there is no reason to set TNS_ADMIN. However, if you have multiple client products, each with its own ORACLE_HOME (say, you install the base client, then install SQL Devloper) you are faced with maintaining two separate tnsnames files. There are various ways to approach this problem, but the simplest is to simply pick one, and set TNS_ADMIN to point to it. As I demonstrated above, if using TNS_ADMIN, the files don’t even have to be in any ORACLE_HOME directory. I’d even argue that this is preferable, as it makes it very clear to anyone examining the system that there is no implied linkage between your TNS config files and any particular ORACLE_HOME.

Next up: ora-12154 and tns-03505

Film at eleven.