Interesting test case

Question

Hi,
I played a little on my test machine and get interesting results so if someone could explain me what happens here I would be grateful.
It is obvious that some data corruption happened but still interesting situation.
OS: Linux 32bit
Oracle: 10.2.0.2.0
TEST CASE:
1. Created tablespace and one table in that tablespace:
SQL> create tablespace test_tbs datafile '/oradata/tbs01.dbf' size 75M autoextend on next 10M maxsize 512M;
Tablespace created.
SQL> create table objtab tablespace test_tbs as select * from dba_objects where 1=2;
Table created.
2. Made two more copies of tbs01.dbf datafile:
SQL> !cp tbs01.dbf tbs02.dbf
SQL> !cp tbs01.dbf tbs03.dbf
3. Insert some rows into table objtab:
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> /
50417 rows created.
SQL> /
50417 rows created.
SQL> commit;
Commit complete.
SQL> select count(*) from objtab;
COUNT(*)
151251
4. Deleted tbs01.dbf:
SQL> !rm tbs01.dbf
5. Insert still works:
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> commit;
Commit complete.
6. Renamed tbs02.dbf to tbs01.dbf:
SQL> !mv tbs02.dbf tbs01.dbf
7. Inserted new rows:
SQL> select count(*) from objtab;
COUNT(*)
302502
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> commit;
Commit complete.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> commit;
Commit complete.
8. Check size of datafile:
SQL> !du -hs tbs01.dbf
*96M tbs01.dbf*
SQL> select count(*) from objtab;
COUNT(*)
756255
9. Deleted datafile tbs01.dbf and renamed tbs03.dbf to tbs01.dbf:
SQL> !rm tbs01.dbf
SQL> !mv tbs03.dbf tbs01.dbf
10. Insert more rows and executed "alter system checkpoint":
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> insert into objtab select * from dba_objects;
50417 rows created.
SQL> commit;
Commit complete.
SQL> alter system checkpoint;
System altered.
SQL> select count(*) from objtab;
COUNT(*)
907506
11. When I check the size of tbs01.dbf it is smaller then before despite of more rows I inserted. How come? Where are all this rows stored?
SQL> !du -hs tbs01.dbf
*86M tbs01.dbf*
12. Now try to offline tablespace and then I get errors in alertlog:
SQL> alter tablespace test_tbs offline normal;
alter tablespace test_tbs offline normal
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error
ALERT LOG
Errors in file /oracle/admin/um/udump/um_ora_501.trc:
ORA-00600: internal error code, arguments: [krhpfh_03-1208], [fno =], [6], [fecpc =], [4], [fhcpc =], [3], []
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-01122: database file 6 failed verification check
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-01208: data file is an old version - not accessing current version
Fri May 29 09:01:31 2009
ORA-600 signalled during: alter tablespace test_tbs offline normal...
Fri May 29 09:01:31 2009
Errors in file /oracle/admin/um/udump/um_ora_501.trc:
ORA-00600: internal error code, arguments: [krhpfh_03-1208], [fno =], [6], [fecpc =], [4], [fhcpc =], [3], []
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208], [fno =], [6], [fecpc =], [4], [fhcpc =], [3], []
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-01122: database file 6 failed verification check
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-01208: data file is an old version - not accessing current version
Fri May 29 09:01:37 2009
Errors in file /oracle/admin/um/udump/um_ora_501.trc:
ORA-00600: internal error code, arguments: [krhpfh_03-1208], [fno =], [6], [fecpc =], [4], [fhcpc =], [3], []
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208], [fno =], [6], [fecpc =], [4], [fhcpc =], [3], []
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208], [fno =], [6], [fecpc =], [4], [fhcpc =], [3], []
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-01122: database file 6 failed verification check
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-01208: data file is an old version - not accessing current version
Fri May 29 09:01:43 2009
Errors in file /oracle/admin/um/udump/um_ora_501.trc:
ORA-00600: internal error code, arguments: [krhpfh_03-1208], [fno =], [6], [fecpc =], [4], [fhcpc =], [3], []
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208], [fno =], [6], [fecpc =], [4], [fhcpc =], [3], []
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208], [fno =], [6], [fecpc =], [4], [fhcpc =], [3], []
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-01122: database file 6 failed verification check
ORA-01110: data file 6: '/oradata/tbs01.dbf'
ORA-01208: data file is an old version - not accessing current version
13. One more check:
SQL> select tablespace_name, status from dba_tablespaces;
TABLESPACE_NAME STATUS
SYSTEM ONLINE
SYSAUX ONLINE
USERS ONLINE
UNDOTBS2 ONLINE
TMP ONLINE
TEST_TBS ONLINE
7 rows selected.
SQL> select count(*) from objtab;
COUNT(*)
907506
14. Restart database:
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup;
ORACLE instance started.
Total System Global Area 1224736768 bytes
Fixed Size 1267188 bytes
Variable Size 1006635532 bytes
Database Buffers 201326592 bytes
Redo Buffers 15507456 bytes
Database mounted.
Database opened.
15. Try to count(*) from table but it says that object no longer exists:
SQL> select count(*) from objtab;
select count(*) from objtab
ERROR at line 1:
ORA-08103: object no longer exists
SQL> select tablespace_name, status from dba_tablespaces;
TABLESPACE_NAME STATUS
SYSTEM ONLINE
SYSAUX ONLINE
USERS ONLINE
UNDOTBS2 ONLINE
TMP ONLINE
TEST_TBS ONLINE
7 rows selected.
16. If object does not exist, how come I get this results (probably leftovers in data dictionary):
SQL> desc objtab;
Name Null? Type
OWNER VARCHAR2(30)
OBJECT_NAME VARCHAR2(128)
SUBOBJECT_NAME VARCHAR2(30)
OBJECT_ID NUMBER
DATA_OBJECT_ID NUMBER
OBJECT_TYPE VARCHAR2(19)
CREATED DATE
LAST_DDL_TIME DATE
TIMESTAMP VARCHAR2(19)
STATUS VARCHAR2(7)
TEMPORARY VARCHAR2(1)
GENERATED VARCHAR2(1)
SECONDARY VARCHAR2(1)
SQL> create table objtab tablespace test_tbs as select * from dba_objects;
create table objtab tablespace test_tbs as select * from dba_objects
ERROR at line 1:
ORA-00955: name is already used by an existing object
17. To drop object (can't drop):
SQL> drop table objtab;
drop table objtab
ERROR at line 1:
ORA-08103: object no longer exists
18. Clean up:
SQL> drop tablespace test_tbs including contents and datafiles;
Tablespace dropped.
Best Regards,
Marko

Answer 1

Hi Uwe,
as I said before my intention was to understand behavior of Oracle and Linux in scenario like this.
I thought about what will happen if some Linux admin by mistake moves live datafile to another location and after 5-10 mins, when he realizes his mistake, he moves the datafile to old (original) location.
Will Oracle notice some errors in alert log? (In my test case I didn't receive any message in alert log)
How will I know (as a DBA) what was done with this datafile if Linux admin does not say anything to me?
Is any damage made to datbase ? (Probably)
etc...
When I am on my test machine I like to do all kind of stuff and try anything that comes on my mind. It isn't important to me if this scenario has any connection to real world problems. I enjoy doing this so I like to spend some of my time on this test cases.
Anyway thanks for your comment.
Regards,
Marko
Edited by: msutic on May 29, 2009 1:03 PM