Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: 2 entries in V$SGASTAT for log_buffer -- Excessive rode log

RE: 2 entries in V$SGASTAT for log_buffer -- Excessive rode log

From: Khedr, Waleed <Waleed.Khedr_at_FMR.COM>
Date: Wed, 13 Sep 2000 16:13:00 -0400
Message-Id: <10618.116900@fatcity.com>


The small one is header info for the log buffers (big one).

-----Original Message-----
From: Val_Gamerman/Victoria_Financial.VICTORIA_FINANCIAL_at_lnn.com [mailto:Val_Gamerman/Victoria_Financial.VICTORIA_FINANCIAL_at_lnn.com] Sent: Wednesday, September 13, 2000 4:18 PM To: Multiple recipients of list ORACLE-L Subject: 2 entries in V$SGASTAT for log_buffer -- Excessive rode log

Hello,

I am still working on this issuse with redo logs. It's actually worse then I originally stated in my e-mail. During the night backup the redo logs are generated at the rate of two 10Mb files per minute with practically no activity against the database.

I understand that there will be more redo generated while I am in the backup mode, but not THAT much with no activity.

While trying to work on this problem with Oracle support I decided just for the heck of it to double check the value of the LOG_BUFFER in v$sgastat just to make sure that it's not different from what I have in init.ora.

To my great surprise I got 2 records returned from this view for the following query.

SQL>select * from v$sgastat

        2 where name = 'log_buffer'
        3 /
NAME                            BYTES
-------------------------- ---------
log_buffer                     1048576
log_buffer                     16384

SQL> The 1M entry is what we have it set to in the init.ora. I have no idea where the 16K is coming from and what it means.

If anybody could shed some light on this I would be very appreciative.

We are at the point were we have not had backup for two consequtive nights
-- the backup runs very slowly and estimated time to complete
is about 24 hours (I assume it happens because the box is bogged down with all this redo archiving).

Thanks,
Val Gamerman.

To:       Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:        (bcc: Val Gamerman/Victoria Financial)
          NOTES NET
Date:     09/11/2000 09:45:46 PM GMT







Hello,
I upgraded Oracle over the weekend from 7.2 to 7.3.4 (I know 7.3.4 is to be desupported soon, please no flames :-).
Our redo log switches used to occur every 1 hour - 2 hours. Now they occur every 25-30 minutes.
I know that this is still acceptable, however I can see that the database/application is sort of behaving slower then usual. I tried to talk to Oracle Support and did not get any help from them. The guy I talked to philosophy was -- if it's not down, it's working fine :-) It looks almost as if I was in the BACKUP mode all the time -- too much redo is generated. I did verify v$backup and all the files are in the 'NOT ACTIVE' status. When there is no activity against the database, naturally there is no log switches -- no log switches during the night. What should I check for? What can it be? There were no changes made to the application. We have the same number of users as we had before the upgrade. The only two things that changed are the Oracle version and location of some data files. Platform: Netware 4
Oracle: 7.3.4
LOG file size = 10M, there are 5 of them Database is in the ARCHIVE_LOG mode.
Any help is greatly appreciated.
Thanks,
Val Gamerman

--

Author:
  INET: Val_Gamerman/Victoria_Financial.VICTORIA_FINANCIAL_at_lnn.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may Received on Wed Sep 13 2000 - 15:13:00 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US