Manuel,
Yes if you turn off archive log mode. You will only be able to restore your database - if a failure occured - to the time of your last backup. Any activity between the time of the last backup and when the failure occured, will be lost. So if you backed up your system on Saturday, and lost a disk on Tuesday. You will only be to recover the database to Saturday - any activity on Sun & Mon will be lost.
Looking at the report, I can see that you have the default optimiser setting of choose. This means that if you have statistics - can be seen in all/dba/user_tables, _indexes, _ histograms etc, then Oracle will use the cost based optimiser and decide on whether to use an index based on those stats. If those stats were collected when the system contained a little amount of data, then Oracle will tend to go for scan - more data then an index retrieval. (There also a load of other rules, but suffice to say, the more acurate your stats, the more infmored Oracle will be about which method to retrieve your data.
Loking at the stats and doing a quick analysis - I would suggest the following : (NB. this is a quick once through, its worth checking the stats against Oracle performance docs, also I may have mis interpretted things.)
1. LIbrary Cache Stats. The pin hit ratio should be as near 1 as possible. The Body and Index stats are quite low. The body stats suggest that should increase the size of your Shared Pool, maybe. Alternatively, you could pin common code into the Shared Pool. You could use the Shared Pool reserve parms to allocate space to specific, commonly called code? The index stats indicate that perhaps your buffer cache is too small, however, if you are scanning multiple tables, then index blocks will be dumped out.
2. The second load of stats contains a heap of info. I do not have time look at it all, but here a few things which seem 'interesting'
a. There seems to be a lot of check pointing - this can be confirmed in the alert.log file. Looking at the init.ora parms given, I notice that you have the default for the db_block size - this could be crucial. I would expect this to be around 8k in size, but I do not know the default value. If this is a low value, then your database blocks are too small. This is a big problem, as this parameter can be set at the 'create database' stage.
b. You are performing a large number of consistent gets - 2700 per second !. This is where the data is read from the rollback segment rather than the table, and takes therefore extra time. This again could be becuase of all the tablescans.
c. physical reads/writes. These show that you do not actually write much. But you read a hell of a lot.
d. table fetch continued row - this indicates the amount of data that is spread of more than one data block - requiring an additional read. Maybe issues with the storage parms on your tables?
Looking at the buffer busy waits - it seems that the database spends most its time waiting for data blocks and rollback. Again, this could tie in with a small buffer cache, or one that it being cleared quite quickly. If your buffer cache is quite small, and you cannot affored the memory, you could try splitting it in two (using the buffer pool keep/recycle parms - not sure if this is in your version.) This way any tables which you have to scan can be placed in the recycle area, and will not affect the performance of the buffer cache.
There are probably a number of things that I have missed (as I only have limited time), so again I would recommend looking at the Oracle Ref. Doc for guidance on the stats.
Hope this helps, I am not sure how awake I am this morning. It might help if you sent your init.ora settings. (In svrmgrl spool myfile; show parameter; spool off - this should produce a neat file.)
Good luck
If at first you do not succeed. Destroy all evidence that you even attempted.
