Rollback segmenter

Hvilken version af Oracle kører du ? I 9i slipper du for at lege med rollback (næsten ihvertfald)... Her afsætter du blot plads i et tablespace til alt de undo/redo. Så sørger databasen for at håndtere det.

I versioner <9i er det med at sørge for at rollbackerne er store nok. Lav f.eks. 5 store på 500mb. Efter et par dage kan du checke om de er store nok med denne forespørgsel:

VARIABLE sqlstat          VARCHAR2(600);

declare
n1 number;
begin
select count(*) into n1 from v$version
  where banner like 'Oracle7%';
if n1>0 then
  :sqlstat := 'select substr(n.name,1,20) "rollname", ' ||
  'round(24*(sysdate-to_date(i1.value||'' ''||i2.value,''j SSSSS'')) ' ||
  '/(s.writes/s.rssize),1) "rolltime" ' ||
  'from v$instance i1, v$instance i2, v$rollname n, v$rollstat s ' ||
  'where i1.key = ''STARTUP TIME - JULIAN'' '||
  'and i2.key = ''STARTUP TIME - SECONDS'' '||
  'and n.usn = s.usn and s.status = ''ONLINE'' ';
else
  :sqlstat := 'select substr(n.name,1,20) rollname,' ||
      'round(24*(sysdate-i.startup_time)/(s.writes/s.rssize),1) rolltime '||
      'from v$instance i, v$rollname n, v$rollstat s '||
      'where i.instance_number = 1 '||
      'and n.usn = s.usn and s.status = ''ONLINE''';
  end if;
end;
/


set serveroutput on size 40000
declare
  rollname varchar2(32);
  rolltime varchar2(32);
  cursor_handle    INTEGER;
  rows_processed    INTEGER;
begin
  cursor_handle := dbms_sql.open_cursor;
  dbms_sql.parse(cursor_handle,:sqlstat,dbms_sql.v7);
  rows_processed := dbms_sql.execute(cursor_handle);
  dbms_sql.define_column(cursor_handle,1,rollname,32);
  dbms_sql.define_column(cursor_handle,2,rolltime,32);

  rows_processed := dbms_sql.fetch_rows(cursor_handle);
  while rows_processed = 1 loop
    dbms_sql.column_value (cursor_handle, 1, rollname);
    dbms_sql.column_value (cursor_handle, 2, rolltime);
    dbms_output.put_line(rpad(rollname,21,' ')|| lpad(rolltime,17,' '));
    rows_processed := dbms_sql.fetch_rows(cursor_handle);
  end loop;
end;
/

set serveroutput off


Bare sørg for at de er over 24 ...

Jeg kører med en 8.1.4.1
Jeg har kørt den forespørgsel før, og der er jeg kommet frem til, at de skal være større alle sammen. De ligger på ca. 2-3 i værdi.
Det er som om, at de ikke vil udvidde ud over 10-15 extents.

det skulle selvfølgelig være 8.1.7.4.1 i versionen :-)

Lav fem på f.eks. 500MB og stop med at bruge OPTIMAL!

Så er du ihvertfald på rette vej....

OK - nu har jeg oprettet 17 af 125 MB, så må jeg se om nogle dage, om det har gjort udslaget, ellers opretter jeg 5 af 500 MB.
Er der nogen fordel i, at have en masse små rollback segmenter istedet for f.eks. 5 store??
Takker for svaret.

Få store segmenter er bedre end mange små, da en transaktion kun kan ligge i et segment. Til gengæld vil mange samtidige transaktioner ha' bedre af mange (små) segmenter.

Man kan med fordel ha' nogle få store segmenter - og derefter sende de store transaktioner til de store segmenter.

Generelt siges det, at optimal kun er for databaser, som ikke har plads nok - også kaldet "fedterøve" :-) Diskplads er ikke dyrt i dag, så derfor bør man ikke bruge optimal :-)

Og som du kan se af ovenstående indlæg - så kommer det an på brugen af databasen, om det bedst kan betale sig med mange små eller få store rollback segmenter.

Ofte er "snapshot too old" fejlen et problem med sql-koden, som kan optimeres - og dermed vinde en masse. F.eks. er den "select i select i select" ikke optimal, hvis man kan joine sig ud af det.