Does anyone know why I'm getting this error?
ORA-25153: Temporary Tablespace is Empty
I'm doing a simple SELECT OWNER FROM DBA_TABLES; query and it displays the data properly but when I try to narrow the OWNER columns down then it gives me this error.
SELECT OWNER
FROM DBA_TABLES
WHERE OWNER = 'NAME';
your problem is described perfectly at the following post, but if you don't have DBA rights or knowledge you won't succeed to overcome this error and I strongly suggest you to approach your DBA.
http://www.mydigitallife.info/ora-25153-temporary-tablespace-is-empty-error-in-oracle/
The cause for the ORA-25153 error is because attempt was made to use
space in a temporary tablespace with no files (no datafiles defined).
To solve the problem, the solution is just by adding files (datafiles)
to the TEMP tablespace by using ADD TEMPFILE command, or by using “Add
Datafiles” in Oracle Enterprise Manager.
Related
I am currently building a database in my class in SQL PLSQL.
Using Apex Oracle, I made a huge mistake,installed a new apex theme plugin and set it as my current theme to enhance the UI. This plugin replaced my database with all of its own stuff and my tables and data are nowhere to be found.
Is there a FLASHBACK command for databases? Anything at all? Thank you
You may give Restoring Tables from the Recycle Bin a try, but not very sure if it would work in your case.
May need SYSDBA access
SELECT object_name, original_name, createtime FROM recyclebin;
Alternatively you can use DBA_recyclebin or USER_RECYCLEBIN
Once you find the object(table) that was dropped. you can flashback it using below statement
FLASHBACK TABLE <Your dropped table> TO BEFORE DROP
RENAME TO <Your new table name>;
Read more here
I need to eliminate all remnants of specific users from an Oracle 11g R2 database. This means not only deleting the users one by one, but also deleting all objects associaated with that user, in addition to all physical remnants on the disk, such as .dbf files.
I read several articles suggesting syntax for this, and settled on the following series of two lines for each user:
DROP USER <username> CASCADE;
DROP TABLESPACE <username> INCLUDING CONTENTS AND DATAFILES;
I then typed SELECT USERNAME, DEFAULT_TABLESPACE FROM DBA_USERS; and confirmed that the USER with the specific username was not included in the results.
But I also have the folder containing the .DBF files open, and I notice that the .DBF files are not deleted even though the Oracle SQL Developer interface tells me that both of the two above commands succeeded.
What specific syntax or other actions do I need to take in order to delete EVERY remnant of the user and its associated schema, etc. from an Oracle 11g R2 database?
ONGOING RESEARCH:
After reading #EliasGarcia's approach, I tried his first command select tablespace_name from dba_data_files where file_name = 'file_including_path' for the same username that was used in the preceding commands in the OP. But this query did not produce any results because the table space was deleted by the two commands shown above in my OP.
Given that I have to delete the user and all objects related to the user also, can someone please show how to combine the OP approach with #EliasGarcia's approach? For example, the OP is asking for something like DROP USER username CASCADE INCLUDING CONTENTS AND DATAFILES;
I hesitate to simply delete the .dbf files after running the above commands.
Datafiles are allocated to tablespaces, not users. Dropping the users will remove the tables etc. from the tablespace, but the underlying storage is not affected.
Don't delete the dbf files from the filesystem directly, you'll get your database into a mess. To remove them, find which tablespace the files belong to using the following statement:
select tablespace_name
from dba_data_files
where file_name = <file name with full path>;
You can then remove the file(s) by dropping the tablespace:
drop tablespace <tablespace_name> including contents and datafiles;
Before doing this you should verify that there aren't any objects still allocated to the tablespace for other users however. You can find this by running:
select * from dba_segments
where tablespace_name = <tablespace to drop>;
If this returns anything, move the objects to another tablespace if you want to keep them before dropping the tablespace.
I am using oracle 10g express edition. I ran the command in sql command line and it says -- "ORA-00942: table or view does not exist"
PS: Trying to access and increase the number of processes. Cause I am facing this problem -- How to solve ORA-12516 error?
You're probably running this command as a non-privileged user. show parameter is just a fancy wrapper for select ... from v$parameter. You need SELECT privileges on this view:
grant select on v_$parameter to <username>;
(please note the _ in the view name - you cannot directly grant privileges on v$ views, you have to grant privileges on the underlying objects instead).
Of course, the simplest approach is to run show parameter as a DBA user.
I want to get the number of sessions in Oracle using the SQL query:
SELECT value FROM v$parameter WHERE name = 'sessions'
But I get this error:
Error starting at line 1 in command:
SELECT value FROM v$parameter WHERE name = 'sessions'
Error at Command Line:1 Column:18
Error report:
SQL Error: ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
Maybe the Oracle user that I use is not privileged?
Generally the better approach is to use a procedure and grant the necessary privileges to this procedure. However if you want use SQL directly, you can grant SELECT_CATALOG_ROLE or SELECT ANY DICTIONARY to the user.
Probably. To grant the rights, you need to use the table name as V_$PARAMETER. It comes from some restriction when granting rights on dynamic views.
If you want to use SQL directly (referring to the second option in the accepted answer)
As of Feb 2023, using Oracle version 19, this works...
Connect as SYSTEM and run
grant SELECT ANY DICTIONARY to <user>;
But SELECT_CATALOG_ROLE didn't work for me...
grant SELECT_CATALOG_ROLE to ...;
There are documented differences between the two here:
http://www.petefinnigan.com/weblog/archives/00001461.htm
This is where the author gives the following info and warning:
Well, SELECT_CATALOG_ROLE allows access to some things Oracle deemed not allowed by SELECT ANY DICTIONARY so we need to be careful of granting this role on these grounds. BUT, the overwhelming issue for me is that SELECT_CATALOG_ROLE gives access to 4539 objects and SELECT ANY DICTIONARY gives access to 6228 objects (both numbers in 18c XE)
I am not sure why Oracle do not publish the full list of exclusions in SELECT ANY DICTIONARY but they do publish all of the main tables. We can easily find out anyway. For me, i want to know what does SELECT ANY DICTIONARY really mean. I want to know what i am actually granting if I give out that privilege; well it means access to 6228 tables and views in 18cXE
Both of these rights should not be used; they are a sledgehammer to crack a peanut. If someone needs access to V$SESSION or V$DATABASE and there is a legitimate reason to have that access then grant access on the individual views not SELECT ANY DICTIONARY or SELECT_CATALOG_ROLE.
using the privileges: - select any table, alter any table when running the grant as SYS with SYSDBA in Oracle 12c solved the issue for me.
I am using insert statement and trying to insert data into the database table. I am using stored procedures.
But I am getting this error while doing so.
Message: ORA-00942: table or view does
not exist ORA-06512
I checked if the tables/stored procedures are present or not and everything is in place. Also there is no typo in table names or in sp. If I run the part of SP from query editor it works fine but when I execute the entire SP it throws an error.
I tried the steps provided by Stephen but since I have logged in with the same user/owner when I run Grant command it gives me an error saying 'Cannot Grant/revoke on own'.
One more addition to this. I have a stored procedure SP1 in which I am using a select statement as
Select a from table_name where condition;
When I execute this seperately, it returns me some results. But when I execute sp it gives an error at the same line where it is written.
Can anyone help me out to resolve this issue. I am using SQL +.
Thanks in advance
Vijay
Justin's answer is correct but let me expand a bit.
Everyone who said that the table doesn't exist didn't read your whole post. Since you are able to:
If I run the part of SP from query editor it works fine
Obviously the table is there.
Obviously you have some access to it. Otherwise this wouldn't work when it clearly does.
but when I execute the entire SP it throws an error.
This is because Oracle distinguishes between permissions granted directly and those granted via a role.
Say I do this:
Create Table TABLE_A
Create Role READ_ONLY
Grant Select on TABLE_A to READ_ONLY
Grant READ_ONLY to VIJAY
In a SQL Window/prompt you could query that table without issue. So now you need to create a view
Create VIJAY.VIEW_A as SELECT * FROM TABLE_A
You'll get the error that TABLE_A does exist. Because a view is compiled, like a procedure it runs without any roles. Since it runs without the READ_ONLY role, it's blind to the fact that TABLE_A exists. Now what I need to do is
Grant Select on TABLE_A to VIJAY.
Now that you have a direct permission, you can compile a view or procedure/package that uses that table.
Does the table exist in the schema where the stored procedure exists? If not, the simplest explanation is that the owner of your procedure has been granted access to the table via a role not via a direct grant. A definer's rights stored procedure needs to have direct access to the objects it accesses. A quick way to test this is to disable roles for the session, i.e.
SQL> set role none;
SQL> <<execute your query>>
If that generates the error, the problem is the lack of a direct grant.
In Oracle you can choose if the stored procedure is executed with the rights of the invoker or the definer: http://download.oracle.com/docs/cd/E11882_01/appdev.112/e17126/subprograms.htm#i18574
Check if the AUTHID property of the stored procedure is correct and if the resulting user has appropriate permissions.
Well, put very simply, the table that you are trying to insert data into does not exist in the database you are connected to. You need to check both those things (i.e. what are you connected to, and is the table there and accessible for the user context you are using).
As Joe Stefanelli said .. there are a lot of possibilities for the error being shown here.
Check whether:
You are connecting to the correct Oracle Instance.
You have permissions to query or perform processing on table that you are referencing in your query.
There is a difference between ordinary select statements and procedures. Procedures in oracle do not respect the roles assigned to a user; rather the permission needs to be explicitly granted to the user. For more information read the following linkORA-00942