Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
========================================================================
=========================
To Check Percentage Usage of Temp Tablespace:
--------------------------------------------select (s.tot_used_blocks/f.total_blocks)*100 as "percent used"
from (select sum(used_blocks) tot_used_blocks
from v$sort_segment where tablespace_name='TEMP') s,
(select sum(blocks) total_blocks
from dba_temp_files where tablespace_name='TEMP') f;
========================================================================
=========================
To find Sort Segment Usage by a particular User:
-----------------------------------------------SELECT s.username,s.sid,s.serial#,u.tablespace, u.contents, u.extents, u.blocks
FROM v$session s, v$sort_usage u
WHERE s.saddr=u.session_addr
order by u.blocks desc;
========================================================================
===========================
No comments:
2010 09
2010 10
2010 12
2011 02
2011 04
2011 05
2011 07
2011 08
2011 09
2011 10
2011 11
2011 12
2012 01
2012 02
2012 06
2012 08
160
4
38
59
52
16
78
40
9
78
57
8
110
134
6
14
Through OEM :
===========
Here are the steps to know Database growth pattern for last one month/year using
OEM
1) Login to OEM and Click on the Reports Tab
2) Navigate to Reports>Storage>Oracle Database Space Usage path and Click on
Oracle Database Space Usage link.
3) Select the Target database and here we are getting Oracle Database space usage
for last one Month.
4) Also we can get one year Database growth by setting Set Time Period Button.
5) Also we can find Oracle Database Tablespace Monthly Space Usage by Navigating
Reports>Storage>Oracle Database Space Usage path and click on Oracle
Database Tablespace Monthly Space Usage link.
1 comment:
AWR Reports
AWR FEATURES
Time model statistics indicating the amount of DB time associated with a process from
the V$SESS_TIME_MODEL and V$SYS_TIME_MODEL views.
Some system and session statistics from the V$SYSSTAT and V$SESSTAT views.
ENTERPRISE MANAGER
The automated workload repository administration tasks have been included in Enterprise Manager. The
"Automatic Workload Repository" page is accessed from the main page by clicking on the
"Administration" link, then the "Workload Repository" link under the "Workload" section. The page allows
you to modify AWR settings or manage snapshots without using the PL/SQL APIs.
No comments:
STATE
COUNT(*)
---------------------------------------------------------------------------------- ---------rdbms ipc message
WAITING
9
SQL*Net message from client
WAITING
8
log file sync
WAITING
6
gcs remote message
WAITING
2
PL/SQL lock timer
WAITING
2
PL/SQL lock timer
TIME
WAITED KNOWN
WAITING
1
smon timer
WAITING
1
log file parallel write
WAITING
1
ges remote message
1
WAITING
WAITED SHORT
WAITING
1
pmon timer
WAITING
1
db file sequential read
WAITING
1
Streams AQ: waiting for messages in the queue
WAITING
1
rdbms ipc message
TIME
WAITED KNOWN
WAITING
1
Streams AQ: qmn slave idle wait
WAITING
1
Streams AQ: waiting for time management or cleanup tasks
WAITING
1
19 rows selected.
It uses the Oracle wait interface to report what all database sessions are currently doing wait/CPU
usage wise. Whenever theres a systemic issue (like extremely slow log file writes) this query will
give good hint towards the cause of problem. Of course just running couple of queries against wait
interface doesnt give you the full picture (as these kinds of database wide healthchecks can be
misleading as we should be really measuring end user response time breakdown at session level
and asking questions like what throughput/response time do you normally get) but nevertheless, if
you want to see an instance sessions state overview, this is the simplest query I know.
Interpreting this query output should be combined with reading some OS performance tool output
(like vmstat or perfmon), in order to determine whether the problem is induced by CPU overload. For
example, if someone is running a parallel backup compression job on the server which is eating all
CPU time, some of these waits may be just a side-effect of CPU overload).
Below is a cosmetically enhanced version of this command, as one thing I decode the WAITED
FOR xyz TIME wait states to WORKING and On CPU / runqueue as event name as otherwise
its easy to miss by accident that some sessions are not actually waiting on previous event anymore:
SQL> select
2
count(*),
ELSE 'WAITING'
END AS state,
ELSE event
END AS sw_event
FROM
10
11
v$session_wait
GROUP BY
12
13
ELSE 'WAITING'
14
END,
15
16
ELSE event
17
END
18
ORDER BY
19
20
1 DESC, 2 DESC
/
COUNT(*) STATE
EVENT
SQL>
Also, sometimes you might want to exclude the background processes and idle sessions from the
picture:
SQL> select
2
count(*),
ELSE 'WAITING'
END AS state,
ELSE event
END AS sw_event
FROM
10
11
v$session
WHERE
12
type = 'USER'
13
14
GROUP BY
15
16
ELSE 'WAITING'
17
END,
18
19
ELSE event
20
END
21
ORDER BY
22
23
1 DESC, 2 DESC
/
COUNT(*) STATE
EVENT
By the way, the above scripts report quite similar data what ASH is actually using (especially the
instance performance graph which shows you the instance wait summary). ASH nicely puts the CPU
count of server into the graph as well (that you would be able to put the number of On CPU
sessions into perspective), so another useful command to run after this script is show parameter
cpu_count or better yet, check at OS level to be sure :)
Note that you can use similar technique for easily viewing the instance activity from other
perspectives/dimensions, like which SQL is being executed:
SQL> select sql_hash_value, count(*) from v$session
2
SQL_HASH_VALUE
COUNT(*)
-------------- ---------0
20
966758382
2346103937
3393152264
3349907142
2863564559
4030344732
1631089791
8 rows selected.
SQL> select sql_text,users_executing from v$sql where hash_value = 966758382;
SQL_TEXT
USERS_EXECUTING
10
On being prompted for the context file to be retrieved, select the option of retrieving
the
Applications tier context file that has been lost and retrieve it to the default location
specified
by the script.
The above command can be used only when INST_TOP the is still intact. In case that has
also been lost
accidentally, the Applications tier context file may be retrieved as follows:
Execute the following command on the Database tier: perl
/appsutil/clone/bin/adclonectx.pl retrieve
On being prompted for the context file to be retrieved, select the option of retrieving
the
On being prompted for the context file to be retrieved, select the Database tier
context file and
retrieve it to the default location specified by the script.
No comments:
GETS Ratio
---------- --------269 .00000
304 .00000
2820 .00000
629 .00000
511 .00196
513 .00000
503 .00199
301 .00000
299 .00000
Looking at the tcl script to see what sql gets performed to determine rollback
segment contention
select count from v$waitstat where class = 'system undo header';
select count from v$waitstat where class = 'system undo block';
select count from v$waitstat where class = 'undo header';
select count from v$waitstat where class = 'undo block';
v$parameter f,
(
SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
undo_block_per_sec
FROM v$undostat
)g
WHERE e.name = 'undo_retention'
AND f.name = 'db_block_size'
/
ACTUAL UNDO SIZE [MByte]
-----------------------200
UNDO RETENTION [Sec]
-------------------10800
OPTIMAL UNDO RETENTION [Sec]
---------------------------16401
Calculate Needed UNDO Size for given Database Activity
If you are not limited by disk space, then it would be better to choose the UNDO_RETENTION time that is
best for you (for FLASHBACK, etc.). Allocate the appropriate size to the UNDO tablespace according to
the database activity:
Again, all in one query:
SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
(TO_NUMBER(e.value) * TO_NUMBER(f.value) *
g.undo_block_per_sec) / (1024*1024)
"NEEDED UNDO SIZE [MByte]"
FROM (
SELECT SUM(a.bytes) undo_size
FROM v$datafile a,
v$tablespace b,
dba_tablespaces c
WHERE c.contents = 'UNDO'
AND c.status = 'ONLINE'
AND b.name = c.tablespace_name
AND a.ts# = b.ts#
) d,
v$parameter e,
v$parameter f,
(
SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
undo_block_per_sec
FROM v$undostat
)g
WHERE e.name = 'undo_retention'
AND f.name = 'db_block_size'
/