Snapshot_id duplicated in sys.slog$

Question

We have a master site with 20 snapshot sites. There are about 60 master tables with snapshot logs.
I have doubts regardind the snapshot_id.
In dba_registered_snapshots the snapshot_id is unique, but in sys.slog$, dba_snapshot_logs there are pairs of records with the same snapshot_id. One of the records matches the corresponding record in dba_registered_snapshots while the other has as a master table one that seems to be totally unrelated.
Does it make sense?
select *
from dba_snapshot_logs
where snapshot_id=4156
NAF46,MONEDAS,MLOG$_MONEDAS,,NO,YES,NO,2003/12/01 8:13:46 ,4156
NAF46,ARINTCL,MLOG$_ARINTCL,,NO,YES,NO,2003/12/05 2:33:34 ,4156
select *
from dba_registered_snapshots
where snapshot_id=4156
NAF46,SS_MONEDAS_OF,RICAPE01.WAKED.COM.CO,YES,NO,PRIMARY KEY,4156,ORACLE 8 SNAPSHOT,
The query_txt is:
SELECT "MONEDAS"."ID_MONEDA" "ID_MONEDA","MONEDAS"."DESC_MONEDA" "DESC_MONEDA","MONEDAS"."DESCRIPCION" "DESCRIPCION","MONEDAS"."SIGNO" "SIGNO","MONEDAS"."REDONDEO" "REDONDEO","MONEDAS"."NUMDECI" "NUMDECI","MONEDAS"."TSTAMP" "TSTAMP" FROM "MONEDAS"@WAKED.WAKED.COM.CO "MONEDAS"

Answer 1

No, the error has nothing to do with Service Broker. Or for that matter, query notifications, which is the feature you are actually using. (Query notifications uses Service Broker, but Service Broker != Query notification.)
You would get the same error if you had a trigger in MyObjects that tried to update the same row for both deletions. A snapshot transaction gives you a consistent view of the database in a certain point in time. Consider this situation:
Snapshot transaction A that started at time T update a row R at time T2. Snapshot transaction B starts at time T1 updates the same row at time T3. Had they been regular non-snapshot transaction, transaction B would have been blocked already when it tried
to read R, but snapshot transactions do not get blocked. But if B would be permitted to update R, the update from transaction A would be lost. Assume that the update is an incremental one, for instance updating cash balance for an account. You can see that
this is not permittable.
In your case, the row R happens to be a row in an internal table for query notifications, but it is the application design which is the problem. There is no obvious reason to use snapshot isolation in your example since you are only deleting. And there is
even less reason to have two transactions and connections for the task.
Erland Sommarskog, SQL Server MVP, [email protected]