Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations sizbut on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Reading a book (Oracle Performance

Status
Not open for further replies.

CRoberts

MIS
Apr 14, 1999
70
US
Reading a book (Oracle Performance Tuning [an O'Reilly book], pg 427) tells of a sql script called Sync.sql. It explain on running this make little sense. Sync.sql is a file that is wrapped or encrypted. Yet the book tell of doing a "EXECUTE SYNC.INIT" like it was a existing stored package and method. Synch.sql errors out if I try and load it as if it were source code. Oracle documentation itself gives no indicate of this file. Has anyone every used this? How does it work.
 
What kind of errors? Can it be permisiion issue?

Regards, Dima
 
This seems to be a package for use with oracle version 7.
Here are the comments from sync.sql

Copyright (c) 1991 by Oracle Corporation
NAME
sync.sql - synchronization primitives to help write multi-user tests
DESCRIPTION
Call these routines to synchronize multiple test scripts.
RETURNS

NOTES
Several test scripts (such as sqldba scripts) can keep themselves
synchronized in order to test concurrent activity. These might be
different scripts or multiple instances of the same script. For
example, suppose you want to test the concurrent execution of
the stmt 'select * from dual' by three processes, followed by the
concurrent execution of 'grant select on dual to public' by three
processes. You would use the test mechanism to fork three
instances of the sqldba script:
execute sync.init(3)
execute sync.wait
select * from dual
execute sync.wait
grant select on dual to public;
or suppose you wanted to test the concurrent execution of
'select * from dual' and 'grant select on dual to public' Then you
have the test mechanism fork the two scripts:
execute sync.init(2) execute syn.init(2)
execute sync.wait execute sync.wait
grant select on dual to public select * from dual
You can also force ordering of stmts between two scripts. Suppose
you want to update from one script and then delete from another
script. You would fork the scripts:
execute sync.init(2) execute syn.init(2)
execute sync.wait execute sync.wait
update emp set sal=1000 where id=3 execute sync.wait
execute sync.wait delete emp where id=3

setdefaults - choose which sequence of lockids to use (defaults to
lockids 1,2,3 and 4. Also can specify the timeout in
seconds (defaults to forever)
init - assumes you hold no locks upon entry. It busywaits until all
cohorts (the number of which you specify as its parameter)
arrive. Upon exit you will hold a share lock on the front door.
wait - assumes you hold a share lock on the front door. It waits
(not busywait) until all cohorts arrive. Upon exit you will
hold a share lock on the front door of the next house.
cleanup - releases any locks still held

The first synchronization point in the scripts must be done with the
'init' call and all subsequent synchronization points must be done with
the 'wait' call. All cohorts must agree on the number of cohorts (the
value passed to the init call).

Lockids 1, 2 and 3 are used by these routines. The timeout is
essentially forever. You can change the lockids or the timeout with
setdefaults. If you choose lockid n, then lockids n, n+1 and n+2 will
be used. Currently changing the timeout is not supported.

This package assumes table 'sync$blocker(cnt number)' exists and has one
row. It does not matter what the value of the rows.


Regards

James
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top