Vaak zullen de prestaties van de database traag zijn. We moeten eerst uitvinden of er een scan van een grote tafel aan de gang is.
Laten we eerst eens kijken wat Volledige tabelscan is en dan zullen we de vraag zien om volledige tabelscans te vinden in orakel
Wat is Full Table Scan
- Volledige tabelscan is een van de toegangsmethoden die door Optimizer worden gebruikt. Hierin worden alle blokken in de tabel (tot HWM) gescand en worden de filtervoorwaarden van de WHERE-clausule toegepast en worden rijen geretourneerd die aan de filtervoorwaarde voldeden. Leg uit dat het plan er zo uit zal zien
Execution Plan
TABLE ACCESS FULL OF HZ_PARTIES
- Volledige tabelscan heeft de tabel gescand met behulp van meerdere blokken gelezen. Meerdere blokken gescand voor elke IO -> er worden minder IO-bewerkingen uitgevoerd
- db_multiblock_read_count init.ora parameter bepaalt het aantal blokken. Recente versie, orakel zelf past deze parameter aan volgens het systeem en u hoeft het niet te definiëren
- Wat is HWM – High Water Mark:het is de limiet die de blokken scheidt die gegevens bevatten of bevatten van de blokken die er nooit in zijn ingevoegd. Het aantal blokken onder de HWM kan worden verkregen via de blokkenkolom van de weergave dba_tables
query om scans van volledige tabellen in orakel te vinden
col event format a25 col module format a50 col File format 9999 col Block format 9999999 set lines 130 set trimspool on select sessw.SID, sessw.EVENT, sessw.p1 "File",sessw.p2 "Block", s.MODULE from v$session_wait sessw, v$session sess where sessw.sid = sess.sid and sessw.event like '%scattered%' order by 1 /
De bovenstaande query rapporteert elke huidige volledige tabelscan die in de database wordt uitgevoerd. U kunt de tabelnaam vinden in de onderstaande query
select segment_name
from dba_extents
where file_id = &fileid
and &block between block_id and block_id + blocks - 1
;
Als u de geschiedenis van alle huidige sessies in de database wilt zien voor een volledige tabelscan, kunnen we de onderstaande query gebruiken
column user_process heading "Name |SID" format a20;
column long_scans heading "Long Scans" format 999,999,999;
column short_scans heading "Short Scans" format 999,999,999;
column rows_retreived heading "Rows Retrieved" format 999,999,999;
set linesize 1000
set timing on
select ss.username||'('||se.sid||') ' "USER_PROCESS",
sum(decode(name,'table scans (short tables)',value)) "SHORT_SCANS",
sum(decode(name,'table scans (long tables)', value)) "LONG_SCANS",
sum(decode(name,'table scan rows gotten',value)) "ROWS_RETRIEVED"
from v$session ss, v$sesstat se, v$statname sn
where se.statistic# = sn.statistic#
and (name like '%table scans (short tables)%'
or name like '%table scans (long tables)%'
or name like '%table scan rows gotten%' )
and se.sid = ss.sid
and ss.username is not null
group by ss.username||'('||se.sid||') '
order by LONG_SCANS desc
/
Als u alle sql in de cache in de bibliotheekcache wilt vinden voor de volledige tabelscanverklaring
select sql_id,object_owner,object_name from V$SQL_PLAN where
operation='TABLE ACCESS' and
options='FULL' and
object_owner <> 'SYS';
U kunt de volledige tekst van sql_id krijgen met behulp van de onderstaande zoekopdracht
SELECT sql_text, parsing_schema_name, module FROM v$sql WHERE sql_id = '&1'
Hoe een volledige tabelscan in Oracle te vermijden
Volledige tafelscan is geen noodzakelijk kwaad. Oracle Optimizer kiest het plan op basis van datapunt. Als het heeft gekozen voor volledige gegevensscan, dan heeft het het zeker goed gevonden. Ook is indexscan vaak niet goed voor de zoekopdracht en is het duurder dan een volledige tabelscan. We moeten dus grondig analyseren voordat we een beslissing nemen over Volledige tafelscan
Hier volgen enkele dingen die u moet controleren
(a) Stale Optimizer-statistieken:controleer of de beschikbare optimalisatiestatistieken in de tabellen actueel zijn en niet veel verschillen van de werkelijke gegevens
(b) Controleer indexen en index clusterfactor :u mist mogelijk de juiste indexen
(c) De query gebruikt mogelijk een parallelle clausule en kiest daarom Volledige tabelscan als optimaal plan
(d) Onjuiste parameterinstellingen voor Optimizer_mode,optimizer_index_cost_adj, optimizer_index_caching
Soms helpt het om sql tuning-adviseur op de query uit te voeren
Verwante artikelen
plan uitleggen in orakel:alles over plan uitleggen in Oracle, hoe orakel te lezen plan uitleggen voor prestatiegerelateerd probleem, hoe het plan uitleggen voor query in cursor te vinden
wat is logisch lees in orakel:wat is logisch lezen in orakel en fysieke I / O in Oracle, wat betere logische en fysieke I / O is in termen van prestaties, vragen om fysieke leesbewerkingen te vinden
sql-afstemmingsadviseur:SQL-afstemmingsadviseur voor sql_id uitvoeren in de cursor cache, hoe wordt de sql-afstemmingstaak gemaakt en uitgevoerd om de aanbeveling te krijgen
vind indexen op een tafel in oracle:bekijk dit artikel om vragen te vinden over het vinden van indexen op een tabel in oracle, lijst alle indexen op in schema ,indexstatus, indexkolom
bindvariabelen in oracle:Bindvariabele is de tijdelijke aanduiding voor waarden in sqlplus en PLSQL en wordt vervangen door waarden wanneer de instructie wordt uitgevoerd
hoe sql-profiel in oracle te controleren:controleren lees dit bericht over hoe je het sql-profiel in oracle kunt controleren, hoe je de inhoud van sql prof . kunt vinden ile, hoe het sql-profiel te verwijderen