You must re-define the tablespace to change the extent management:
- Backup the tablespace
- Export the tablespace data
- Drop and re-allocate the tablespace
- Import the tablespace
SYSTEM
tablespace is too busyDBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION
PL/SQL procedure to specify the name of the destination tablespace and move it to that tablespace.
BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, AUDIT_TRAIL_LOCATION_VALUE => 'AUD_AUX'); END;
PROMPT How Far Back Can We Flashback To (Time)? PROMPT select to_char(oldest_flashback_time,'dd-mon-yyyy hh24:mi:ss') "Oldest Flashback Time" from v$flashback_database_log; PROMPT PROMPT How Far Back Can We Flashback To (SCN)? PROMPT col oldest_flashback_scn format 99999999999999999999999999 select oldest_flashback_scn from v$flashback_database_log; PROMPT PROMPT Flashback Area Usage SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE; PROMPT col ROUND(SPACE_LIMIT/1048576) heading "Space Allocated (MB)" format 999999 col round(space_used/1048576) heading "Space Used (MB)" format 99999 col name Heading "Flashback Location" format a40 select name, round(space_limit/1048576),round(space_used/1048576) from v$RECOVERY_FILE_DEST;
Log file sync is a client wait event. It is the wait event your clients wait on when they say "commit". It is the wait for LGWR to actually write their redo to disk and return back to them. You can "tune" this by making lgwr faster (no raid 5 for example) and committing less frequently and generating less redo (BULK operations generate less redo than row by row do) The other one is a background wait. LGWR is waiting for forgrounds to finish a current copy affecting the data LGWR is about to process. HOWEVER, that said, tuning either of these will have no noticable affect on your systems performance whatsoever! It certainly looks like "enqueue" is your wait and that is all about application design - those are heavyweight locks induced by the application logic itself. You would be best served by looking at the *application* not at the "system" at this point.
More infos here
Best Practice
|
Reasoning
|
Make the SYSTEM tablespace locally managed | Doing this enforces that all tablespaces created in this database are locally managed |
Use the REUSE clause with caution. Normally, you should
use it only when you’re re-creating a
database |
The REUSE clause instructs Oracle to overwrite
existing files, regardless of whether they’re in use. This is dangerous |
Create a default temporary tablespace with TEMP somewhere in the name | Every user should be assigned a temporary
tablespace of type TEMP, including the SYS user. If you don’t specify a default temporary tablespace, the SYSTEM tablespace is used. You never want a user to be assigned a temporary tablespace of SYSTEM. If your database doesn’t have a default temporary tablespace, use the ALTER DATABASE DEFAULT TEMPORARY TABLESPACE statement to assign one |
Create a default permanent tablespace named
USERS |
This ensures that users are assigned a default
permanent tablespace other than SYSTEM. If your database doesn’t have a default permanent tablespace, use the ALTER DATABASE DEFAULT TABLESPACE statement to assign one |
Use the USER SYS and USER SYSTEM clauses to specify nondefault passwords | Doing this creates the database with nondefault
passwords for database accounts that are usually the first targets for hackers |
Create at least three redo log groups with two
members each |
At least three redo log groups provides time for the
archive process to write out archive redo logs between switches. Two members mirror the online redo log members, providing some fault tolerance |
Name the redo logs something like redoNA.rdo | This deviates slightly from the OFA standard, but it's better to avoid to name it with the extension of .log because you can accidentally delete it |