Oracle is throwing this error when dropping and creating a table I regularly do without problem.
ORA-12801: error signaled in parallel query server P000, instance MyURL:bwup (3)
ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS3'
I would like to understand conceptually what is happening here and how could I fix this without autoextending the tablespace. I've purged the DB in order to cleanse the space occupied by those recoverable tables recently dropped and stopped throwing the error, but I don't understand why. Is that tablespace that Oracle is talking about common for different processes?
Related
If we specify ONLINE in the CREATE INDEX statement, the table isn't locked during creation of the index. Without ONLINE keyword it isn't possible to perform DML operations on the table. But is the SELECT statement possible on the table meanwhile? After reading the description of CREATE INDEX statement it still isn't clear to me.
I ask about this, because I wonder if it is similar to PostgreSQL or SQL Server:
In PostgreSQL writes on the table are not possible, but one can still read the table - see the CREATE INDEX doc > CONCURRENTLY parameter.
In SQL Server writes on the table are not possible, and additionally if we create a clustered index reads are also not possible - see the CREATE INDEX doc > ONLINE parameter.
Creating an index does NOT block other users from reading the table. In general, almost no Oracle DDL commands will prevent users from reading tables.
There are some DDL statements that can cause problems for readers. For example, if you TRUNCATE a table, other users who are in the middle of reading that table may get the error ORA-08103: Object No Longer Exists. But that's a very destructive change that we would expect to cause problems. I recently found a specific type of foreign key constraint that blocked reading the table, but that was likely a rare bug. I've caused a lot of production problems while adding objects, but so far I've never seen adding an index prevent users from reading the table.
We are trying to enter 1.6M records in a table, however, we are running into the "undo tablespace" error described below. Any suggestions? We looked at other similar errors here, but didn't find a solution.
Couple notes:
We just installed the db application today.
We entered 1.6M records in another table successfully. Didn't commit afterward.
Then, tried adding another 1.6M records into another table and got the error.
Tried committing the first 1.6M records, but still got the error.
Error:
SQL Error: ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1'
30036. 00000 - "unable to extend segment by %s in undo tablespace '%s'"
*Cause: the specified undo tablespace has no more space available.
*Action: Add more space to the undo tablespace before retrying
the operation. An alternative is to wait until active
transactions to commit.
Found the answer. Came across a YouTube video that had enough info to help me piece together the answer (I found the video only OK, but helpful):
https://youtu.be/CSD0JFc9mtw
Couple notes
1) First note that in order to release the space in the UNDO tablespace, you have to "commit" the transaction(s).
2) Second note the UNDO tablespace has a size limit.
3) Last, it also has a retention time, so even after you commit the transaction, you have to wait a defined time before it releases the space to be used.
The third was the part that tripped me up because I couldn't understand why even after commiting the transactions I still was having issue with the UNDO tablespace.
To fix the problem all I had to do was increase the size of the tablespace, then to avoid the problem next time, I reduced the retention time (careful with the second part - see video).
Increase size with this:
ALTER DATABASE DATAFILE 'C:\MYDBLOCATION\UNDOTBS1.DBF' RESIZE 1024M;
Many months ago while shrinking table spaces I mistakenly deleted a table space with out taking backup. There were many indexes which belonged to tables which are a part of that table space.
I never had any problems while inserting or deleting records from tables which belonged to that specific tablespace. But from yesterday I observed that data isn't inserting into many tables due to indexes on it which are giving me error that unique index violated which belong to that specific table space.
Since this morning, I am receiving this error which is caused by a file which was deleted by me:
ORA-00376: file 663 cannot be read at this time
ORA-01110: data file 663: '/oradata/db3/pm/pm4h_db_dat_w_150316_02.dbf'"
How can I overcome this error?
I also now tried to recover the file which gives me this error:
SQL> recover datafile '/oradata/db3/pm/pm4h_db_dat_w_150316_00.dbf';
ORA-00283: recovery session canceled due to errors
ORA-01122: database file 661 failed verification check
ORA-01110: data file 661: '/oradata/db3/pm/pm4h_db_dat_w_150316_00.dbf'
ORA-01207: file is more recent than control file - old control file"
My program creates a database schema. The queries related to tables and/or view creations work just fine but the first insert I do fails with
unable to create INITIAL extent for segment in tablespace SYSAUX
error. It is a straightforward insert in a table that has just two columns, one two strings.
The user is obviously not set to use SYSAUX tablespace and has one on its own so:
I don't understand where a SYSAUX-related failure can come from?
How to fix this?
Is it okay to create an index on a table while , lets say when are there some tasks which creates some new rows into the table at the same time?? Would there be any locking issues???
EX: FEEDBACK TABLE --> creating an index on (Name, feedbackrule) while there are any inserts happening simultaneously , is this BAD?? if so what.
I'm assuming, Oracle will just not use this index when the inserts are happening, later this will be used.
Normally, creating an index requires locking the table, so all the DML operations would block; and if there are active transactions on the table when you initiate the index creation, you'd likely get the error "ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired".
If the table is small, this may not be much of an issue - transactions would just be blocked for a few moments. But if it is very large it would be a bad idea to try creating an index while the table is in use.
However, if you using Enterprise Edition, you can add the ONLINE keyword to your CREATE INDEX statement, which will allow transactions to proceed against the table while the index is building. It may still cause slower performance.