T.R | Title | User | Personal Name | Date | Lines |
---|
5110.1 | | HOTRDB::PMEAD | Paul, [email protected], 719-577-8032 | Wed Mar 05 1997 16:01 | 8 |
| Yes, it is a lock that is used to momentarily prevent new update
transactions from starting. See the docs for RMU/BACKUP.
If they are running V7.0 then they are tripping over a "feature" of
V7.0. That is, in V7.0, Rdb also has read-only transactions take out
the quiet lock which really causes problems for backups when there are
long running read-only txns in the db. I don't know if this has been
fixed or not.
|
5110.2 | | NOVA::SMITHI | Don't understate or underestimate Rdb! | Wed Mar 05 1997 16:27 | 4 |
| But Paul, we don't name the resource 'QUIET' do we? This might be some power
build specific lock.
Ian
|
5110.3 | | HOTRDB::PMEAD | Paul, [email protected], 719-577-8032 | Wed Mar 05 1997 17:59 | 1 |
| We don't name it quiet, but RMU will display it as "QUIET".
|
5110.4 | | NOVA::SMITHI | Don't understate or underestimate Rdb! | Wed Mar 05 1997 20:18 | 12 |
| .0:
~The powerbuilder application is holding a PR lock (I think it was PR) on a
~resource named QUIET.
.3
~ We don't name it quiet, but RMU will display it as "QUIET".
Are you saying that RMU displays its RESOURCE NAME as "QUIET"? I think not.
Ian
|
5110.5 | Yes... | svrav1.au.oracle.com::MBRADLEY | I was dropped on my head as a baby. What's your excuse? | Wed Mar 05 1997 21:55 | 14 |
| Ian,
>Are you saying that RMU displays its RESOURCE NAME as "QUIET"? I think not.
Node: SVRVV1 Oracle Rdb V7.0-0 Performance Monitor 6-MAR-1997 12:47:43
Rate: 3.00 Seconds Stall Messages Elapsed: 00:02:09.18
Page: 1 of 1 SYSTEM$DIA0:[USER$DISK.MBRADLEY]JUNK.RDB;1 Mode: Online
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
Process.ID Since...... Stall.reason............................. Lock.ID.
000002DE:1u12:46:06.70 - waiting for quiet (EX) 1100089C
G'day,
Mark.
|
5110.6 | And yes ... | svrav1.au.oracle.com::MBRADLEY | I was dropped on my head as a baby. What's your excuse? | Wed Mar 05 1997 21:56 | 20 |
| Ian,
>Are you saying that RMU displays its RESOURCE NAME as "QUIET"? I think not.
================================================================================
SHOW LOCKS/MODE=BLOCKING Information
================================================================================
--------------------------------------------------------------------------------
Resource: quiet
ProcessID Process Name Lock ID System ID Requested Granted
--------- --------------- --------- --------- --------- -------
Waiting: 000002DE MBRADLEY....... 1100089C 00000000 EX NL
Blocker: 000002F4 _TNA106:....... 5200001B 00000000 CR CR
G'day,
Mark.
|
5110.7 | Well, if you stretch it a bit... | BOUVS::OAKEY | I'll take Clueless for $500, Alex | Wed Mar 05 1997 22:55 | 13 |
| >><<< Note 5110.6 by svrav1.au.oracle.com::MBRADLEY "I was dropped on my head as a baby. What's your excuse?" >>>
>> -< And yes ... >-
>>>Are you saying that RMU displays its RESOURCE NAME as "QUIET"? I think not.
>>Resource: quiet
Well, I'll have to admit....
QUIET <> quiet
:)
|
5110.8 | Actually I thought he was shouting :-) | svrav1.au.oracle.com::MBRADLEY | I was dropped on my head as a baby. What's your excuse? | Wed Mar 05 1997 23:21 | 14 |
| Kathy,
> QUIET <> quiet
That depends on how you measure it :-
$ a:==quiet
$ b:==QUIET
$ if a.eqs.b then write sys$output "quiet=QUIET"quiet=QUIET
quiet=QUIET
G'day,
Mark
|
5110.9 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Thu Mar 06 1997 08:18 | 14 |
| Yes, this *is* the "quiet-point lock", which RMU/SHOW STATS displays as "quiet"
(as does RMU/SHOW LOCKS, etc).
It should be noted that Rdb7 did NOT change the snapshot tx quiet-point lock
behaviour; snapshot transactions have ALWAYS taken out the quiet-point lock if a
previous read-write transaction was started (ever) during the attach.
Rdb7 simply made the snapshot transaction behaviour consistent in that the
quiet-point lock is consistently acquired (or not) regardless of whether a
previous read-write transaction was started.
FYI.
Rick
|
5110.10 | Is it possible that this quiet resource could block backup? | BROKE::BASTINE | | Thu Mar 06 1997 08:28 | 11 |
| Thanks for all the confirmation. Then there should be no reason why a backup
should be "blocked" by a process with this type of lock if the quietpoint
forces processes to take it out, correct?
I'm trying to now understand how this process with the quiet lock could be
"blocking" the backup. I haven't confirmed this is what the customer found,
this is what he said he found, but didn't ask why he thought that until I
had more information on what the quiet resource was.
Thanks,
Renee
|
5110.11 | | NOVA::SMITHI | Don't understate or underestimate Rdb! | Thu Mar 06 1997 08:45 | 5 |
| (OK I give in... what I was thinking about was the actual resource name as in
what the lock manager sees and this is not QUIET (or even quiet) but some
other sequence of bits)
Ian
|
5110.12 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Thu Mar 06 1997 08:55 | 16 |
| >I'm trying to now understand how this process with the quiet lock could be
>"blocking" the backup. I haven't confirmed this is what the customer found,
>this is what he said he found, but didn't ask why he thought that until I
>had more information on what the quiet resource was.
Obviously, any uncommitted transaction holding the quiet-point lock will block
the backup; the backup is waiting for all "active" transactions to commit.
If you don't want snapshot transactions to block a backup operation (or anything
else that waits for a quiet-point), then define the RDM$BIND_SNAP_QUIET_POINT
logical to "0" (default value is "1").
You can also do this temporarily using the SHOW STATS "Dashboard Facility"
*before* your snapshot transactions attach to the database.
Rick
|
5110.13 | | NOVA::DICKSON | | Thu Mar 06 1997 10:06 | 2 |
| There is also the /NOQUIET switch on the backup command, but read the
warnings about its use.
|
5110.14 | Thanks, it's all been very helpful! | BROKE::BASTINE | | Thu Mar 06 1997 12:28 | 3 |
| Thanks everyone... I need to get more information from the customer.
Renee
|
5110.15 | Why? | svrav1.au.oracle.com::MBRADLEY | I was dropped on my head as a baby. What's your excuse? | Thu Mar 06 1997 18:05 | 12 |
| Rick,
>Rdb7 simply made the snapshot transaction behaviour consistent in that the
>quiet-point lock is consistently acquired (or not) regardless of whether a
>previous read-write transaction was started.
Why should a read only TXN interact with the quiet point? I would have
thought it sufficient to stop R/W/ TXNs, and ignore R/O.
G'day,
Mark.
|
5110.16 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Fri Mar 07 1997 06:50 | 10 |
| Because the original definition of "quiet-point" was the prevention of new
transactions from starting, even read-only transactions.
Around Rdb v5.1 (I think) we relaxed this restriction to allow the DBA to ignore
snapshot transactions for the quiet-point operation.
There are some operations which MUST wait for ALL transactions to terminate.
Most, however, work just fine when snapshot transactions are running.
Rick
|