Home
All Oracle Error Codes
Oracle DBA Forum

Frequent Oracle Errors

TNS:could not resolve the connect identifier specified
Backtrace message unwound by exceptions
invalid identifier
PL/SQL compilation error
internal error
missing expression
table or view does not exist
end-of-file on communication channel
TNS:listener unknown in connect descriptor
insufficient privileges
PL/SQL: numeric or value error string
TNS:protocol adapter error
ORACLE not available
target host or object does not exist
invalid number
unable to allocate string bytes of shared memory
resource busy and acquire with NOWAIT specified
error occurred at recursive SQL level string
ORACLE initialization or shutdown in progress
archiver error. Connect internal only, until freed
snapshot too old
unable to extend temp segment by string in tablespace
Credential retrieval failed
missing or invalid option
invalid username/password; logon denied
unable to create INITIAL extent for segment
out of process memory when trying to allocate string bytes
shared memory realm does not exist
cannot insert NULL
TNS:unable to connect to destination
remote database not found ora-02019
exception encountered: core dump
inconsistent datatypes
no data found
TNS:operation timed out
PL/SQL: could not find program
existing state of packages has been discarded
maximum number of processes exceeded
error signaled in parallel query server
ORACLE instance terminated. Disconnection forced
TNS:packet writer failure
see ORA-12699
missing right parenthesis
name is already used by an existing object
cannot identify/lock data file
invalid file operation
quoted string not properly terminated

RE: Table Joins

Mark W. Farnham

2006-05-25

Replies:
That was a pretty slick way to benchmark the comparison filter costs.

For the original poster I'm wondering whether they are looking for the
solution to a particular case or for a development guideline.

For a particular case, I'll echo the "measure it" sense of the thread.

For a development guideline, my prediction is that over a wide range of
joins of a wide range of objects, that numbers will indeed win.

It appears from the results below that number have a little less than a 1
percent advantage on the comparison, and your mileage may vary.
For example, if you used rownum+a quadrillion, then the character
comparisons will probably take longer by a bigger margin. (Gints - if you do
that on exactly your system for comparison that might be useful to the
thread.)

Cross type comparisons, as Gints succintly demonstrated, are significantly
more expensive.

Over the broad case of pre-designed queries and joins, you'll probably have
indexes of proper types designed to support the joins, and the number of
"keys" per block and row to block selectivity will probably dominate.
Numbers are not always shorter than character fields, but usually they are
in cases of large numbers of rows and reasonable row selectivity. If two
indexes of roughly equal row to block cohesion have different depths due to
size at the steady state number of rows you expect to have in the table,
that will make a difference unless the join is traversing the leafs (leaves
if you prefer).

So whatever produces a smaller overall key tends to be good.

Whatever tends to have correspondence to the order new rows are inserted
into the database tends to be good, because that tends to result in good row
to block cohesion. Generating a need for later periodic maintenance of row
to block cohesion with respect to a join key at design time is a bad idea.
(And in some specific expensive cases such periodic maintenance is one of
the few remaining valid justifications for rebuild maintenance, meaning bad
working hours for DBAs, which in turn is bad for your data since sleep
deprivation is a leading cause of operator error.) Sequence generated
artificial numeric keys, aside from any bugs in any versions or data
accidents that may generate tree skewing that is curable in any case, have
historically had excellent row to block cohesion.

Mark Bobak's advice will probably tend to get you good cohesiveness between
row selection and block selection as well. Following the natural logic of a
situation tends to do that, especially with dates. Also notice that if
generating a numeric key as a proxy for a name means the query will be
forced to do an extra lookup and pull an extra table into the join, that is
not likely to be a win for an individual query where you measure joins, but
it might well be an overall benefit to your relational model.

Jared's advice about using the tool probably tends to get you a small key,
but I'm at a loss to predict whether it will tend to produce row to block
cohesion. It certainly might, and in any case you don't always have a reason
to suspect that one or another key will dominate queries in future use and
that tool is unlikely to be worse than neutral.

If you decide to benchmark entire designs, be extra careful about accidents
of sample size and row to block cohesion. If your data and keys may be
frequently updated in your steady state system, the best row to block
cohesion may also have the side effect of tending to generate hot blocks.
Since the general cure for that is reducing the number of rows per block,
making there tend to be more blocks to handle per query, that is not to be
ignored.

All my musings about tendencies, of course, pale beside testing actuals to
determine what is best when you have actuals to test.

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce@(protected)
Behalf Of Gints Plivna
Sent: Thursday, May 25, 2006 2:42 AM
To: genegurevich@(protected)
Cc: oracle-l
Subject: Re: Table Joins

I'd say that for such a comparison you probably don't even need
anything to join.
For my very very simple test below you can see that difference for
comparison of 5'877'112 rows two identical number columns needed
mostly 01.02 sec but for the same comparison for the same values of
varchar columns needed 01.03 sec.

BUT as you can imagine the worst case is to compare number to varchar2
because it takes 2 times more 02.04 sec.

So that's the real comparison that shoul be avoided.

Of course you can use Kyte's nice tool runstats to get more precise
numbers for more indicators and get better picture of all that.

Gints Plivna

SQL> create table big as select rownum rn1, rownum rn2,
to_char(rownum) rn3, to_char(rownum) rn4
2 from dba_source;

Table created.

Elapsed: 00:00:06.04

SQL> insert into big select * from big;

734639 rows created.

Elapsed: 00:00:04.09
SQL> /

1469278 rows created.

Elapsed: 00:00:09.06
SQL> /

2938556 rows created.

Elapsed: 00:00:19.04
SQL> select count(*) from big where rn1 = rn2;

COUNT(*)
----------
 5877112

Elapsed: 00:00:02.01
SQL> /

COUNT(*)
----------
 5877112

Elapsed: 00:00:01.02
SQL> /

COUNT(*)
----------
 5877112

Elapsed: 00:00:01.02
SQL> /

COUNT(*)
----------
 5877112

Elapsed: 00:00:01.02
SQL> select count(*) from big where rn3 = rn4;

COUNT(*)
----------
 5877112

Elapsed: 00:00:01.03
SQL> /

COUNT(*)
----------
 5877112

Elapsed: 00:00:01.03
SQL> /

COUNT(*)
----------
 5877112

Elapsed: 00:00:01.03
SQL> /

COUNT(*)
----------
 5877112

Elapsed: 00:00:01.03
SQL> select count(*) from big where rn1 = rn3;

COUNT(*)
----------
 5877112

Elapsed: 00:00:02.05
SQL> /

COUNT(*)
----------
 5877112

Elapsed: 00:00:02.04
SQL> /

COUNT(*)
----------
 5877112

Elapsed: 00:00:02.05
SQL> /

COUNT(*)
----------
 5877112

Elapsed: 00:00:02.04


2006/5/25, genegurevich@(protected)
<genegurevich@(protected)>:
> Hi all:
>
> One of my developers insists that joins by numerical fields result in
> better preformance than the joins by
> character fields. I don't remember reading much on this point. Is there
any
> truth in it?
>
> thank you
>
> Gene Gurevich
--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l