Very Computer

by **Shami Palanive** » Thu, 01 Aug 1996 04:00:00

Is there anything like NO LOCK option in sybase SQL server10.0.3.

The SELECT stmt (even without holdlock, isolation level=1,
unchained tran mode) momentarily acquires shared lock on the page
that is being read/selected (Sh_page). This sometime conflicts
with a long (4 mins, not too long I guess) running transaction
(updates) and causes deadlock. Is there any way where we can force
a SELECT stmt to retrieve records without any lock. It is ok even
if the data is dirty.

Following is the scenario of the tran execution:

User 1 User 2
------ ------
Begin tran
Update ... (locks pg 1)
Select ... (waiting to lock pg 1)
...

What I really want is the "select..." by User 2
should not acquire any locks.

I appreciate any help in this re:

Thanks

=================================================================
Shami Palanivelu ;

University of NorthDakota ; 701-777-2151 (Phone)
Grandforks, ND - 58202 ; 701-777-2940 (Fax)
=================================================================

by **Karen Hogobo** » Sat, 03 Aug 1996 04:00:00

>Is there anything like NO LOCK option in sybase SQL server10.0.3.

No...this functionality wasn't added until 10.1. In releases before
that, you'll need some sort of work around...I vagely remember a
hack where you could avoid the deadlock by forcing an early ex lock
instead of the intent lock using something like delete ... where 1 = 0.
The other option is to periodically create a temp table for the reader,
but this of course depends entirely on how often the data changes and
how current it needs to be for the reader.

-karenh

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

My opinions are only my own.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by **RGCramot** » Thu, 08 Aug 1996 04:00:00

Quote:Fairclough) writes:
>when trying to dump using system 11 on solaris 2.5 with the following
command
>:

>dump database megabase to '/dev/nrtape' with init

>i get

>Backup Server: 6.53.1.1: OPERATOR: Volume on device '/dev/nrtape' cannot
be
>opened for write access. Mount another volume.

I know this sounds basic, but, is the tape write protected?

Richard Cramotte, Jr.
Sybase DBA

Very Computer

Dirty reads

Dirty reads

Dirty reads

Dirty reads