The impact of I/O and and enqueue contention depends, of course, on the nature of the work being done – you might be wasting effort or losing time but it might be a waste of resources that you’re not worred about and time that is effectively invisible to the end-user. You should not be using basicfile LOBs in 19c, and both the nocache and nologging options can introduce problems of I/O and enqueue contention. Note, particularly, the key words basicfile, nocache, and nologging. Their performance issue was due to their BLOB defintion which, with the storage information removed, was as follows:
#Waiting for snapshot control file enqueue archive
The OP was running Oracle 19.9 but was suffering from a problem which (when I checked my archive and MOS) turned out to have a history (and a workaround) that started with 8.0.4. The forum note that triggered completion and publication was a complaint that’s common: “why is this so slow” but with a cause that comes up less frequently: “BLOB operations and control file parallel writes”. The original title was CF Enqueues but I’ve combined it with notes from another draft called LOB write waits to get to the final title because a couple of small variations in my test script can produce all the annoying symptoms you may want to investigate in that area. The conflict is usually caused when two jobs are both backing up the control file, and the job that first starts backing up the control file waits for service from the media manager.Originally drafted 4th Aug 2011, this is a blog note that has been waiting a little over 10 years to be completed and published and it’s probably worth doing it even now since the topic came up on the Oracle database forum just a couple of weeks ago. Recovery Manager makes up to five attempts to get the enqueue and then fails the job. Under normal circumstances, a job that must wait for the control file enqueue waits for a brief interval and then successfully retrieves the enqueue. If one RMAN job is already backing up the control file while another needs to create a new snapshot control file, you may see the following message: waiting for snapshot control file enqueue You can also set the snapshot control file name to a raw device: CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/dev/vgd_1_0/rlvt5' Subsequent snapshot control files that RMAN creates use the specified filename.įor example, start RMAN and then enter: CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/oradata/trgt/snap_trgt.ctl' Use the CONFIGURE SNAPSHOT CONTROLFILE NAME TO ' filename ' command to change the name of the snapshot control file. Setting the Location of the Snapshot Control File In these earlier releases, the default location for the snapshot control file was not dependent on the Oracle home, whereas in the current release the default location is dependent on the Oracle home. In general, you should only need to set the snapshot control file location when you are upgrading to the current release from a release earlier than 8.1.7. For example, the default filename on some UNIX platforms in Oracle Database 10 g is Note that if you have a flash recovery area configured, the default location for the snapshot control file is not the flash recovery area. The default value for the snapshot control file is platform-specific and depends on the Oracle home. RMAN needs a snapshot control file only when resynchronizing with the recovery catalog or when making a backup of the current control file. When RMAN needs to resynchronize from a read-consistent version of the control file, it creates a temporary snapshot control file. Setting the Snapshot Control File Location
0 kommentar(er)
