views:

69

answers:

3

I have to fetch all sequences with their table name along with the column name on which sequence is applied .Some how i managed to fetch table name corresponding to sequence because in my data base sequence is stored with first name as table name from data dictionary(all_sequences and all_tables) .

Please let me know how to fetch corresponding column name also if possible!!

+6  A: 

In Oracle, a sequence is an independent object, it's not associated with a specific table or column. For example, you can run this query to get a list of the sequences:

SELECT * FROM all_sequences

And when you create a sequence, you'll notice that there's nothing in the CREATE SEQUENCE syntax to indicate that you want to associate it with a table or column.

A sequence is just a unique number generator, it doesn't care what you do with the number generated from it (i.e. whether you insert the sequence value into a table, etc.), it's just there to provide that unique number.

So it's impossible to tell for a given column what sequence was used (if any) to generate that column's value.

dcp
A: 

See dcp's answer.

However, a sequence will normally be used to generate a unique key for the table it corresponds to - try looking for primary keys and/or unique indexes on the matching table.

Mark Bannister
@Mark Bannister - I think it really depends. In my shop, we use one sequence for each schema, not each table.
dcp
@dcp - sorry, I shouldn't have said "normally". However, in Vineet's case, it looks as though the sequences do correlate to specific tables. I just hope there isn't more than one sequence per table...
Mark Bannister
@Mark: How do you define "Corresponds to" and "matching"? Why is more than one sequence per table a bad thing?
Stephanie Page
@dcp, what do you set for its cache?
Stephanie Page
@Stephanie Page - Not sure I know what you mean, can you clarify?
dcp
@Stephanie: As DCP notes, a sequence can be used across multiple tables. However, it seems to be more common (in my experience) to use a given sequence to generate unique keys for a specific table - in such circumstances, the name of the sequence is typically based on the name of the table (as appears to be true for Vineet). This is what I mean by "corresponds to" and "matching".
Mark Bannister
@Stephanie: More than one sequence per table would be a bad thing for two reasons - firstly, because it implies that either there is more than one unique key for the table, or (worse) because two different sequences may be being used to generate "unique" key values for the same key field, with the probable end result of generating duplicate values for different records. Secondly, because it will make Vineet's job harder.
Mark Bannister
@Mark, I'm not sure why you assume there would be duplicate values or two keys. There's an increment by clause to the Create Sequence and a Starts With clause. Two sequences for the same key, Start one at 1 and the other at 2 and increment both by 2. One sequence will generate even number and the other odd -- in the same key. Whether or not it makes Vineet job harder is irrelevant. He's not creating the Seqs, just querying for existing ones. We don't know if the database designer did so or not.
Stephanie Page
@dcp, a sequence has a cache clause? You're using 1 sequence for an entire schema and haven't explored the effect of cache? Ok, so this is a very low concurrency database? Not a lot of simultaneous inserts?
Stephanie Page
@Stephanie: you could do that, but why would you want to?
Mark Bannister
@Stephanie Page - Actually, I was not aware of the cache clause for sequences, thank you for pointing it out.
dcp
This is very common technique for "distributed" apps. Beats a GUID, so long as you have some idea the total number of nodes and leave room. The point is it can happen, it's not by default bad, it has a valid purpose...
Stephanie Page
@dcp, very, very important for performance. If it's a big-boy enterprise app. If it's your family's coin manager app then it won't matter. The fact that you're using only one means you could be serializing many complete disparate processes together. This is one of those things in the "works but doesn't scale well" category. Things in that category are often never an issue since most apps never push the limits. Run-of-the-mill apps... don't worry... Big-boy enterprise apps, raise you cache and start migrating away from only one.
Stephanie Page
+1  A: 

You can often 'guess' at a correlation by looking at the LAST_NUMBER in all_sequences and the following SQL (which looks at the highest number for numeric columns defined as part of a primary key).

select table_name, column_name, utl_raw.cast_to_number(high_value) 
from dba_tab_columns
where owner = '...'
and data_type = 'NUMBER'
and (owner, table_name, column_name) in 
  (select cc.owner, cc.table_name, cc.column_name
  from dba_cons_columns cc 
     join dba_constraints c 
       on cc.owner = c.owner and cc.constraint_name = c.constraint_name
  where c.constraint_type = 'P')
order by 3;

But it is a good idea to adopt a naming standard that indicates the correlation (eg the same as the table_name with a _SEQ on the end).

Gary