I need to rename bunch of sequences in another schema.
RENAME old_seq to new_seq doesnt work.
Tried:
ALTER SEQUENCE old_seq RENAME TO new_seq;
but it gives me error
ORA-02286: no options specified for ALTER SEQUENCE
I do not wish to mention all the options that i had mentioned earlier while creating the sequence, since they need to be same. Only the name needs to be changed.
If you are not the owner of that sequence, You can use following steps:-
SELECT CURVAL FROM old_seq;
This will give you the value of Current_Sequence.
Now Drop this sequence using
DROP SEQUENCE old_seq;
And Create new Sequence with same name. Using
CREATE SEQUENCE old_seq;
And then alter that with this:-
ALTER SEQUENCE seq_example INCREMET BY <CURVAL FROM OLD VALUE>;
The answer from #ankit is quite in line with what's needed to fix this issue but it presents a few problems and typos which I'm fixing in this answer. I hope it'd be useful.
First, you have to select the current value for the old_seq:
SELECT old_seq.CURRVAL FROM dual;
If you get an ORA-08002 error that's because you need to ask for the NEXTVAL first in order to initialize the sequence. Just do:
SELECT old_seq.NEXTVAL FROM dual;
and then ask for CURRVAL again.
Now that you have the current value, just drop the old sequence by using
DROP SEQUENCE old_seq;
and create the new_seq with the name you want by using
CREATE SEQUENCE new_seq START WITH <CURRVAL FROM old_seq>;
If you use INCREMENT instead of START WITH, you should take into account that the increment would apply to every request for a value from the sequence. You would have to create the sequence and then reset the increment to 1. Using START WITH avoids that issue.
You can rename it straight out:
rename old_sequence to new_sequence;
It would say table renamed but you can ignore it. Your sequence will be renamed.
Try it.
Related
I need to rename the sequences of my tables. There are a lot of tables and they are complex and droping anything would not be prefered. Is there a way to rename them?
I tried:
ALTER SEQUENCE ISEQ$$_149698 RENAME TO NEW_SEQUENCE;
RENAME ISEQ$$_149698 to NEW_SEQUENCE;
The first option throws the following error:
SQL Error [2286] [42000]: ORA-02286: no options specified for ALTER SEQUENCE
The second:
SQL Error [32799] [99999]: ORA-32799: cannot rename a system-generated sequence
You cannot rename a sequence generated for an identity column. (As other users have pointed out, and as the error message implies.) For that reason, I recommend you use a sequence default value instead of an identity column.
For example:
--Create the sequence and a table to use it.
create sequence my_sequence;
create table my_table(a number default my_sequence.nextval, b number);
--Rename the sequence to whatever you want.
rename my_sequence to my_sequence2;
However, there are a few disadvantages of the default approach:
This feature is not available until 12.1. (Although identity columns are also a new feature.)
You have to create the sequences yourself (obviously).
You need to remember to also grant the sequence to any users who will insert rows to the table:
grant insert, select on my_table to test_user;
grant select on my_sequence to test_user;
If you rename a default sequence you must also modify the default value to point to the new sequence.
--Afate a sequence rename, this INSERT fails with: ORA-02289: sequence does not exist
insert into my_table(b) values(1);
--You must first modify the table:
alter table my_table modify a number default my_sequence2.nextval;
--Now this will run:
insert into my_table(b) values(1);
Despite the disadvantages of using the sequence default, I still prefer that approach over identity columns because I want all of my objects to have the exact same name in every environment.
rename old_seq to new_sequence;
In the project I'm working at the Id for certain insert statements is managed by hdbsequences. Now I want to create a sequence for another table that already has existing data in it and I want it to start with the max id value of the data of that table.
I know I could just manually set the "start_with"-Property to it but that is not an option because we need to transport the sequence to another system later where the data in that corresponding table is not the same as on the current system (therefore the ID is different).
I also know of the "reset_by"-Property in which I can select the max value of the table, the problem is that I don't know how to trigger that explicitly.
What I already found out, is that the "reset_by"-Property is called whenever the database is restarted, but unfortunately that is not also not an option because we can't reset the database to not disrupt the other systems.
Thanks in advance for your time and help.
You can do an ALTER SEQUENCE and set the value to be used by the next sequence usage with the option "restart with".
For instance (schema name and sequence name have to be replaced):
alter sequence "<schema name>"."<sequence name>" restart with 100;
The integer value behind the "restart with" option has to be set to the value which has to be used next. So in case your last ID is 100, set it to 101. 101 is the value returned by the next NEXTVAL call on the sequence.
We use a sequence in a Db2 database. Recently, we have migrated the data from an AIX server to a Linux server. During that the latest number of that sequence was not moved to the Linux system. As a consequence, we are seeing duplicates values now.
Here is how we use the sequence:
SELECT NEXTVAL FOR SEQ_YFS_ORDER_NO FROM SYSIBM.SYSDUMMY1
The current value of the sequence on Linux is 100092142. How can I update it to the current value that we have on the AIX system, i.e to (100110960)?
You can modify the sequence using ALTER SEQUENCE. An option offered by ALTER SEQUENCE is to RESTART it with a specific value. Try something like this:
ALTER SEQUENCE SEQ_YFS_ORDER_NO RESTART WITH 100110960
Also note that sequence numbers typically are cached. This may lead to a gap and could have caused the issue during the migration.
Use the below query to fetch next sequence value from DB2 database.
SELECT NEXT VALUE FOR "Sequence_name" FROM SYSIBM.SYSDUMMY1
Work Around
ALTER SEQUENCE SEQ_YFS_ORDER_NO INCREMENT BY (100110960-100092142);
SELECT SEQ_YFS_ORDER_NO FROM dual;
ALTER SEQUENCE SEQ_YFS_ORDER_NO INCREMENT BY 1;
Before backup of your database, you can too create one Stored Procedure to SET "START WITH" with current_value to all your SEQUENCES, so when you will do restore, they will be restored with your desired starts.
I recently created a SQL dump of a database behind a Django project, and after cleaning the SQL up a little bit was able to restore the DB and all of the data. The problem was the sequences were all mucked up. I tried adding a new user and generated the Python error IntegrityError: duplicate key violates unique constraint.
Naturally I figured my SQL dump didn't restart the sequence. But it did:
DROP SEQUENCE "auth_user_id_seq" CASCADE;
CREATE SEQUENCE "auth_user_id_seq" INCREMENT 1 START 446 MAXVALUE 9223372036854775807 MINVALUE 1 CACHE 1;
ALTER TABLE "auth_user_id_seq" OWNER TO "db_user";
I figured out that a repeated attempt at creating a user (or any new row in any table with existing data and such a sequence) allowed for successful object/row creation. That solved the pressing problem.
But given that the last user ID in that table was 446 - the same start value in the sequence creation above - it looks like Postgresql was simply trying to start creating rows with that key.
Does the SQL dump provide the wrong start key by 1? Or should I invoke some other command to start sequences after the given start ID? Keenly curious.
The dump is fine, no problem. If your code (or default value for the column) uses nextval() to get the next value from the sequence, everything will be fine as well. Check your code and see what it does, what SQL is executed. With this information you can see why things are going wrong.
Good luck!
I've just wasted the past two hours of my life trying to create a table with an auto incrementing primary key bases on this tutorial, The tutorial is great the issue I've been encountering is that the Create Target fails if I have a column which is a timestamp and a table that is called timestamp in the same table...
Why doesn't oracle flag this as being an issue when I create the table?
Here is the Sequence of commands I enter:
Creating the Table:
CREATE TABLE myTable
(id NUMBER PRIMARY KEY,
field1 TIMESTAMP(6),
timeStamp NUMBER,
);
Creating the Sequence:
CREATE SEQUENCE test_sequence
START WITH 1
INCREMENT BY 1;
Creating the trigger:
CREATE OR REPLACE TRIGGER test_trigger
BEFORE INSERT
ON myTable
REFERENCING NEW AS NEW
FOR EACH ROW
BEGIN
SELECT test_sequence.nextval INTO :NEW.ID FROM dual;
END;
/
Here is the error message I get:
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-320: the declaration of the type of this expression is incomplete or malformed
Any combination that does not have the two lines with a the word "timestamp" in them works fine. I would have thought the syntax would be enough to differentiate between the keyword and a column name.
As I've said I don't understand why the table is created fine but oracle falls over when I try to create the trigger...
CLARIFICATION
I know that the issue is that there is a column called timestamp which may or may not be a keyword. MY issue is why it barfed when I tried to create a trigger and not when I created the table, I would have at least expected a warning.
That said having used Oracle for a few hours, it seems a lot less verbose in it's error reporting, Maybe just because I'm using the express version though.
If this is a bug in Oracle how would one who doesn't have a support contract go about reporting it? I'm just playing around with the express version because I have to migrate some code from MySQL to Oracle.
There is a note on metalink about this (227615.1) extract below:
# symptom: Creating Trigger fails
# symptom: Compiling a procedure fails
# symptom: ORA-06552: PL/SQL: %s
# symptom: ORA-06553: PLS-%s: %s
# symptom: PLS-320: the declaration of the type of this expression is incomplete or malformed
# cause: One of the tables being references was created with a column name that is one of the datatypes (reserved key word). Even though the field is not referenced in the PL/SQL SQL statements, this error will still be produced.
fix:
Workaround:
1. Rename the column to a non-reserved word.
2. Create a view and alias the column to a different name.
TIMESTAMP is not listed in the Oracle docs as a reserved word (which is surprising).
It is listed in the V$RESERVED_WORDS data dictionary view, but its RESERVED flag is set to 'N'.
It might be a bug in the trigger processing. I would say this is a good one for Oracle support.
You've hinted at the answer yourself. You're using timestamp as a column name but it's also a keyword. Change the column name to something else (eg xtimestamp) and the trigger compiles.
Well, I'm not totally sure about it, but I think this happens because the SQL code used to manipulate and access database objects is interpreted by some interpreter different form the one used to interpret PL/SQL code.
Have in mind that SQL an PL/SQL are different things, and so they are processed differently. So, I think there is some error in one interpreter, just not sure which one is.
Instead of having Oracle maintain a view, use EXECUTE IMMEDIATE (i.e. if 'Rename the column to a non-reserved word' is not an option.
You can execute via EXECUTE IMMEDIATE. IT's not better way but work's and avoid column rename.
In my case rename column will be a caotic way