Delete AUD$ table do not free space

Question

Hi,
We have an Oracle 10g database (10.2.0.4) with the Oracle auditing feature on.
Our problem is that I delete on regular basis the AUD$ rows, but the system do not free the space on the tablespace. The system free the space only after a truncate.
The actual situation is:
SQL> select segment_name,bytes/1024/1024 as Mb from dba_segments where bytes/1024/1024 > 1000 and TABLESPACE_NAME='SYSTEM';
SEGMENT_NAME                                                                              MB
AUD$                                                                                             10161
SQL> select count(*) from sys.aud$;
COUNT(*)
+1073+
Someone can help me with this!?
The delete of the table is done with a simple script:
select count(*) from sys.aud$;
delete from sys.aud$ where NTIMESTAMP# < sysdate -(1/24*6);
select count(*) from sys.aud$;
commit;
exit;
Thanks
Nunzio

Answer 1

Nunzio Cafarelli wrote:
EdStevens wrote:
Nunzio Cafarelli wrote:
Hi,
thanks for your answer.
The scrink and the coalesce feature do not works:
SQL> alter table SYS.AUD$ enable row movement;
alter table SYS.AUD$ shrink space;
alter table SYS.AUD$ coalesce;
Table altered.
SQL> SQL> alter table SYS.AUD$ shrink space
ERROR at line 1:
ORA-10635: Invalid segment or tablespace type
SQL> SQL> alter table SYS.AUD$ coalesce
ERROR at line 1:
ORA-01735: invalid ALTER TABLE optionthe only way I have is to move the table in a different tablespace and in case move back.
Do you know if that is a know bug!?No it is not a bug.
Why are you concerned about the space being released? If it were you'd just have to re-aquire it as new rows are added to the table.
As rows are added, when an extent is filled a new extent is allocated. If rows are deleted those extents remain allocated to the table and are re-used as needed. The aud$ table is a perfect example of a table which most definately will need to reuse that space, so it it a total waste of effor to try to reclaim it.Hi, that is the real point, it seems that the table don't use the allocated space.
It constantly grows and reclaim new space. That is the real problem for me.You haven't demonstrated that. You only showed us a one-time snapshot of the space used and the row count.
You need to track this over several days / iterations of deleting rows. Show us that over a period of time the row count is fairly stable and yet the space used continues to increase.
If, today the rowcount is 'x' and the space allocated (measured in blocks or extents) is 'y', and you delete a bunch (or even all) rows, space allocated should remain 'y'. Then tomorrow, you should have near 'x' rows again (assuming a fairly level amount of audited activity). And space allocated should still be 'y' .. maybe allowing for a slight increase in 'x' triggering one more extent. But if you are regularly pruning the row count, the number of extents should stabilize. If not, then you do have an issue, but I haven't yet seen proof of that happening.
>
>>
Can this create problems since AUD$ is a system table!?No, but you don't want a very active table like that in your SYSTEM tablespace. Oracle puts it there by default, but there have been well known procedures on the net for YEARS on how to move it to another TS. Thanks
With 11g, they've even introduced the dbms_audit_management package to help with these tasks.I know, I hope the my customer will authorize the upgrade soon.
Thanks for your suggestion to upgrade sybrand_b, but as you can understand, sometime the upgrade are not possible until the software vendor will authorize that, so, we need to work on version 10.2.0.4 for some other months.
Regards
Nunzio
P.S. I think that there are problems, after the move of the table to a different tablespace, and the move back to SYSTEM, the used space was around 2Gb, but I was not able to resize the datafile. Don't move it back. Get it out of SYSTEM and leave it there.I think that I'll do this, at least to not risk the corruption of the system tablespace.
Thanks again for your answers.
regards
Nunzio