vncserver

1. start a vncserver session
vncserver
2. kill a vncserver session
vncserver -kill :1 (display number)

reclaim disk space from oracle tablespace;

select 'alter database datafile ' || a.file_id || ' resize ' || round((a.bytes - b.free_space + 1024*1024)/1024/1024)|| 'm ;'
from dba_data_files a,
(select sum(bytes) free_space , file_id from dba_free_space group by file_id) b
where a.file_id = b.file_id
;

----------
----------

set verify off
column file_name format a50 word_wrapped
column smallest format 999,990 heading "Smallest|Size|Poss."
column currsize format 999,990 heading "Current|Size"
column savings format 999,990 heading "Poss.|Savings"
break on report
compute sum of savings on report

column value new_val blksize
select value from v$parameter where name = 'db_block_size'
/

select file_name,
ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) smallest,
ceil( blocks*&&blksize/1024/1024) currsize,
ceil( blocks*&&blksize/1024/1024) -
ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) savings
from dba_data_files a,
( select file_id, max(block_id+blocks-1) hwm
from dba_extents
group by file_id ) b
where a.file_id = b.file_id(+)
/

column cmd format a75 word_wrapped

select 'alter database datafile '''||file_name||''' resize ' ||
ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) || 'm;' cmd
from dba_data_files a,
( select file_id, max(block_id+blocks-1) hwm
from dba_extents
group by file_id ) b
where a.file_id = b.file_id(+)
and ceil( blocks*&&blksize/1024/1024) -
ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) > 0
/


references:
http://dbaforums.org/oracle/index.php?showtopic=4444
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:54178027703899
http://asktom.oracle.com/pls/asktom/f?p=100:11:3259860865329305::::P11_QUESTION_ID:153612348067

Enterprise manager 11g (database control or grid control)

Check dbconsole web
emctl status dbconsole

https://192.168.1.1:1158/em

bin/rm: Argument list too long.

find . -name "*.aud" | xargs rm

Why is V$SESSION.SQL_ID null for an ACTIVE session

we may get sql_in from v$active_session_history(the top_level_sql column in V$ACTIVE_SESSION_HISTORY reports the sql_id )


reference:
https://forums.oracle.com/forums/thread.jspa?threadID=2244920

massive deletion solution

massive DELETE operation deletes millions of rows from a table with indexes and constraints. This operation is database intensive and time consuming, mainly because it forces the database to generate and save to disk significant amounts (possibly gigabytes) of redo and undo data.
You can perform massive DELETEs as bulk INSERT operations: instead of removing data you no longer need, you insert data you want to keep. The key to this option is performing it efficiently with minimum logging by using direct-path INSERT. Part 1 of this article series compares direct-path INSERT and regular INSERT. It also describes the technique of performing DELETEs as INSERTs. Part 2 will discuss the packaged APIs that implement the bulk INSERT technique.

Problem
How do I complete a massive DELETE operation in my Oracle database without having to pay the heavy performance overhead?

Solution.
Perform the massive DELETE operation as a direct-path (direct-load) INSERT (INSERT with APPEND hint) into a table whose logging parameter is set to NOLOGGING. This operation will complete significantly faster than DELETE and with minimum logging, but you have to take a backup afterwards to establish a new baseline.

Why INSERT Could Be Faster Than DELETE (or UPDATE)
Direct-path INSERT is a special database operation. Like SQL*Loader, it writes data directly to the database files, bypassing the buffer cache. It does this with minimum logging, recording only data dictionary changes. The logic behind this method is that because the data files are already up-to-date when an instance failure occurs, logging isn't necessary.

The two distinct cases in which direct-path INSERT is important are when:

1.The database is in noarchivelog mode. Media recovery is not possible, and you don't need redo data for that either.
2.The database is in archivelog mode. It logs redo blocks for media recovery by default. However, if you explicitly set a table to NOLOGGING mode, the database won't log redo blocks.
Therefore, with the direct-path INSERT when the database is in noarchivelog mode or when it is in archivelog mode and the table is in NOLOGGING mode, it performs only minimum redo logging—to protect the data dictionary.


reference:
http://www.devx.com/dbzone/10MinuteSolution/22191

last_call_et in v$session

this column give the running time of active session in seconds or waiting time of inactive session.

last call et is time in seconds that the backgrounds have been work -- roughly the same..