This question already has answers here:
Sequence number in table
(2 answers)
Closed 5 years ago.
I would like to know if there is a way to find out which sequences are associated with a given Oracle table.
There is no way in general, short of searching the source code or v$sql or finding common dependencies in all_dependencies, because sequences created with create sequence are independent objects that you can use however you like.
From Oracle 12.1, if you define an identity column this will generate a system-defined sequence with a name like ISEQ$$_1744544. You can find these in all_tab_identity_cols together with the table and column they were created for.
Related
This question already has an answer here:
How to Log Alter Column DDL Operations
(1 answer)
Closed 2 years ago.
I know how to find the last DDL for standalone procedures. Is there a way to do it for procedures written inside a package?
I think you can not. In any of USER_/ALL_/DBA_ OBJECTS, LAST_DDL_TIME column is related to the whole object - in your case, a package. Procedures that are part of the package aren't tracked.
So, you know when package was modified, but can't tell which part was it.
This question already has answers here:
PL/SQL Performance Tuning for LIKE '%...%' Wildcard Queries
(5 answers)
Closed 5 years ago.
I have a table that has among others, two columns
SPONSOR_ID number
NR_CERTIFICATE char(11)
And there's a index for these two columns
NR_CERTIFICATE + SPONSOR_ID
This table has hundreds of thousands of rows, and the problem is, when we filter by a specific certificate, the select takes nanoseconds as expected:
SELECT * FROM TBL_XXX WHERE NR_CERTIFICATE = '33300123456'
the problem is when we use LIKE to filter:
SELECT * FROM TBL_XXX WHERE NR_CERTIFICATE LIKE '%123456'
Then the select takes around 15 seconds.
I know that in this case, the index is discarded and a table scan takes place. Is there a way to force ORACLE to use the index in this case? Or is there a way to speed up this select?
You can "force" the index use with optimizer hints :
SELECT /*+INDEX(TBL_XXX,YOUR_INDEX_NAME)*/ *
FROM TBL_XXX
WHERE NR_CERTIFICATE LIKE '%123456'
That answers the question but not sure if that will solve your issue. You should show the table struct and explain plan for further help
If you force the use of the index with an hint, Oracle will do a full index scan.
It will not be interesting for you.If your query has a sense, maybe your data model is not appropriate. Maybe a good way is to split you column nr_certificate in two columns. If it's possible, it will be easy to you after to have the good and quick query.
This question already has an answer here:
Alternate method to global temp tables for Oracle Stored Procedure
(1 answer)
Closed 8 years ago.
I need a way to temporarily store and use multiple values returned from an Oracle query. In SQL Server, I stored my values in a temp table, did my work, then dropped the table. I'm discovering the Oracle equivalent isn't as clear cut.
Here's a SQL Server example of what I'm trying to do:
select id into #temp from SomeTable where SomeColumn = 'Some Value'
:
(do whatever I need to do with #temp data)
:
drop table #temp
I can code my way around SQL Server pretty well, but am almost clueless when it comes to Oracle syntax. I've been reading various Oracle references, and they haven't been very helpful. I did read that Oracle temp tables work differently than SQL, and are often not recommended.
I'm looking into the temp table route, but if there's a better way to do this that doesn't use temp tables, I'm all ears. Anyone know a better way to do this in Oracle?
Thanks in advance.
As with many things, that depends. It depends on how much data you'll be retrieving and how you want to use it. If you don't have too much data to work with ("too much" meaning, oh, say, more than a couple thousand rows) and you want to manipulate the data procedurally, i.e. in a PL/SQL procedure or script, AND you don't want to access it using DML, i.e. you don't want to say something like SELECT * FROM your_temp_data... than loading the data into a PL/SQL collection, as #EgorSkriptunoff mentions above, might be a workable solution.
However, if the temp data is large (more than a couple thousand rows) and/or you need to be able to do something like SELECT * FROM your_temp_data... then your best bet it to use Oracle's Global Temp Tables. A GTT is a table which is used to hold data which should only last as long as either a single transaction or a complete session (i.e. as long as you're attached to the database). Documentation here and here, and another write-up on them here.
Share and enjoy.
This question already has answers here:
Auto-increment in Oracle without using a trigger
(9 answers)
Closed 8 years ago.
I want the first column of a table in PLSQL to be auto-increment.That column will be the primary key for that table. I heard something called serialize but i didn't get proper description about that. i was working in SQL Server. I am new to Oracle(PLSQL). Please help me to find out a proper solution.
Create a sequence
CREATE SEQUENCE name_of_sequence
START WITH 1
INCREMENT BY 1
CACHE 100;
Create a trigger
CREATE OR REPLACE TRIGGER trigger_name
BEFORE INSERT ON table_name
FOR EACH ROW
BEGIN
SELECT name_of_sequence.nextval
INTO :new.name_of_primary_key_column
FROM dual;
END;
The syntax of the trigger gets a little simpler in 11g since you can do a direct assignment to the :new.name_of_primary_key_column rather than selecting from dual. And I understand that there is some additional syntactic sugar in 12c that makes this even easier though I haven't played around with that.
This question already has answers here:
How to put more than 1000 values into an Oracle IN clause [duplicate]
(11 answers)
Closed 9 years ago.
I want to use more than 1000 value with IN Clause that is not supported by this clause. eg.
select prodCode from Products where prodId IN (1,2,3.....,1020);
Can someone suggest me for any alternate solution??
Where did the values for prodId that you are putting into your IN clause originate from?
If they originated from another query, then you should combine the two queries.
If they originated from some complicated process or an external data source, then you should store them in a temporary table. The temporary table can just contain a prodId column. Join to that table instead of using an IN list.