oracle 8.1.6 op solaris upgraden ivm performance?

[paulhekje]

situatie:
Sun Enterprise 450 met Solaris 7 1GB geheugen RAID-5 scsi disks.
ERP pakket draaiend op Oracle 8.1.6
max 40 gebruikers.

Er is al zoveel mogelijk getuned met init.ora en binnen het pakket zijn wat settings aangepast. Toch blijft het pakket veel te traag, ook met weinig gebruikers. De leverancier van het erp pakket die de implementatie doet, zegt nu dat de oplossing een upgrade is naar oracle 8.1.7 na al verschillende keren wat geprobeerd te hebben.

Ik heb zo m'n twijfels of het gaat helpen. Een upgrade is altijd riskant, daarom ben ik benieuwd naar ervaringen of deze actie wel zin heeft.

[morphje]

Persoonlijk zou ik eerst vragen aan de leverancier of ze wat tests kunnen tonen. Een upgraden is altijd vervelend, dus als ze kunnen aantonen dat het pakket aanzienlijk sneller is dan pas upgraden.

Ze raden het toch aan? Dan moeten ze het ook kunnen aantonen IMO.

Is dit het enige wat draait op die SUN? Of draait er nog meer geheugenconsumerend spul op die machine. Oracle vreet namelijk geheugen (bijna niet normaal meer)

edit: Ik zie ook dat je solaris 7 draait. Vraag eens na bij het bedrijf wat hun versie is. Misschien een idee om te upgraden naar versie 8 ? (gaat leuk worden met een flinke downtime ) Voor zover ik me kan herinneren zitten er toch aardig wat enhancements in versie8. Ik weet ook niet pcies wat je allemaal gedaan heb

[justmental]

Een upgrade naar 8.1.7 kan zeker helpen.

Ik weet niet of je pakket cost of rule based optimisation dient te gebruiken, maar als dat cost based optimisation is is het misschien handig om naar je statistieken analyse te kijken.

[paulhekje]

er draait verder niks anders op de sun. en als ik het geheugen gebruik bekijk is er niets te kort.
In init.ora zijn o.a. de shared pool en buffers vergroot.

Zo veel oracle kennis heb ik niet dus cost-based zegt me niks...

[justmental]

Op vrijdag 05 april 2002 13:03 schreef paulhekje het volgende:
er draait verder niks anders op de sun. en als ik het geheugen gebruik bekijk is er niets te kort. In init.ora zijn o.a. de shared pool en buffers vergroot.

Dat hoeft niet altijd te helpen.
Zomaar parameters aanpassen is zeker niet handig.

Als je buffer cache hit ratio te laag is dan kun je shared pool en db block buffers idd. vergroten, maar dan moet je dus wel eerst gezien hebben dat je hit ratio slecht is.

Performance tuning is trouwens de meest complexe bezigheid die je met Oracle kunt hebben, daar heb je dus eigenlijk een zeer zware professional voor nodig.

[Dromer]

Mja voor oracle laten wij ook altijd maar een echte expert komen.
Ik zou iig niet zomaar gaan upgraden.
Als het fout gaat heb je 40 boze gebruikers en daar zit je ook niet op te wachten denk ik.
Je zegt dat er geen geheugen tekort is maar met 40 gebruikers lijkt me 1gb vrij weinig ( hangt er een beetje vanaf wat je met de server doet uiteraard )

[paulhekje]

die 40 gebruikers zijn niet constant aan het werk, dat is het max. dat tegelijk ingelogd is.

[-=Arjan=-]

Alleen init.ora aanpassen is inderdaad Performance Tuning op 5Hart niveau (NOFI). Wat je zou kunnen doen is het draaien van utlbstat.sql en utlestat.sql. Deze geven een schat aan informatie, en ik denk dat je dan behulp van OTN, Metalink, en DBAsupport.com best wel een eind komt

[paulhekje]

ik heb utlbstat en utlestat gedraaid, maar om er iets uit te kunnen halen moet je iets meer weten van oracle dan ik. Kunnen jullie hier iets uit halen?<blockquote><font size="1" face="verdana, arial, helvetica">code:</font><hr><font face="courier, fixedsys, lucida console"><nobr>SVRMGR> 
SVRMGR> set charwidth 12
Charwidth                       12
SVRMGR> set numwidth 10
Numwidth                        10
SVRMGR> Rem Select Library cache statistics.  The pin hit rate should be high.
SVRMGR> select namespace library,
     2>        gets, 
     3>        round(decode(gethits,0,1,gethits)/decode(gets,0,1,gets),3) 
     4>           gethitratio,
     5>        pins, 
     6>        round(decode(pinhits,0,1,pinhits)/decode(pins,0,1,pins),3) 
     7>           pinhitratio,
     8>        reloads, invalidations
     9>   from stats$lib;
