While running our process random tables are getting created with name like this BIN$xGf2aDIQ07bgUxnq9QrvVw==$0. Not sure how are they getting generated by themselves. Any idea?
These are objects in recycle bin, e.g.
SQL> select * From tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
ADHERENT TABLE
ADMIN_REGISTRATION TABLE
AUDIT_TABLE TABLE
AUDIT_TBL1 TABLE
BASE TABLE
BIN$v05hK8D0Y6HgU8lkAQqVqw==$0 TABLE
BIN$v05rTFDqUODgU8lkAQo1og==$0 TABLE
BIN$v05rTFDrUODgU8lkAQo1og==$0 TABLE
BIN$v05rTFDwUODgU8lkAQo1og==$0 TABLE
BIN$v3OGPz/pGrngU8lkAQoglg==$0 TABLE
BIN$v3OGPz/qGrngU8lkAQoglg==$0 TABLE
<snip>
How do objects get there? When you drop them. If you don't need them (i.e. you won't be retrieving anything from recycle bin), simply purge it:
SQL> purge recyclebin;
Recyclebin purged.
SQL> select * From tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
ADHERENT TABLE
ADMIN_REGISTRATION TABLE
AUDIT_TABLE TABLE
AUDIT_TBL1 TABLE
BASE TABLE
BONUS TABLE
BOOK TABLE
<snip> --> see? no more BIN$...
These objects created when you drop a table.
Ex:
drop table xyz;
but if you drop table with purge, the recyclebin tables does not get created
drop table xyz purge;
to delete these recyclebin tables you can use
purge recyclebin;
you can also delete recyclebin table one by one
PURGE TABLE test;
or
PURGE TABLE BIN$v05rTFDrUODgU8lkAQo1og==$0;
Related
Iam facing a issue while altering the GTT table.
I need to find the active users on that table, Can someone help in query regarding how to find the active users on the specific object in oracle database
As far as I can tell, you didn't explain what problem you're trying to solve, but rather what you think that might help you solve it. So, let me try to guess.
Here's a global temporary table (GTT):
SQL> create global temporary table gtt (id number) on commit preserve rows;
Table created.
SQL> insert into gtt values (1);
1 row created.
SQL> commit;
Commit complete.
You're trying to alter it, but - it fails:
SQL> alter table gtt add name varchar2(10);
alter table gtt add name varchar2(10)
*
ERROR at line 1:
ORA-14450: attempt to access a transactional temp table already in use
OK, so - delete row(s) and commit, then try again:
SQL> delete from gtt;
1 row deleted.
SQL> commit;
Commit complete.
SQL> alter table gtt add name varchar2(10);
alter table gtt add name varchar2(10)
*
ERROR at line 1:
ORA-14450: attempt to access a transactional temp table already in use
Still no luck. But, if you truncate the table, then it works:
SQL> truncate table gtt;
Table truncated.
SQL> alter table gtt add name varchar2(10);
Table altered.
SQL>
If that's not what you're after, then see if this answers your question: connect as a privileged user (such as SYS, if you don't have any other) and run such a query: it shows who owns the GTT, its name, who locked it (which Oracle user) and which operating system user is it (that might help you to contact those people):
SQL> select b.owner,
2 b.object_name,
3 a.oracle_username,
4 a.os_user_name
5 from v$locked_object a, dba_objects b
6 where a.object_id = b.object_id;
OWNER OBJECT_NAM ORACLE_USERNAME OS_USER_NAME
--------------- ---------- --------------- ------------------------------
SCOTT GTT SCOTT littlefoot
SQL>
I'm using Oracle and I have a strange thing.
I dropped a table using :
drop table t_my_table, and committed.
But when I launch select * from t_my_table, it shows the data, as if the table is not dropped.
I tried disconnecting and reconnecting, it stills shows the data when I select.
And when I once again try with :
drop table t_my_table, it tells me that this table does not exist.
But if I run select again, the data is always there.
How is this possible ?
Thank you.
You mean this case?
create view t_my_table as
select 'I''m here' as txt from dual;
drop table t_my_table;
ORA-00942: table or view does not exist
But
select * from t_my_table;
TXT
--------
I'm here
solution of the most probably cause
select OBJECT_TYPE from user_objects where object_name = 'T_MY_TABLE';
OBJECT_TYPE
-------------------
VIEW
You defined a view (or other object type other than TABLE), that can't be dropped with DROP TABLE, but can be selected.
Simple check in USER_OBJECTS the OBJECT_TYPE. You may alternatively see also SYNONYM as proposed in other answer.
Note that it is not a MATERIALIZED VIEW as if you try to drop a Materialized View with DROP TABLE a different error message is raised:
ORA-12083: must use DROP MATERIALIZED VIEW to drop T_MY_TABLE
What does this return?
select * from all_synonyms
where synonym_name = 'T_MY_TABLE';
I suspect there is a synonym T_MY_TABLE that points to a table in a different schema.
drop table t_my_table purge;
Specify PURGE if you want to drop the table and release the space associated with it in a single step. If you specify PURGE, then the database does not place the table and its dependent objects into the recycle bin.
...
Using this clause is equivalent to first dropping the table and then purging it from the recycle bin. This clause lets you save one step in the process. It also provides enhanced security if you want to prevent sensitive material from appearing in the recycle bin.
Probably something different is happening.
Normal case would be:
SQL> create table t1 as select 1 a from dual;
Table T1 created.
SQL> drop table t1;
Table T1 dropped.
SQL> select * from t1;
Error starting at line : 22 in command -
select * from t1
Error at Command Line : 22 Column : 20
Error report -
SQL Error: ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
So what was the message after the drop table?
Is t_my_table really a table?
Try select * from all_objects where lower(object_name) = 't_my_table'
I am working on our database users privileges, and I am facing a confusing issue. I first created a user (user1) without any quota and grant him the role CONNECT which have the system privilege (Create Session). After that I grant him the (Create Table) privilege. The user try to create a table and he succeeded to create a table in his tablespace!! my questions are:
Based on my understanding, the user must have a quota to create any objects, how this user created the table?
Is there any privilege or roles that give the user a quota implicitly?
Regards,
A quota isn't being granted implicitly. But creating a table doesn't necessarily require any storage, and so doesn't necessarily require a quota:
create table t42 (id number);
Table T42 created.
select segment_type, bytes from user_segments where segment_name = 'T42';
no rows selected
Adding data to the table does require storage, and therefore a quota:
insert into t42 (id) values (1);
1 row inserted.
select segment_type, bytes from user_segments where segment_name = 'T42';
SEGMENT_TYPE BYTES
------------------ ----------
TABLE 65536
If the owner doesn't have a quota on the tablespace then they will get an error when they try to insert; which is the case when they do have a quota and try to exceed it too of course (though the error will be different).
This behaviour is due to deferred segment creation; the default behaviour is controlled by an initialisation parameter. You can override that during table creation with the segment creation clause.
drop table t42 purge;
Table T42 dropped.
create table t42 (id number) segment creation immediate;
Table T42 created.
select segment_type, bytes from user_segments where segment_name = 'T42';
SEGMENT_TYPE BYTES
------------------ ----------
TABLE 65536
Read more in the documentation.
Incidentally, if you create a table with deferred segment creation then dbms_metadata.get_ddl shows that; if you then insert a row to force a segment to be created, dbms_metadata.get_ddl changes to SEGMENT CREATION IMMEDIATE. Which might not be expected. Truncating the table with the DROP ALL STORAGE clause will remove the segments, and revert the DDL to SEGMENT CREATION DEFERRED. Just something I noticed in passing.
When I create a GLOBAL TEMPORARY TABLE in Oracle 11g (11.2.0.1.0), and then add a new column to it, Oracle does not update the LAST_DDL_TIME column of the system catalog views (e.g. DBA_OBJECTS):
create global temporary table test# (foo varchar2(3));
select last_ddl_time from dba_objects where object_name='TEST#';
-- Shows created time
-- Wait a minute
alter table test# add (bar varchar(3));
select last_ddl_time from dba_objects where object_name='TEST#';
-- Shows NO UPDATE
-- Wait a minute
alter table test# drop (bar);
select last_ddl_time from dba_objects where object_name='TEST#';
-- Shows time when column was dropped
However, when I execute the same sequence of SQL statements in Oracle 12c (12.1.0.2.0), then LAST_DDL_TIME does reflect newly-added columns.
create global temporary table test# (foo varchar2(3));
select last_ddl_time from dba_objects where object_name='TEST#';
-- Shows created time
-- Wait a minute
alter table test# add (bar varchar(3));
select last_ddl_time from dba_objects where object_name='TEST#';
-- Shows time when column was added
-- Wait a minute
alter table test# drop (bar);
select last_ddl_time from dba_objects where object_name='TEST#';
-- Shows time when column was dropped
This behavior appears to be very specific to adding columns to GLOBAL TEMPORARY TABLES, and to Oracle 11g; renaming or dropping columns does affect LAST_DDL_TIME as expected.
Is this a known Oracle 11g bug?! If so, is there an official Oracle patch update for it?
I want to find the recently added column to existing table.
How to find recently added column in table or database(oracle).
Recently the table and the databases of our web application got modified and some of the table got altered.
Ideally you should have restricted access to your Production database, together with a build process which applies scripts out of source control, rather than allowing people to change things using TOAD. It's pretty hard to conduct forensics in a free-fire zone.
You can find out which tables have changed by interrogating the data dictionary:
SQL> select object_name from user_objects t
2 where t.object_type = 'TABLE'
3 and t.last_ddl_time > trunc(sysdate)
4 /
no rows selected
SQL> alter table t23 add col_3 number
2 /
Table altered.
SQL> select object_name from user_objects t
2 where t.object_type = 'TABLE'
3 and t.last_ddl_time > trunc(sysdate)
4 /
OBJECT_NAME
----------------------------------------------------------
T23
SQL>
This won't tell you what the change was, or who did it. To get better information you need a proper audit trail. At the very least you should enable auditing of DDL statements....
SQL> audit ALTER TABLE;
Audit succeeded.
SQL>
Find out more.