RE: Diag dest
Date: Wed, 12 Jul 2023 09:55:17 -0400
Message-ID: <449301d9b4c8$7dfe3190$79fa94b0$_at_rsiz.com>
“If it "freezes" then you will have a bigger problem that diag dest most likely.”
yes, exactly: the dbwriters, log writers, and all the other things about database files have built in (and really slick) ways to buffer and batch (which is why single row commits in a loop are a performance 101 conversation topic and you had better really need single row transaction integrity if you commit every row). The firing off of diagnostic data, including creating files that may never be written to, but may be created very fast is a way to stress test to non-local storage.
IF your performance requirements and diagnostics writing is not a challenge for your infrastructure you may get by, but design, care, and feeding of diag files raises your performance ceiling on the same hardware.
If memory serves my friend Tanel once called a performance issue involving flat files and diagnostics the most complex he had seen to that point. It had been less complex several years earlier at coat because the relatively small non-dynamic inode limits made the UNIX OS slap us in the face for a similar issue. In that era everyone with a serious diag file output problem built something to handle it.
The high dynamic limits on inodes in more modern generations of the OS(es) means you can drive a pretty big performance issue without triggering OS warnings, making it much more difficult to diagnose. It should be on your radar, but you may not hit it. If you use local storage you eliminate network latency and load from diagnostics on your network.
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Ricard Martinez
Sent: Wednesday, July 12, 2023 8:55 AM
To: Mark W. Farnham
Cc: ilmar.kerm_at_gmail.com; Oracle-L Freelists
Subject: Re: Diag dest
I get your point about NFS, but, mainly, in RAC systems you use ASM (cellnodes, san/nas, whatever) and your DB files reside there.
If it "freezes" then you will have a bigger problem that diag dest most likely.
On Wed, Jul 12, 2023 at 11:18 AM Mark W. Farnham <mwf_at_rsiz.com> wrote:
Nods. The last thing you want to do is impair performance because of diagnostics getting hung up on network issues. +42 to Ilmar.
in re: inode limits. It may be a pain in the butt, but I recommend an at least daily sweeper: make a subdirectory yyyymmdd in each accumulating log and diagnostic directory and on yyyymmdd+2 mv all yyyymmdd files into yyyymmdd.
the mv local to a subdirectory moves only the names, but each subdirectory gets its own inode limit and you’re not going to run out of days. Then if you want to centralize with an actual copy of the contents you have a useful container to move. Organization by time (date) has always been useful. Purging is also efficient.
Some cases may require more frequent sweeping, but daily after a waiting a full day is a useful default configuration.
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Ilmar Kerm
Sent: Tuesday, July 11, 2023 4:35 PM
To: ricard.martinez_at_gmail.com
Cc: Oracle-L Freelists
Subject: Re: Diag dest
Local only local.
ACFS, NFS (anything shared?) can freeze and there also goes your database instance.
Also have hit some inode limits for NAS systems, that Oracle diag dest (or old style audit dest) will eventually reach.
Have a local agent on each server that will send the file contents to a central destination (like splunk or just a time series database)
Ilmar
On Tue, Jul 11, 2023 at 9:51 PM Ricard Martinez <ricard.martinez_at_gmail.com> wrote:
Hi everyone,
I've worked in several organizations with radical different visions about where to store the audit and trace files.
RAC nodes using ACFS for diag to have access to all files from any nodes, others using local filesystem for the same.
What are you thought and/or cons/pros about it?
Do you use ACFS as diag destination? Do you prefer to use local filesystem?
Thanks
--
Ilmar Kerm
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jul 12 2023 - 15:55:17 CEST