LIBRARY      GETS       GETHITRATI PINS       PINHITRATI RELOADS    INVALIDATI
------------ ---------- ---------- ---------- ---------- ---------- ----------
BODY                115       .983        115       .983          0          0
CLUSTER               0          1          0          1          0          0
INDEX                 0          1          0          1          0          0
OBJECT                0          1          0          1          0          0
PIPE                  0          1          0          1          0          0
SQL AREA            337       .955       2218       .974          0          0
TABLE/PROCED        761       .997       1354       .986          6          0
TRIGGER               0          1          0          1          0          0
8 rows selected.
SVRMGR> 
SVRMGR> set charwidth 27;
Charwidth                       27
SVRMGR> set numwidth 12;
Numwidth                        12
SVRMGR> Rem The total is the total value of the statistic between the time
SVRMGR> Rem bstat was run and the time estat was run.  Note that the estat
SVRMGR> Rem script logs on as "internal" so the per_logon statistics will
SVRMGR> Rem always be based on at least one logon.
SVRMGR> select 'Users connected at ',to_char(start_time, 'dd-mon-yy hh24:mi:ss'),':',start_users from stats$dates;
'USERSCONNECTEDAT'  TO_CHAR(START_TIME ' START_USERS 
------------------- ------------------ - ------------
Users connected at  10-apr-02 13:47:37 :           44
1 row selected.
SVRMGR> select 'Users connected at ',to_char(end_time, 'dd-mon-yy hh24:mi:ss'),':',end_users from stats$dates;
'USERSCONNECTEDAT'  TO_CHAR(END_TIME,' ' END_USERS   
------------------- ------------------ - ------------
Users connected at  10-apr-02 13:47:58 :           44
1 row selected.
SVRMGR> select 'avg # of connections: ',((start_users+end_users)/2) from stats$dates;
'AVG#OFCONNECTIONS:'   ((START_USER
---------------------- ------------
avg # of connections:            44
1 row selected.
SVRMGR> 
SVRMGR> select n1.name "Statistic", 
     2>        n1.change "Total", 
     3>        round(n1.change/trans.change,2) "Per Transaction",
     4>        round(n1.change/((start_users + end_users)/2),2)  "Per Logon",
     5>        round(n1.change/(to_number(to_char(end_time,   'J'))*60*60*24 -
     6>                         to_number(to_char(start_time, 'J'))*60*60*24 +
     7> to_number(to_char(end_time,   'SSSSS')) -
     8> to_number(to_char(start_time, 'SSSSS')))
     9>              , 2) "Per Second"
    10>    from 
    11> stats$stats n1, 
    12> stats$stats trans, 
    13> stats$dates
    14>    where 
    15>  trans.name='user commits'
    16>     and  n1.change != 0
    17>    order by n1.name;
Statistic                   Total        Per Transact Per Logon    Per Second  
--------------------------- ------------ ------------ ------------ ------------
CPU used by this session        11596961    724810.06     263567.3    552236.24
CPU used when call started           316        19.75         7.18        15.05
CR blocks created                     33         2.06          .75         1.57
DBWR checkpoint buffers wri            1          .06          .02          .05
DBWR transaction table writ            1          .06          .02          .05
SQL*Net roundtrips to/from           161        10.06         3.66         7.67
background timeouts                   24          1.5          .55         1.14
buffer is not pinned count          6236       389.75       141.73       296.95
buffer is pinned count               252        15.75         5.73           12
bytes received via SQL*Net         36196      2262.25       822.64      1723.62
bytes sent via SQL*Net to c        22395      1399.69       508.98      1066.43
calls to get snapshot scn:          1062        66.38        24.14        50.57
calls to kcmgas                       34         2.13          .77         1.62
calls to kcmgcs                        8           .5          .18          .38
change write time                      3          .19          .07          .14
cleanouts and rollbacks - c            1          .06          .02          .05
cleanouts only - consistent            2          .13          .05           .1
cluster key scan block gets          508        31.75        11.55        24.19
cluster key scans                     88          5.5            2         4.19
commit cleanout failures: b            2          .13          .05           .1
commit cleanouts                      89         5.56         2.02         4.24
commit cleanouts successful           87         5.44         1.98         4.14
consistent changes                    43         2.69          .98         2.05
consistent gets                     8010       500.63       182.05       381.43
cursor authentications                 9          .56           .2          .43
data blocks consistent read           35         2.19           .8         1.67
db block changes                     468        29.25        10.64        22.29
db block gets                        878        54.88        19.95        41.81
deferred (CURRENT) block cl           46         2.88         1.05         2.19
enqueue conversions                    7          .44          .16          .33
enqueue releases                     199        12.44         4.52         9.48
enqueue requests                     198        12.38          4.5         9.43
enqueue timeouts                       5          .31          .11          .24
execute count                       1025        64.06         23.3        48.81
free buffer inspected                  1          .06          .02          .05
free buffer requested               4138       258.63        94.05       197.05
immediate (CR) block cleano            3          .19          .07          .14
immediate (CURRENT) block c            5          .31          .11          .24
logons cumulative                     13          .81           .3          .62
messages received                     25         1.56          .57         1.19
messages sent                         25         1.56          .57         1.19
no work - consistent read g         6005       375.31       136.48       285.95
opened cursors cumulative            375        23.44         8.52        17.86
opened cursors current               105         6.56         2.39            5
parse count (hard)                    29         1.81          .66         1.38
parse count (total)                  464           29        10.55         22.1
parse time cpu                        28         1.75          .64         1.33
parse time elapsed                    54         3.38         1.23         2.57
physical reads                      4106       256.63        93.32       195.52
physical reads direct                 18         1.13          .41          .86
physical writes                       19         1.19          .43           .9
physical writes direct                18         1.13          .41          .86
physical writes non checkpo           18         1.13          .41          .86
prefetched blocks                   3825       239.06        86.93       182.14
recursive calls                     5288        330.5       120.18       251.81
recursive cpu usage                  129         8.06         2.93         6.14
redo blocks written                  215        13.44         4.89        10.24
redo entries                         254        15.88         5.77         12.1
redo size                          90776       5673.5      2063.09      4322.67
redo synch time                       14          .88          .32          .67
redo synch writes                     13          .81           .3          .62
redo wastage                        6752          422       153.45       321.52
redo write time                       25         1.56          .57         1.19
redo writes                           24          1.5          .55         1.14
rollbacks only - consistent           34         2.13          .77         1.62
rows fetched via callback            495        30.94        11.25        23.57
session logical reads               8888        555.5          202       423.24
session pga memory              75144412   4696525.75   1707827.55   3578305.33
session pga memory max          81300624      5081289   1847741.45   3871458.29
session uga memory                405368      25335.5      9212.91     19303.24
session uga memory max           1634128       102133     37139.27     77815.62
sorts (disk)                           2          .13          .05           .1
sorts (memory)                        48            3         1.09         2.29
sorts (rows)                        3108       194.25        70.64          148
switch current to new buffe            2          .13          .05           .1
table fetch by rowid                 836        52.25           19        39.81
table fetch continued row              3          .19          .07          .14
table scan blocks gotten            4187       261.69        95.16       199.38
table scan rows gotten            113631      7101.94      2582.52         5411
table scans (long tables)              2          .13          .05           .1
table scans (short tables)           108         6.75         2.45         5.14
total file opens                       1          .06          .02          .05
user calls                           145         9.06          3.3          6.9
user commits                          16            1          .36          .76
84 rows selected.
SVRMGR> 
SVRMGR> 
SVRMGR> set numwidth 27
Numwidth                        27
SVRMGR> Rem Average length of the dirty buffer write queue.  If this is larger 
SVRMGR> Rem than the value of:
SVRMGR> Rem  1. (db_files * db_file_simultaneous_writes)/2
SVRMGR> Rem  or
SVRMGR> Rem  2. 1/4 of db_block_buffers
SVRMGR> Rem which ever is smaller and also there is a platform specific limit
SVRMGR> Rem on the write batch size (normally 1024 or 2048 buffers). If the average 
SVRMGR> Rem length of the dirty buffer write queue is larger than the value 
SVRMGR> Rem calculated before, increase db_file_simultaneous_writes or db_files.
SVRMGR> Rem Also check for disks that are doing many more IOs than other disks.
SVRMGR> select queue.change/writes.change "Average Write Queue Length"
     2>   from stats$stats queue, stats$stats writes
     3>  where queue.name  = 'summed dirty queue length'
     4>   and  writes.name = 'write requests';
Average Write Queue Length 
---------------------------
0 rows selected.
SVRMGR> 
SVRMGR> 
SVRMGR> set charwidth 32;
Charwidth                       32
SVRMGR> set numwidth 13;
Numwidth                        13
SVRMGR> Rem System wide wait events for non-background processes (PMON, 
SVRMGR> Rem SMON, etc).  Times are in hundreths of seconds.  Each one of 
SVRMGR> Rem these is a context switch which costs CPU time.  By looking at
SVRMGR> Rem the Total Time you can often determine what is the bottleneck 
SVRMGR> Rem that processes are waiting for.  This shows the total time spent
SVRMGR> Rem waiting for a specific event and the average time per wait on 
SVRMGR> Rem that event.
SVRMGR> select n1.event "Event Name", 
     2>        n1.event_count "Count",
     3> n1.time_waited "Total Time",
     4> round(n1.time_waited/n1.event_count, 2) "Avg Time"
     5>    from stats$event n1
     6>    where n1.event_count > 0
     7>    order by n1.time_waited desc;
Event Name                       Count         Total Time    Avg Time     
-------------------------------- ------------- ------------- -------------
SQL*Net message from client                177         25307        142.98
rdbms ipc message                            6          4098           683
db file scattered read                     142           108           .76
db file sequential read                    138            80           .58
log file sync                               12            14          1.17
SQL*Net more data from client                2             9           4.5
control file sequential read            &a

[paulhekje]

en het 2e deel van report.txt (excuses is beetje groot)

code:

vecio buf des             11            0           1
8 rows selected.
SVRMGR> 
SVRMGR> Rem Buffer busy wait statistics.  If the value for 'buffer busy wait' in 
SVRMGR> Rem the wait event statistics is high, then this table will identify
SVRMGR> Rem which class of blocks is having high contention.  If there are high
SVRMGR> Rem 'undo header' waits then add more rollback segments.  If there are
SVRMGR> Rem high 'segment header' waits then adding freelists might help.  Check
SVRMGR> Rem v$session_wait to get the addresses of the actual blocks having
SVRMGR> Rem contention.
SVRMGR> select * from stats$waitstat 
     2>   where count != 0 
     3>   order by count desc;
CLASS         COUNT     TIME        
------------------ ---------------- ----------------
data block              2           0
1 row selected.
SVRMGR> 
SVRMGR> 
SVRMGR> set numwidth 19;
Numwidth                19
SVRMGR> Rem Waits_for_trans_tbl high implies you should add rollback segments.
SVRMGR> select * from stats$roll;
UNDO_SEGMENT      TRANS_TBL_GETS    TRANS_TBL_WAITS     UNDO_BYTES_WRITTEN  SEGMENT_SIZE_BYTES  XACTS          SHRINKS       WRAPS        
------------------- ------------------- ------------------- ------------------- ------------------- ------------------- ------------------- -------------------
            0            1           0           0       5005312             0           0           0
            2           19           0          2762         4169728             0           0           0
            3           20           0          3026         4169728             0           0           0
            4           55           0         14730         4169728             0           0           0
4 rows selected.
SVRMGR> 
SVRMGR> set charwidth 39
Charwidth                39
SVRMGR> Rem The init.ora parameters currently in effect:
SVRMGR> select name, value from v$parameter where isdefault = 'FALSE' 
     2>   order by name;
NAME                        VALUE                       
--------------------------------------- ---------------------------------------
compatible                  8.1.6.0.0                   
control_files                  /oracle/PROD/ctl1.ora, /oracle_log/PROD
db_block_buffers                4096                         
db_block_size                  8192                      
db_file_multiblock_read_count        32                      
db_files                      20                         
db_name                    PROD                      
distributed_transactions            10                       
dml_locks                    1200                        
global_names                    TRUE                         
job_queue_interval              10                       
job_queue_processes            2                          
log_buffer                  245760                     
log_checkpoint_interval          50000                      
log_checkpoint_timeout          900                     
log_checkpoints_to_alert            TRUE                         
max_dump_file_size              10240                       
max_enabled_roles                50                      
nls_date_format              DD-MON-YY                  
nls_language                    American                     
nls_territory                  America                    
open_cursors                    600                     
optimizer_mode                RULE                       
os_authent_prefix                                         
processes                    100                        
remote_login_passwordfile          EXCLUSIVE                    
rollback_segments                rb1, rb2, rb3                
shared_pool_size                348000000                   
utl_file_dir                    /oracle/PROD/interface           
29 rows selected.
SVRMGR> 
SVRMGR> set charwidth 15;
Charwidth                15
SVRMGR> set numwidth 8;
Numwidth                8
SVRMGR> Rem get_miss and scan_miss should be very low compared to the requests.
SVRMGR> Rem cur_usage is the number of entries in the cache that are being used.
SVRMGR> select * from stats$dc
     2>  where get_reqs != 0 or scan_reqs != 0 or mod_reqs != 0;
NAME        GET_REQS GET_MISS SCAN_REQ SCAN_MIS MOD_REQS COUNT    CUR_USAG
--------------- -------- -------- -------- -------- -------- -------- --------
dc_tablespaces    39      0   0   0   0  16  13
dc_free_extents  55  21  11   0  47 214 198
dc_segments      71   4   0   0  13 856 854
dc_used_extents  19  11   0   0  19  43  28
dc_users         399      0   0   0   0  59  58
dc_objects       648      4   0   0   0     2938     2929
dc_synonyms      91   0   0   0   0  18  15
dc_usernames       101    0   0   0   0  40  37
dc_object_ids      35     1   0   0   0 684 681
dc_sequences         1    0   0   0   1  46  35
dc_profiles      12   0   0   0   0   3   2
11 rows selected.
SVRMGR> 
SVRMGR> 
SVRMGR> set charwidth 80;
Charwidth                80
SVRMGR> set numwidth 10;
Numwidth                10
SVRMGR> Rem Sum IO operations over tablespaces.
SVRMGR> select
     2>   table_space||'                                 ' 
     3> table_space,
     4>   sum(phys_reads) reads,  sum(phys_blks_rd) blks_read,
     5>   sum(phys_rd_time) read_time,  sum(phys_writes) writes,
     6>   sum(phys_blks_wr) blks_wrt,  sum(phys_wrt_tim) write_time,
     7>   sum(megabytes_size) megabytes
     8>  from stats$files
     9>  group by table_space
    10>  order by table_space;
TABLE_SPACE                                            READS    BLKS_READ  READ_TIME  WRITES     BLKS_WRT   WRITE_TIME MEGABYTES 
------------------------------------------------------------------------------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
AC_DATA                                                     2       2       2       0       0       0     465
AC_INDEX                                                       2        2       2       0       0       0     596
ARCH_DATA                                                     1     1       0       0       0       0     105
ARCH_INDEX                                                   0      0       0       0       0       0     105
FND_DATA                                                      11       11      10       0       0       0     315
FND_INDEX                                                    11    11       5       0       0       0     156
FND_REPORT                                                   0      0       0       0       0       0     105
MAINT_DATA                                                   0      0       0       0       0       0     210
MAINT_INDEX                                                 0       0       0       0       0       0     167
MANUF_DATA                                                   160     3985     114       0       0       0    1182
MANUF_INDEX                                                 4       4       1       0       0       0     978
ROLLBACK                                                       0        0       0       1       1       0     157
SYSTEM                                                      82     90      46      18      18       0     993
TEMP                                                         0      0       0       0       0       0      52
TOOLS                                                       0       0       0       0       0       0      52
USERS                                                       0       0       0       0       0       0      52
16 rows selected.
SVRMGR> 
SVRMGR> 
SVRMGR> set charwidth 48;
Charwidth                48
SVRMGR> set numwidth 10;
Numwidth                10
SVRMGR> Rem I/O should be spread evenly accross drives. A big difference between
SVRMGR> Rem phys_reads and phys_blks_rd implies table scans are going on.
SVRMGR> select table_space, file_name,
     2>   phys_reads reads, phys_blks_rd blks_read, phys_rd_time read_time,
     3>   phys_writes writes, phys_blks_wr blks_wrt, phys_wrt_tim write_time, 
     4>   megabytes_size megabytes,
     5>   round(decode(phys_blks_rd,0,0,phys_rd_time/phys_blks_rd),2) avg_rt,
     6>   round(decode(phys_reads,0,0,phys_blks_rd/phys_reads),2) "blocks/rd"
     7>  from stats$files order by table_space, file_name;
TABLE_SPACE           FILE_NAME                         READS   BLKS_READ  READ_TIME  WRITES     BLKS_WRT   WRITE_TIME MEGABYTES  AVG_RT     blocks/rd 
------------------------------ ------------------------------------------------ ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
AC_DATA             /oracle/PROD/ac_data.dbf                        2       2       2       0       0       0     465       1       1
AC_INDEX                 /oracle/PROD/ac_index.dbf                     2        2       2       0       0       0     596       1       1
ARCH_DATA               /oracle_log/PROD/arch_data.dbf                  1       1       0       0       0       0     105       0       1
ARCH_INDEX             /oracle_log/PROD/arch_index.dbf                 0        0       0       0       0       0     105       0       0
FND_DATA                 /oracle/PROD/fnd_data.dbf                    11       11      10       0       0       0     315     .91       1
FND_INDEX               /oracle/PROD/fnd_index.dbf                   11    11       5       0       0       0     156     .45       1
FND_REPORT             /oracle/PROD/fnd_report.dbf                   0      0       0       0       0       0     105       0       0
MAINT_DATA             /oracle/PROD/maint_data.dbf                   0      0       0       0       0       0     210       0       0
MAINT_INDEX           /oracle/PROD/maint_index.dbf                  0       0       0       0       0       0     167       0       0
MANUF_DATA             /oracle/PROD/manuf_data.dbf                   160     3985     114       0       0       0    1182     .03   24.91
MANUF_INDEX           /oracle/PROD/manuf_index.dbf                  4       4       1       0       0       0     978     .25       1
ROLLBACK                 /oracle/PROD/rollback.dbf                     0        0       0       1       1       0     157       0       0
SYSTEM               /oracle/PROD/system.ora                        82     90      46      18      18       0     993     .51     1.1
TEMP                   /oracle/PROD/temp.dbf                         0      0       0       0       0       0      52       0       0
TOOLS                 /oracle/PROD/tools.dbf                        0       0       0       0       0       0      52       0       0
USERS                 /oracle/PROD/users.dbf                        0       0       0       0       0       0      52       0       0
16 rows selected.
SVRMGR> 
SVRMGR> 
SVRMGR> set charwidth 25
Charwidth                25
SVRMGR> Rem The times that bstat and estat were run.
SVRMGR> select to_char(start_time, 'dd-mon-yy hh24:mi:ss') start_time,
     2>   to_char(end_time,   'dd-mon-yy hh24:mi:ss') end_time
     3>   from stats$dates;
START_TIME     END_TIME     
------------------ ------------------
10-apr-02 13:47:37 10-apr-02 13:47:58
1 row selected.
SVRMGR> 
SVRMGR> set charwidth 75
Charwidth                75
SVRMGR> Rem Versions
SVRMGR> select * from v$version;
BANNER                                      
----------------------------------------------------------------
Oracle8i Release 8.1.6.3.0 - Production              
PL/SQL Release 8.1.6.3.0 - Production                  
CORE    8.1.6.0.0   Production                         
TNS for Solaris: Version 8.1.6.3.0 - Production          
NLSRTL Version 3.4.0.0.0 - Production                  
5 rows selected.
SVRMGR> 
SVRMGR> 
SVRMGR> spool off;

[-=Arjan=-]

Als je zelf alle remmetjes leest tussen de resultaat tabellen valt je al eea op denk ik.

Ik kan niet aan een remote tuning sessie gaan beginnen, dan zal ik de meter moeten gaan starten

[paulhekje]

daar heb je gelijk in. eerst zelf onderzoeken.

Waar het mij omgaat is te weten of onze erp-leverancier aan het prutsen is ja of nee.
De directeur heeft al een keer bij oracle een performance audit aangevraagd, maar helaas weer afgezegd omdat de erp-leverancier met een nieuw "oplossing" kwam: de upgrade.

[-=Arjan=-]

Tja...je kan twee dingen doen :

Vraag aan de leverancier referenties waar een upgrade performance winst heeft gebracht. Bel met de systeembeheerder van zo'n bedrijf en vraag naar zijn ervaring.

Of creeer een tweede ORACLE_HOME op je server, installeer daar 8.1.7 met een demo database en doe een import van je productie ERP database. Laat daar de users eens voor proef op aanloggen en kijk zelf of het beter gaat. Zo ja, upgraden, zo niet, wegwezen met die upgrade smoes.

Ik kan me gewoon niet voorstellen dat het omhoog gaan van 1 patchlevel zoveel performance winst geeft. Of het moet zo zijn dat ze bepaalde stored procedures aanspreken die verbeterd zijn in 8.1.7

Ps: De grootste performance winsten heb ik altijd nog behaald met het creeren van extra indexen

[mkleinman]

Ik ben zelf Oracle ontwikkelaar (2,5 jaar) en imho zit er qua architectuur niet zo conceptueel verschil tussen 8.1.6 en 8.1.7. je kan op metalink kijken voor de bugfixes tov beide versies.

net even bij een collega nagevraagd, het zijn voornamelijk extra functies en packages en wat bugfixes.

maw. upgraden naar 8.1.7 zal het probleem hoogstwaarschijnlijk niet oplossen.

met 40 gebruikers 1 pakket zitten op een db met 1gb geheugen, etc.. MOET goed draaien.

ik denk dat dit een klus is voor een dba'er om hier eens goed naar te kijken.

* mkleinman is geen dba maar op mijn werk zitten er wel een paar.

mocht je meer willen weten mail me dan ff op [e-mail]

[leonardo1504]

Een upgrade van 8.1.6 naar 8.1.7 is niet het eerste waar ik aan zou denken bij performance tuning. Als je 8.0.5 zou draaien zou het het overwegen waard zijn, maar dan nog moet je daarna eens flink aan de bak met de Oracle-parameters. Een aantal dingen kan je zowiezo proberen zonder al te veel moeite :

1. tabellen (en indexen) raken na een tijdje gefragmenteerd. Die fragmentatie krijg je er uit door een keer een export en een import te doen.
2. de query optimizer gaat uit van statistics, die moeten dan ook af en toe vernieuwd worden. Draai "ANALYZE TABLE {tablename} estimate STATISTICS" of "ANALYZE TABLE {tablename} compute STATISTICS" op tabellen waar je een probleem vermoedt.
3. REBUILD je indexen een keer
4. TOAD (Tool for Oracle Application Developers) op http://www.quest.com/toad/ , is een handige tool. Als je SYS bent kan je een heleboel dingen bekijken, onder andere Server Statistics. SGA trace en View Session kunnen je helpen om bottlenecks op te sporen. Server Stats geeft ook een hint wat je kan doen.
5. gebruik metalink (ff aanmelden) en technet.oracle.com

Suc6 !

edit:

typootje

[justmental]

Op woensdag 10 april 2002 15:25 schreef mkleinman64 het volgende:
Ik ben zelf Oracle ontwikkelaar (2,5 jaar) en imho zit er qua architectuur niet zo conceptueel verschil tussen 8.1.6 en 8.1.7. je kan op metalink kijken voor de bugfixes tov beide versies.

Met 8.1.7 is de optimizer behoorlijk verbeterd, dus ik denk dat het een poging waard is.

Wat me in die logs opvalt is dat je 4000 physical reads hebt op 8000 consistent gets, dat is wel heel veel.
Dat geeft aan dat er met db block buffers nog wel wat te halen kan zijn.

Het kan natuurlijk nog steeds zo zijn dat er gewoon beroerde query's in dat pakket gedraaid worden.
Kijk anders eens in v$sqlarea en sorteer aflopend op buffer_gets of disk_reads. Dan krijg je de meest belastende query's van de afgelopen tijd.

[paulhekje]

ik denk dat er gewoon beroerde queries gedraaid worden, want ook bij weinig belasting (<10 gebruikers) is de performance van een aantal veel gebruikte queries beroerd.

ik ga er nog een keer bij m'n chef op aandringen om oracle een performance audit te laten doen, ondertussen probeer ik wat met de tips te doen.

samengevat: er is dus wel een kans dat de upgrade helpt, hoeveel is niet te zeggen zonder specifieke kennis van deze database. maar de verwachting is weinig tot niks.

[Verwijderd]

Op woensdag 10 april 2002 23:49 schreef justmental het volgende:

[..]

Met 8.1.7 is de optimizer behoorlijk verbeterd, dus ik denk dat het een poging waard is.

Wat me in die logs opvalt is dat je 4000 physical reads hebt op 8000 consistent gets, dat is wel heel veel.
Dat geeft aan dat er met db block buffers nog wel wat te halen kan zijn.

Het kan natuurlijk nog steeds zo zijn dat er gewoon beroerde query's in dat pakket gedraaid worden.

Ik sluit me hier bij aan... de cijfers zijn op zich goed (de percentages van hits en misses) maar toch is de performance slecht. Dit duidt meestal op zeer slecht geschreven queries, queries die bvb. altijd volledige tabellen lezen zonder "where" clause, sorteringen op de client doen (gebruikt het pakket ODBC om naar Oracle te connecten?). Ik vrees dat noch een upgrade naar 8.1.7 noch tuning hieraan veel veranderd. De enige reden om te upgraden is dat 8.1.7 de laatste nog door Oracle actief ondersteunde 8i release is.
De fabrikant van het pakket moet dringend eens de hand in eigen boezem steken.

[Ooyevaar]

Ik heb hier ook een 450 met 640Mb voor 20 gebruikers. Ik draai echter nog 7.3.4 met BaaN-4c4.

Dit is echter ook enorm traag. Sommige financiele rapporten duren 3 kwartier We hebben ooit een test gedaan om te controleren of de database het probleem was. Dit hield in dat we in BaaN een query hebben geschreven die dezelfde gegevens gaf als dat 3 kwartier rapport ... duur nog maar 2 kwartier. Ten slotte dit als gewoon sql-statement met sqlplus opgestart .... 20 minuten. BaaN is het probleem.

Draai je toevallig ook met BaaN ?

[DigiK-oz]

Op donderdag 11 april 2002 07:28 schreef paulhekje het volgende:

samengevat: er is dus wel een kans dat de upgrade helpt, hoeveel is niet te zeggen zonder specifieke kennis van deze database. maar de verwachting is weinig tot niks.

Goed samengevat. Performance van een Oracle-database ligt maar zelden aan het Oracle-release. In mijn ervaring de meest voorkomende problemen (in volgorde) :

1) Brakke queries of db-design, waardoor indexen niet (of de verkeerde) worden gebruikt.

2) Ontbreken van juiste index(en), of juist het bestaan van indexen zonder enig nut (dit laatste met name bij rule-based optimizer)

3) Rule-based versus cost-based optimizer, of ontbreken van statistics.

4) Overbelasting hardware (met name memory en disk i/o)

En dan pas releases van Oracle of OS.

[paulhekje]

extra info:
Het ERP pakket is IFS application 2001.
De clients hebben naast een oracle client installatie een door IFS gecompileerde client waarin de menu's en queries zijn gedefinieerd.
Het OS van de clients is windows 98/2000 en win2k terminal server.

Dat hele tabellen continu doorlopen kom ik ook op andere plekken tegen. er zijn een paar maatwerk stukjes tbv interfacing. die lopen ook regel voor regel alles opnieuw door...

[-=Arjan=-]

Op donderdag 11 april 2002 08:01 schreef paulhekje het volgende:
extra info:
Het ERP pakket is IFS application 2001.
De clients hebben naast een oracle client installatie een door IFS gecompileerde client waarin de menu's en queries zijn gedefinieerd.
Het OS van de clients is windows 98/2000 en win2k terminal server.

Dat hele tabellen continu doorlopen kom ik ook op andere plekken tegen. er zijn een paar maatwerk stukjes tbv interfacing. die lopen ook regel voor regel alles opnieuw door...

Je weet zeker dat je terminal server niet de bottleneck is ?

[paulhekje]

zeker weten dat het niet aan de terminal server ligt. m'n collega die meer inhoudelijk met het pakket bezig is (en de benchmarks meet), werkt altijd vanaf z'n laptop en niet vanaf de terminal server.

We hebben besloten om toch de upgrade te doen, omdat:
- er anders bij de leverancier geen serieuze figuren naar willen kijken
- de versie beter door oracle wordt ondersteund

Over ca. 2 weken weten we meer.

[-=Arjan=-]

Hou ons op de hoogte

[paulhekje]

De upgrade van oracle is uitgevoerd, zoals verwacht geen performance verbetering

Het balletje ligt nu weer bij de leverancier die kritisch naar de gebruikte queries gaat kijken...