Oracle Distributed Systems [1st ed] 9781565924321, 1-56592-432-0

Citation preview

Oracle Distributed Systems

Oracle Dist ribut ed Syst em s Charles Dye Publisher: O'Reilly First Edit ion April 1999 I SBN: 1- 56592- 432- 0, 548 pages

This book describes how you can use m ult iple dat abases and bot h Oracle8 and Oracle7 dist ribut ed syst em feat ures t o best advant age. I t covers design, configurat ion of SQL* Net / Net 8, securit y, and Oracle's dist ribut ed opt ions ( advanced replicat ion, snapshot s, m ult i- m ast er replicat ion, updat eable snapshot s, procedural replicat ion, and conflict resolut ion) . I ncludes a com plet e API reference for built - in packages .

1

Oracle Distributed Systems

2

Oracle Distributed Systems

Oracle Dist ribut ed Syst em s Preface Audience for This Book About Replicat ion About Oracle Versions and Plat form s St ruct ure of This Book Convent ions Used in This Book About t he Script s Com m ent s and Quest ions Acknowledgm ent s I : The Dist ribut ed Syst em 1. I nt roduct ion t o Dist ribut ed Syst em s 1.1 Term inology and Concept s 1.2 What I s a Dist ribut ed Dat abase Syst em ? 1.3 Benefit s of Dist ribut ed Dat abases 1.4 Mult iple Schem a Versus Mult iple Dat abases 1.5 Opt ions for Dist ribut ed Dat a 1.6 Perils of Dist ribut ed Dat abases 1.7 Differences Bet ween Oracle7 and Oracle8 2. SQL* Net and Net 8 2.1 Prot ocol Overview 2.2 Archit ect ure 2.3 SQL* Net / Net 8 Tuning 2.4 Load Balancing 2.5 Oracle8 Scalabilit y Opt ions 2.6 SQL* Net / Net 8 Client Configurat ion 2.7 SNMP Support 2.8 Securit y 3. Configurat ion and Adm inist rat ion 3.1 I nit ializat ion Param et ers 3.2 Dat abase Links 3.3 Dist ribut ed Queries and Transact ions 3.4 Dist ribut ed Backup and Recovery 3.5 Mult iversion I nt eroperabilit y 4. Dist ribut ed Dat abase Securit y 4.1 Privilege Managem ent 4.2 Aut hent icat ion Met hods 5. Designing a Dist ribut ed Syst em 5.1 Charact erist ics of a Dist ribut ed Syst em 5.2 The Global Dat a Dict ionary 5.3 Replicat ion- Specific I ssues 5.4 Dat a Part it ioning Met hodologies 5.5 Applicat ion Part it ioning St rat egies 5.6 Procedural Replicat ion

3

Oracle Distributed Systems 6. Oracle's Dist ribut ed Syst em I m plem ent at ion 6.1 Meet ing t he 12 Obj ect ives wit h Oracle 6.2 Oracle's Global Dat a Dict ionary 7. Sam ple Configurat ions 7.1 The High- Availabilit y Syst em 7.2 Geographic Dat a Dist ribut ion 7.3 Workflow Part it ioning 7.4 Dat a Collect ion and Consolidat ion 7.5 Loosely Coupled Federat ion 8. Engineering Considerat ions 8.1 Schem a Design and I nt egrat ion 8.2 Applicat ion Tiering 8.3 Designing a Replicat ed Syst em I I : Replicat ion 9. Oracle Replicat ion Archit ect ure 9.1 What I s Oracle Replicat ion? 9.2 Types of Replicat ion 9.3 Archit ect ure Com ponent s 9.4 Replicat ion of DDL 9.5 Oracle8 Enhancem ent s 9.6 Oracle8i Enhancem ent s 9.7 Alt ernat ives t o Replicat ion 10. Advanced Replicat ion I nst allat ion 10.1 I nit ializat ion Param et ers 10.2 Redo Logs and Rollback Segm ent s 10.3 Size and Placem ent of Dat a Dict ionary Obj ect s 10.4 Adm inist rat ive Account s, Privileges, and Dat abase Links 11. Basic Replicat ion 11.1 About Read- Only Snapshot s 11.2 Prerequisit es and Rest rict ions 11.3 Snapshot Creat ion Basics 11.4 Sim ple Versus Com plex Snapshot s 11.5 Snapshot Logs 11.6 Subquery Subset t ing 11.7 Refresh Groups 11.8 Managem ent and Opt im izat ion 11.9 Script s 12. Mult i- Mast er Replicat ion 12.1 Concept s and Term inology 12.2 Get t ing St art ed 12.3 Replicat ion Groups 12.4 Mast er Sit e Maint enance and Propagat ion 12.5 Cont rolling Propagat ion 12.6 The Replicat ion Cat alog 12.7 Table Replicat ion 12.8 Replicat ing DDL

4

Oracle Distributed Systems 12.9 Your Replicat ed Environm ent 12.10 Advanced Replicat ion Lim it at ions 13. Updat eable Snapshot s 13.1 About Updat eable Snapshot s 13.2 Creat ing Updat eable Snapshot s 13.3 Com m unicat ion Flow 13.4 Cont rolling Propagat ion and Refreshes 13.5 Maint enance 14. Procedural Replicat ion 14.1 When t o Use Procedural Replicat ion 14.2 How Procedural Replicat ion Works 14.3 Creat ing a Replicat ed Package Procedure 14.4 Rest rict ions on Procedural Replicat ion 14.5 An Exam ple 15. Conflict Avoidance and Resolut ion Techniques 15.1 Dat a I nt egrit y Versus Dat a Convergence 15.2 Applicat ions That Avoid Conflict s 15.3 Types of Conflict s Det ect ed 15.4 How Oracle Det ect s and Resolves Conflict s 15.5 Colum n Groups and Priorit y Groups 15.6 The Built - in Met hods 15.7 Writ ing Your Own Conflict Resolut ion Handler I I I : Appendixes A. Built - in Packages for Dist ribut ed Syst em s A.1 DBMS_DEFER: Building Deferred Calls A.2 DBMS_DEFER_QUERY: Perform ing Diagnost ics and Maint enance A.3 DBMS_DEFER_SYS: Managing Deferred Transact ions A.4 DBMS_OFFLI NE_OG: Perform ing Sit e I nst ant iat ion A.5 DBMS_OFFLI NE_SNAPSHOT: Perform ing Offline Snapshot I nst ant iat ion A.6 DBMS_RECTI FI ER_DI FF: Com paring Replicat ed Tables A.7 DBMS_REFRESH: Managing Snapshot Groups A.8 DBMS_REPCAT: Perform ing Replicat ion Adm inist rat ion A.9 DBMS_REPCAT_ADMI N: Set t ing Up Adm inist rat ive Account s A.10 DBMS_REPCAT_AUTH: Set t ing Up More Adm inist rat ive Account s A.11 DBMS_REPUTI L: Enabling and Disabling Replicat ion A.12 DBMS_SNAPSHOT: Managing Snapshot s B. Script s and Ut ilit ies B.1 busycirc.sql B.2 busydisp.sql B.3 busyq.sql B.4 checklat ency B.5 colgroups.sql B.6 confst at s.sql B.7 cr_regions.sql B.8 defcall.sql B.9 defcalldest .sql B.10 defcallinfo.sql

5

Oracle Distributed Systems B.11 B.12 B.13 B.14 B.15 B.16 B.17 B.18 B.19 B.20 B.21 B.22 B.23 B.24 B.25 B.26 B.27 B.28 B.29 B.30 B.31 B.32 B.33 B.34 B.35 B.36 B.37 B.38 B.39 B.40 B.41 B.42 B.43 B.44 B.45 B.46 B.47 B.48 B.49 B.50 B.51 B.52

defdest .sql deferror.sql deferror8.sql deforigin.sql defschedule.sql deft ran.sql deft randest .sql disprat e.sql errorinfo.sql fixdefer.sql gendelerrt ran.sql gendelt ran.sql gengensup.sql groupedcols.sql invalids.sql j obs.sql keycols.sql last snap.sql lat ent .sql links.sql m ast ersnapinfo.sql m logs.sql needsgen.sql nonrepobj ect s.sql pk_regions.sql priorit ygroups.sql priorit ysit es.sql propm ode.sql refgroups.sql regsnaps.sql repcat err.sql repcat log.sql repconflict .sql repgroup.sql repobj ect s.sql repres.sql repsit es.sql resconfs.sql snaps.sql snaps7.sql t rg_regions.sql UserAdm in

Colophon

6

Oracle Distributed Systems

Pr e fa ce I n m y nearly 10 years of Oracle dat abase adm inist rat ion experience, I 've wit nessed t he em ergence of a dist ribut ed dat abase t echnology whose sophist icat ion level has risen while t he average user's underst anding of t hat t echnology has not . Wit h t he advent of Oracle's advanced replicat ion facilit ies, relat ively few DBAs are well versed in all aspect s of Oracle's dist ribut ed syst em s offerings, and few engineers fully recognize t he im plicat ions t hat dist ribut ed syst em s have for t heir code. As a result , m any hours are spent st ruggling t o im plem ent doom ed solut ions, and st ill m ore hours are spent support ing hobbled archit ect ures. Oracle's exploding feat ure set is not t o blam e t hese lost hours. There is a vast gap bet ween t he t heoret ical, or academ ic, knowledge base surrounding dist ribut ed syst em s and t he pract ical, or applied, knowledge base. I n general, t he people who underst and t he principles and nuances of a dist ribut ed environm ent are not t he sam e people who are out t here building syst em s. The publicat ions on dist ribut ed syst em s reflect t his divide; m ost books are eit her very t heoret ical and cont ain lit t le specific advice or are rat her sim plist ic cookbooks for t hose on t he front lines ( or in t he kit chen, as t he case m ay be) . Needless t o say, it can be rat her frust rat ing t o find t he inform at ion you need when one book discusses set t heory and anot her says " point here, click t here." This book st rives t o close t he gap bet ween t he t heoret ical and t he applied by explaining t he obj ect ives of t he ideal dist ribut ed syst em in t he cont ext of Oracle's t echnology. I exam ine t he reasons why dist ribut ed syst em s should have cert ain propert ies and discuss how Oracle is designed t o deliver t hese propert ies. I also provide design recom m endat ions for various com m on requirem ent s. And, finally, I deliver program m ing exam ples and script s and t ricks for t he DBA. I wish I had had t his book 10 years ago.

Au die n ce for Th is Book This book is int ended prim arily for Oracle dat abase adm inist rat ors, developers, syst em adm inist rat ors, net work adm inist rat ors, and ot hers who need t o build or m aint ain dist ribut ed dat abase syst em s.

Abou t Re plica t ion This book cont ains a subst ant ial am ount of det ail about Oracle's advanced replicat ion facilit ies. Most of t his inform at ion has been obt ained t hrough several real- world im plem ent at ions, and m y advice is based on experiences and sit uat ions t hat are, for t he m ost part , not addressed in Oracle's docum ent at ion. I n addit ion t o sharing t he benefit of m y experience, t his book t ries t o convey a fundam ent al underst anding of how t he advanced replicat ion facilit ies act ually work. I describe it s underpinnings, it s lim it at ions, and how t o use it successfully t o solve a variet y of problem s. One t hing t his book does not at t em pt t o describe is Oracle's GUI t ool—Replicat ion Manager. Alt hough t his t ool m ay be useful for t he adm inist rat ion of a pre- exist ing,

7

Oracle Distributed Systems st able environm ent , using it does not give you any insight int o how replicat ion works or int o t he viabilit y of your environm ent . I n addit ion, t he t ool is not very useful for solving t he inevit able problem s t hat arise in a replicat ed environm ent . I f you are int erest ed in using Oracle's Replicat ion Manager, we refer you t o t he Oracle8 Server Replicat ion Guide.

Abou t Or a cle Ve r sion s a n d Pla t for m s At t his point , I work wit h Oracle8 alm ost exclusively in bot h product ion and developm ent environm ent s. Therefore, m ost of t he specific exam ples and recom m endat ions in t his book are proven on Oracle8. I n cases in which I refer t o Oracle7, I m ean Version 7.3.0 and lat er. When I am aware of how a feat ure will work under t he upcom ing release, Oracle8i, I have not ed t hat as well. As a general observat ion, m y experience wit h Oracle8 has been quit e posit ive, especially where replicat ion is concerned. I f you have not yet m igrat ed t o Oracle8, m y advice is t o do so as soon as possible. Most of t he exam ples described in t his book were developed on a Unix operat ing syst em ; however, SQL script s are very port able, and m ost of t hem will run as is on Windows NT and ot her operat ing syst em s.

St r u ct u r e of Th is Book This book is divided int o t hree part s:

Pa r t I Chapt er 1, is an overview of dist ribut ed syst em s—t erm inology, basic concept s, benefit s and perils, and t he various opt ions provided by Oracle. Chapt er 2, describes t he underlying prot ocols Oracle supplies t o support com m unicat ion wit h dist ribut ed Oracle dat abases over a net work. Chapt er 3, explains how t o set up a dist ribut ed dat abase environm ent ; it discusses init ializat ion param et ers, dat abase links, how dist ribut ed t ransact ions work, and t he basics of dist ribut ed backup and recovery. Chapt er 4, describes special securit y concerns for dist ribut ed syst em s; it looks at privilege m anagem ent , various aut hent icat ion m et hods, t he encrypt ion of net work t raffic, and t he use of t he Oracle Securit y Server ( OSS) and t he Advanced Net working Opt ion ( ANO) . Chapt er 5, exam ines t he design of a dist ribut ed syst em ; it int roduces C. J. Dat e's fundam ent al principles of dist ribut ed dat abases, discusses t he global dat a dict ionary, and recom m ends a part icular approach t o dat a part it ioning. Chapt er 6, exam ines how Oracle's RDBMS and net working product s m eet Dat e's obj ect ives for dist ribut ed dat abase syst em s.

8

Oracle Distributed Systems Chapt er 7, focuses on t he m ost com m on dist ribut ed archit ect ures: t he highavailabilit y syst em , syst em s illust rat ing geographic dat a dist ribut ion, workflow part it ioning, and dat a collect ion and consolidat ion, and t he loosely coupled federat ion. Chapt er 8, exam ines t he special requirem ent s of dist ribut ed syst em s t hat m ust be t aken int o account during t he engineering process: schem a design and int egrat ion, applicat ion t iering, and t he design of a replicat ed applicat ion.

Pa r t I I Chapt er 9, t akes a deeper look at Oracle's replicat ion archit ect ure; it exam ines t he various t ypes of replicat ion available t hrough Oracle, specific archit ect ural com ponent s, inst allat ion t ips, and enhancem ent s for Oracle8 and Oracle8i. Chapt er 10, describes how t o set up an advanced replicat ion environm ent , including t he set t ing of init ializat ion param et ers, t he select ion of redo logs and rollback segm ent s, t he size and placem ent of dat a dict ionary obj ect s, and t he use of adm inist rat ive account s, privileges, and dat abase links. Chapt er 11, is a det ailed analysis of Oracle's basic replicat ion ( snapshot ) facilit y. Chapt er 12, is a det ailed analysis of Oracle's m ult i- m ast er replicat ion facilit y. Chapt er 13, is a det ailed analysis of Oracle's updat eable snapshot facilit y. Chapt er 14, is a det ailed analysis of Oracle's procedural replicat ion facilit y. Chapt er 15, describes a variet y of t echniques for avoiding conflict s am ong t he various dist ribut ed sit es where dat a is replicat ed.

Pa r t I I I Appendix A, is t he Applicat ion Program m ing I nt erface ( API ) reference; it cont ains sum m aries of all specificat ions, param et ers, except ions, and rest rict ions for t he procedures and funct ions available t hrough t he Oracle built - in packages used wit h dist ribut ed syst em s. Appendix B, cont ains t he code for a variet y of script s m ent ioned in t his book.

Con ve n t ion s Use d in Th is Book I ndicat es a t ip, suggest ion, or general not e. For exam ple, we'll t ell you if you need t o use a part icular Oracle version or if an operat ion requires cert ain privileges.

I ndicat es a warning or caut ion. For exam ple, we'll t ell you if Oracle does not behave as you'd expect or if a part icular operat ion has a negat ive im pact on perform ance.

9

Oracle Distributed Systems

I t alic Used for script nam es, filenam es, direct ory nam es, and operat ing syst em com m ands. Also used for replaceables in t ext , for em phasis, and t o int roduce new t erm s.

Const ant widt h Used for code exam ples.

Constant width italic Used in code exam ples t o indicat e elem ent s ( e.g., filenam es) t hat you supply.

Constant width bold Used occasionally t o highlight part icular it em s in code being discussed.

UPPERCASE I n code exam ples, generally indicat es Oracle keywords.

lowercase I n code exam ples, generally indicat es user- defined it em s such as variables, param et ers, and so fort h.

punct uat ion I n code exam ples, ent er exact ly as shown.

* and * / I n code exam ples, t hese charact ers delim it a com m ent , which can ext end from one line t o anot her.

- - / or # I n code exam ples, t hese charact ers indicat e t he st art of a com m ent line.

[ ] I n synt ax descript ions, square bracket s enclose opt ional it em s.

{} I n synt ax descript ions, curly bracket s enclose a set of it em s; you m ust choose only one of t hem .

10

Oracle Distributed Systems

| I n synt ax descript ions, a vert ical bar separat es t he it em s enclosed in curly bracket s, as in { VARCHAR | DATE | NUMBER} .

Abou t t h e Scr ipt s I n addit ion, t hese script s are available at t he O'Reilly web sit e ( see Sect ion P.7) .

Com m e n t s a n d Qu e st ion s Please address com m ent s and quest ions concerning t his book t o t he publisher: O'Reilly & Associat es, I nc. 101 Morris St reet Sebast opol, CA 95472 800- 998- 9938 ( in t he U.S. or Canada) 707- 829- 0515 ( int ernat ional or local) 707- 829- 0104 ( fax) You can also send us m essages elect ronically. To be put on our m ailing list or request a cat alog, send em ail t o: nut [email protected] To ask t echnical quest ions or com m ent on t he book, send em ail t o: bookquest [email protected] For correct ions and am plificat ions for t he book, as well as for copies of t he script s found in t his book, check out ht t p: / / www.oreilly.com / cat alog/ oradist sys. See t he ads at t he end of t he book for inform at ion about all of O'Reilly & Associat es' online services.

Ack n ow le dgm e n t s Fort unat ely m any people have support ed m e in t he writ ing of t his book; t rit e as it m ay sound, I definit ely could not have done it by m yself. While m y nam e m ay appear on t he byline, t here are num erous people whose cont ribut ions, t echnical and ot herwise, have been invaluable. This is t he second book I have writ t en for O'Reilly & Associat es, and m y first solo effort . Debby Russell, m y edit or, has provided guidance and encouragem ent , as well as a m easure of adm onishm ent , all of which have led t o a successful proj ect . Debby has t wo abilit ies which result in great books for O'Reilly: m ot ivat ing writ ers and envisioning a high- qualit y product . Many t hanks as well t o St eve Abram s, who convert ed files, did lot s of preproduct ion work on t he t ext , and ot herwise helped m ove t hings along efficient ly. And finally, t hanks t o t he ent ire product ion st aff; you did a great j ob.

11

Oracle Distributed Systems My first line of support for solving int ract able replicat ion issues and one of t he prim ary reviewers of t his book was Jenny Tsai of Oracle Corporat ion. Jenny has been able t o help m e research issues wit h t he ut m ost t horoughness and has devot ed a significant am ount of t im e t o validat ing t he accuracy of t he m at erial present ed here. And m ost im port ant ly, Jenny int roduced m e t o Oracle's advanced replicat ion several years ago when she t aught t he sym m et ric replicat ion class for Oracle Educat ion. Ot her folks at Oracle have been m ost generous wit h t heir t im e and have provided significant assist ance wit h various port ions of t his book. Harvey Enem an, t he archit ect of m ult i- t hreaded server ( MTS) , provided ext ensive consult at ion. Sue Jang, who probably has m ore experience wit h im plem ent ing replicat ion t han anybody, has provided valuable input int o t he replicat ion chapt ers. Virt ually all m em bers of t he replicat ion t eam have been very helpful, not only wit h t he cont ent s of t his book but also wit h t he resolut ion of real- world issues. They include Al Dem ers, Alan Downing, Pat McElroy, Maria Prat t , Benny Souder, Jim St am os, Harry Sun, and Lik Wong. Ot her reviewers who have provided insight from t he consum er point of view include Jerem y Brinkley, Pet er Grendler, and Teresa Shaw. All of t hese people have been working wit h Oracle for a num ber of years, and were able t o provide com m ent ary from t he point of view of DBAs and engineers. Wit t ingly or not , m y m anagers at Excit e also have cont ribut ed t o t he qualit y of t his book. Dan Nat er and Jon Prall have asked m e t o push Oracle's replicat ion t echnology t o it s lim it s, which I have. Their insat iable t hirst for solut ions has enhanced m y abilit y t o opt im ize a replicat ed environm ent , and t he knowledge I have gained m eet ing t heir request s is all available here. Chances are, you will not ever need t o push Oracle replicat ion as far as Dan and Jon have. Finally, I t hank m y wife, Kat hy, who has been incredibly pat ient and underst anding t hroughout t he course of m y writ ing t his book. Nobody is looking forward t o it s com plet ion m ore t han she is.

12

Oracle Distributed Systems

Pa r t I : Th e D ist r ibu t e d Syst e m Part I int roduces dist ribut ed dat abase syst em s and provides inform at ion on t he net working, configurat ion, securit y, and design of t hese syst em s. I t cont ains t he following chapt ers: •

•

• •

• •

• •

Chapt er 1, is an overview of dist ribut ed syst em s—t erm inology, basic concept s, benefit s and perils, and t he various opt ions provided by Oracle. Chapt er 2, describes t he underlying prot ocols Oracle supplies t o support com m unicat ion wit h dist ribut ed Oracle dat abases over a net work. Chapt er 3, explains how t o set up a dist ribut ed dat abase environm ent ; it discusses int it ializat ion param et ers, dat abase links, how dist ribut ed t ransact ions work, and t he basics of dist ribut ed backup and recovery. Chapt er 4, describes special securit y concerns for dist ribut ed syst em s; it looks at privilege m anagem ent , various aut hent icat ion m et hods, t he encrypt ion of net work t raffic, and t he use of t he Oracle Securit y Server ( OSS) and t he Advanced Net working Opt ion ( ANO) . Chapt er 5, exam ines t he design of a dist ribut ed syst em ; it int roduces C. J. Dat e's fundam ent al principles of dist ribut ed dat abases, discusses t he global dat a dict ionary, and recom m ends a part icular approach t o dat a part it ioning. Chapt er 6, exam ines how Oracle's RDBMS and net working product s m eet Dat e's obj ect ives for dist ribut ed dat abase syst em s. Chapt er 7, focuses on t he m ost com m on dist ribut ed archit ect ures: t he highavailabilit y syst em , syst em s illust rat ing geographic dat a dist ribut ion, workflow part it ioning, and dat a collect ion and consolidat ion, and t he loosely coupled federat ion. Chapt er 8, exam ines t he special requirem ent s of dist ribut ed syst em s t hat m ust be t aken int o account during t he engineering process: schem a design and int egrat ion, applicat ion t iering, and t he design of a replicat ed applicat ion.

13

Oracle Distributed Systems

14

Oracle Distributed Systems

Ch a pt e r 1 . I n t r odu ct ion t o D ist r ibu t e d Syst e m s Any organizat ion t hat uses t he Oracle relat ional dat abase m anagem ent syst em ( RDBMS) probably has m ult iple dat abases. There are a variet y of reasons why you m ight use m ore t han a single dat abase in a dist ribut ed dat abase syst em : •

•

• •

•

Different dat abases m ay be associat ed wit h part icular business funct ions, such as m anufact uring or hum an resources. Dat abases m ay be aligned wit h geographic boundaries, such as a behem ot h dat abase at a headquart ers sit e and sm aller dat abases at regional offices. Two different dat abases m ay be required t o access t he sam e dat a in different ways, such as an order ent ry dat abase whose t ransact ions are aggregat ed and analyzed in a dat a warehouse. A busy I nt ernet com m erce sit e m ay creat e m ult iple copies of t he sam e dat abase t o at t ain horizont al scalabilit y. A copy of a product ion dat abase m ay be creat ed t o serve as a developm ent t est bed.

Som et im es t he relat ionship bet ween m ult iple dat abases is part of a well- planned archit ect ure, in which dist ribut ed dat abases are designed and im plem ent ed as such from t he beginning. I n ot her cases, t hough, t he relat ionship is unforeseen; it is quit e com m on for dist ribut ed dat abases t o evolve as businesses expand, requirem ent s grow, and applicat ions spawn. But com m on t o all cases is t he need t o copy or reference dat a in one or m ore rem ot e dat abases. A dist ribut ed dat abase syst em will m eet one or m ore of t he following obj ect ives:

Availabilit y Dat a m ust be available at t he local sit e even when a rem ot e sit e is unreachable.

Survivabilit y The failure of any single dat abase inst ance m ust not im pact t he ongoing business.

Dat a collect ion Regional dat a such as sales receipt s is consolidat ed and aggregat ed at a single sit e.

Dat a ext ract ion A dat a warehouse ext ract s t ransact ion records from an online t ransact ion processing ( OLTP) syst em .

15

Oracle Distributed Systems

Decent ralized dat a Dat a m ay be updat ed in several dat abases.

Maint enance There m ust be support for act ivit ies such as load t est ing wit h dat a from product ion in a benchm arking dat abase. Oracle Corporat ion int roduced int erdat abase connect ivit y wit h SQL* Net in Oracle Version 5 and sim plified it s usage considerably wit h t he dat abase links feat ure in Oracle Version 6, opening up a world of dist ribut ed possibilit ies. Oracle now supplies a variet y of t echniques t hat you can use t o est ablish int erdat abase connect ivit y and dat a sharing. Each t echnique has it s advant ages and disadvant ages, but in m any cases t he best solut ion is not im m ediat ely obvious. Before delving int o Oracle's offerings in t he dist ribut ed dat abase syst em s area, I 'll clarify som e t erm inology and concept s.

1 .1 Te r m in ology a n d Con ce pt s I have found t hat t here is a great deal of confusion surrounding t he various product s and t erm inology from Oracle. I t hink it 's wort hwhile t o clarify som e of t hese t erm s up front so you'll get t he m ost benefit from t his book.

Dat abase/ dat abase inst ance These t erm s are oft en used int erchangeably, but t hey are not t he sam e t hing. I n Oracle parlance, a dat abase is t he set of physical files cont aining dat a. These files com prise t ablespaces, redo logs, and cont rol files. A dat abase inst ance ( or sim ply inst ance) is t he set of processes and m em ory st ruct ures t hat m anipulat e a dat abase. A dat abase m ay be accessed by one or m ore dat abase inst ances, and a dat abase inst ance m ay access exact ly one dat abase.

Oracle parallel server Oracle parallel server( OPS) is a t echnology t hat allows t wo or m ore dat abase inst ances, generally on different m achines, t o open and m anipulat e one dat abase, as shown in Figure 1.1. I n ot her words, t he physical dat a files ( and t herefore dat a) in a dat abase can be seen, insert ed, updat ed, and delet ed by users logging on t o t wo or m ore different inst ances; t he inst ances run on different m achines but access t he sam e physical dat abase.

16

Oracle Distributed Systems

Figu r e 1 .1 . Pa r a lle l se r ve r a r ch it e ct u r e

Oracle parallel server requires an operat ing syst em t hat support s clust ering and a dist ribut ed lock m anager because t he m ult iple dat abase inst ances m ust share inform at ion about t he dat a t hat is updat ed, t he lock resources, and so on. For exam ple, if a user on inst ance A updat es a row, and a user on inst ance B perform s a query t hat would ret urn t hat row, inst ance B m ust inst ruct inst ance A t o writ e t he updat ed dat a t o t he physical dat abase so t hat t he query will deliver t he updat ed inform at ion. Oracle parallel server is int ended t o provide failover capabilit ies —capabilit ies t hat allow a second m achine t o t ake over t he processing being perform ed by t he first in t he event of m achine failure ( e.g., CPU or m ot herboard failure) . I t does not provide any prot ect ion from disk failure. Occasionally, parallel server t echnology is used t o achieve horizont al scalabilit y, a concept I 'll discuss lat er in t his chapt er.

St andby dat abase Oracle int roduced t he st andby dat abase in Version 7.2, alt hough som e sit es had creat ed t heir own hom egrown variet ies earlier. A st andby dat abase is one t hat shadows a norm al dat abase and is always in recovery m ode. Whenever a redo log is archived in t he prim ary dat abase, t he archived redo log is applied t o t he st andby dat abase, as shown in Figure 1.2. Generally, t he st andby dat abase resides on a separat e m achine and uses separat e st orage.

17

Oracle Distributed Systems

Figu r e 1 .2 . St a n dby da t a ba se

I f t he prim ary dat abase fails, t he DBA can open t he st andby dat abase and point users t o it inst ead of t o t he prim ary dat abase. Once t his occurs, what had been t he st andby dat abase becom es t he prim ary dat abase, and it cannot be put back int o st andby m ode again.

Advanced replicat ion A dvanced replicat ion, also known as sym m et ric replicat ion or m ult i- m ast er replicat ion , refers t o m aint aining a t able or t ables in m ult iple dat abases such t hat DML ( Dat a Manipulat ion Language) can be issued in any of t he dat abases and applied t o t he ot hers aut om at ically. The DML m ay be propagat ed synchronously ( i.e., DML is com m it t ed locally and rem ot ely as a single t ransact ion) or asynchronously ( i.e., DML com m it t ed locally is placed in a queue from which it is applied at t he rem ot e sit e lat er) . Advanced replicat ion can be used t o deliver high availabilit y, in t he sense t hat t he unavailabilit y of any one sit e does not affect t he ot hers, or it m ay be used as part of a survivabilit y policy in which every dat abase has a replicat ed copy t hat can be used in t he event of failure. Unlike parallel server, advanced replicat ion involves num erous dat abases and num erous dat abase inst ances.

Parallel query The parallel query opt ion ( PQO) is a t echnology t hat can divide com plicat ed or long- running queries int o several independent queries and allocat e separat e processes t o execut e t he sm aller queries. A coordinat or process collect s t he result s of t he sm aller queries and const ruct s t he final result set . Parallel queries are effect ive only on m achines t hat have m ult iple CPUs.

Parallel DML

18

Oracle Distributed Systems Oracle int roduced t he parallel DML feat ure in Oracle8. Parallel DML is sim ilar t o parallel query, except t hat t he independent processes perform DML. For exam ple, an updat e of several hundred t housand rows can be doled out t o several processes t hat execut e t he updat e on separat e ranges of t he t able.

1 .2 W h a t I s a D ist r ibu t e d D a t a ba se Syst e m ? A dist ribut ed dat abase syst em , illust rat ed in Figure 1.3, is an environm ent in which dat a in t wo or m ore dat abase inst ances is accessible as t hough t his dat a were in a single inst ance. This access m ay be read- only, or it m ay perm it updat es t o one or m any inst ances. The referenced dat a m ay be real t im e, or it m ay be seconds, hours, or days old. Generally, t he different dat abase inst ances are housed on different server nodes, and com m unicat ion bet ween t hem is via SQL* Net ( for Oracle7) or Net 8 ( for Oracle8) . Chapt er 2, describes t his com m unicat ion. I n addit ion t o dat abase servers, a dist ribut ed dat abase syst em usually includes applicat ion servers and client s. The focus of t his book is on t he int eract ion am ong dat abase servers, but a brief review of t he ent ire dist ribut ed environm ent will clarify t heir raison d'êt re.

Figu r e 1 .3 . A dist r ibu t e d da t a ba se syst e m

Applicat ion servers , like dat abase servers, t ypically are high- capacit y m achines t hat run int ensive ut ilit ies such as web applicat ions, Oracle's applicat ion cart ridges, report generat ors, and so fort h. The client s in t his environm ent are t ypically PCs or Macint oshes or ot her light weight com put ers running web browsers. The client 's role is t o provide an int erface t o t he

19

Oracle Distributed Systems user, such as Form s ( in Oracle Developer 2000) and web browsers. Client m achines are charact erized by low cost and t he absence of a local dat abase. I m plicit in t his dist ribut ed syst em archit ect ure is t he net work . I t links dat abase servers, applicat ion servers, and client s. SQL* Net and Net 8 are net work int erfaces t hat are prot ocol- independent and t hat provide com m unicat ion t o net worked dat abases.

1 .3 Be n e fit s of D ist r ibu t e d D a t a ba se s The separat ion of t he various syst em com ponent s, especially t he separat ion of applicat ion servers from dat abase servers, yields t rem endous benefit s in t erm s of cost , m anagem ent , and perform ance.

1 .3 .1 Tu n a bilit y A m achine's opt im al configurat ion is a funct ion of it s workload. Machines t hat house web servers, for exam ple, need t o service a high volum e of sm all t ransact ions, whereas a dat abase server wit h a dat a warehouse has t o service a relat ively low volum e of large t ransact ions ( i.e., com plex queries) . Separat ing t he web server from t he dat abase server in t his exam ple allows t he syst em adm inist rat ors t o opt im ize t hese m achines wit hout com prom ise. A m achine configured as a web server will differ from a m achine configured as a dat a warehouse dat abase server. I f perform ance problem s arise in a dist ribut ed archit ect ure, it is m uch easier not only t o ident ify problem s but also t o solve t hem wit hout t he risk of com prom ising ot her com ponent s.

1 .3 .2 Pla t for m Au t on om y Since applicat ions and dat abases do not reside on t he sam e m achines, t here is no part icular reason why t hey even need t o reside on t he sam e t ype of m achine. SQL* Net and Net 8 provide a prot ocol- independent net work int erface allowing connect ivit y am ong disparat e plat form s and even disparat e dat abase engines. This openness allows DBAs, developers, and deskt op users t o choose t heir plat form s wit hout being rest rict ed by anybody else's preferences or requirem ent s. Whet her you perform a m aj or plat form change such as m oving from VMS t o Unix or a m inor upgrade such as from Solaris 2.5 t o Solaris 2.6, you can m ake t hese changes wit hout risking funct ionalit y changes in t he Oracle dat abase engine.

1 .3 .3 Fa u lt Tole r a n ce The failure of a single com ponent in a dist ribut ed archit ect ure is m uch less drast ic t han in an environm ent in which dat abases and applicat ions are housed on t he sam e m achine. Adm inist rat ors can design failover m et hodologies t hat are appropriat e t o each com ponent 's funct ionalit y. For exam ple, dat abase m achines m ight im plem ent parallel server or synchronous replicat ion t o prot ect against failure of a dat abase m achine, whereas applicat ion servers m ay have backup hardware available so t hat t he applicat ion can run on a new m achine if an applicat ion server fails. Prot ect ing against failure of m achines t hat house dat a is generally m uch m ore com plicat ed t han prot ect ing against failure of m achines t hat sim ply run applicat ions.

20

Oracle Distributed Systems

1 .3 .4 Sca la bilit y A server t hat houses not hing ot her t han an Oracle dat abase scales very predict ably; sit es t aking advant age of t he parallel query opt ion ( and/ or parallel DML in Oracle8) can expect perform ance t o be a nearly linear funct ion of t he num ber of processors ( up t o t he point of at least 30 processors on Solaris) . Ot her applicat ions m ay or not scale t his way, but if t he applicat ions have t heir own host , syst em adm inist rat ors can underst and t heir requirem ent s and allocat e hardware resources appropriat ely.

1 .3 .5 Loca t ion Tr a n spa r e n cy Locat ion t ransparency m eans t hat neit her applicat ions nor users need t o be concerned wit h t he logist ics of where dat a act ually resides or how it is dist ribut ed. Needless t o say, being shielded from t hese specifics enhances t he usabilit y of a dat abase because developers and users do not need t o consider such det ails as connect st rings. Moreover, dat a can be relocat ed from one dat abase inst ance t o anot her wit h m inim al im pact on users and applicat ions.

1 .3 .6 Sit e Au t on om y Dist ribut ed dat abases allow various locat ions t o share t heir dat a wit hout conceding adm inist rat ive cont rol. I f a dat abase inst ance at headquart ers cont ains part icularly sensit ive inform at ion or has high availabilit y requirem ent s, it can st ill share dat a wit hout com prom ising it s securit y or availabilit y. I n addit ion, any given sit e in a dist ribut ed dat abase environm ent can follow it s own adm inist rat ive procedures and upgrade pat hs, wit hin reason. Of course, we hope t hat adm inist rat ors from various sit es are in com m unicat ion wit h one anot her and t hat t hey coordinat e t heir act ivit ies, but t hey are in no way handcuffed t o one anot her.

1 .3 .7 En h a n ce d Se cu r it y The com ponent s of t he dist ribut ed archit ect ure are com plet ely independent of one anot her, which m eans t hat every sit e can be m aint ained independent ly. You can share dat a wit hout sharing account s and passwords. Each sit e can have it s own adm inist rat ors and it s own set s of account s, and privat e dat a can be kept privat e. As an exam ple, you can im plem ent a replicat ed environm ent wit h updat eable snapshot s t hat would allow users at a branch office t o updat e som et hing as sensit ive as t he salary t able wit hout having any access t o t he salary dat a for headquart ers ( horizont al part it ioning) . As anot her exam ple, you can use workflow part it ioning ( discussed in Chapt er 15) in a m ult i- m ast er replicat ed environm ent t o lim it t he set of rows t hat can be updat ed at any given sit e. You also can configure a dist ribut ed environm ent t o provide securit y in t he sense of survivabilit y—t hat is, you can m aint ain t wo or m ore versions of ent ire schem a by replicat ing t hem t o different m achines at different locat ions. There is no reason for developers or end users t o have account s on a dat abase server, because all dat abase access is t hrough net work API s ( Applicat ion Program m ing I nt erfaces) . The dat abase server's exposure t o m alicious int ruders and

21

Oracle Distributed Systems careless users is m inim al. I n fact , it is not uncom m on for users t o have no idea what soever where t he dat abase resides!

1 .4 M ult iple Sche m a Ve r su s M u lt iple D a t a ba se s Most designers and dat abase adm inist rat ors associat e one schem a wit h one applicat ion. ( By schem a, I m ean an Oracle dat abase account t hat owns t he dat abase obj ect s t hat an applicat ion uses.) Whenever a new schem a is int roduced, t he designers and DBAs m ust choose bet ween giving t he schem a it s own dat abase or placing it wit h ot her schem a in an exist ing dat abase. A num ber of fact ors affect t his decision

1 .4 .1 Th e Sin gle D a t a ba se w it h M u lt iple Sch e m a Quit e oft en,it m akes sense t o let schem a and applicat ions share a dat abase inst ance. The t wo prim ary advant ages of t his approach are lower adm inist rat ive overhead and lower hardware cost s. Every Oracle dat abase inst ance carries a cert ain am ount of overhead: disk space m ust be allocat ed t o syst em , t em porary, and rollback t ablespaces; and m em ory m ust be allocat ed t o t he SGA ( Syst em Global Area) . I n addit ion, a DBA m ust m anage users, SQL* Net configurat ion, dat abase links, and so on. I f you can m inim ize t his overhead, by all m eans do so. I f t he schem as share dat a, t hen you m ay realize addit ional benefit s. For exam ple, an invent ory applicat ion t hat shares a VENDORS t able wit h an account s payable applicat ion can access t he t able wit hout depending on t he availabilit y of t wo dat abases. The adm inist rat ive work is sim plified because no dat abase links are required, and applicat ion code is sim plified because no error t rapping need exist t o handle t he unavailabilit y of t he VENDORS t able. Even if applicat ions do not share dat a, you should consider placing different schem a in t he sam e dat abase if you can answer " Yes" t o all quest ions in Table 1.1.

Table 1.1. Conditions for Locating Application Schema in the Same Database Instance Requirement

Yes No

Are m ost users in t he sam e locat ion or using t he sam e access pat h? Do t he applicat ions have t he sam e adm inist rat ive support st aff? Do t he applicat ions have com pat ible availabilit y requirem ent s? Do t he applicat ions have com pat ible dat abase and OS version requirem ent s and upgrade pat hs? Are t he applicat ions reasonably sim ilar in funct ionalit y and load charact erist ics? Do t he applicat ions have t he sam e usage level ( e.g., QA, developm ent , product ion, m aint enance, et c.) ?

22

Oracle Distributed Systems As a general rule, it is m ore econom ical t o house schem as in a single dat abase inst ance t han t o devot e an inst ance t o every applicat ion t hat com es down t he pike. Don't creat e addit ional inst ances wit hout good reason.

1 .4 .2 D a t a ba se I n st a n ce s D e vot e d t o a Sin gle Applica t ion I f you answered " No" t o any of t he condit ions in Table 1.1, t hen your schem as probably belong in separat e dat abase inst ances, even if t hey share dat a.

1 .5 Opt ion s for D ist r ibu t e d D a t a Oracle provides several m et hods for accessing dat a t hat is dist ribut ed am ong t wo or m ore dat abase inst ances. All of t hese m et hods provide locat ion t ransparency , which m eans t hat users and applicat ions can m anipulat e dat a as t hough it were all in one single dat abase inst ance. These various m et hods are sum m arized here and are described in det ail t hroughout t his book.

1 .5 .1 Ex por t / I m por t The Oracle export and im port ut ilit ies ( illust rat ed in Figure 1.4) are t he m ost prim it ive m et hod of sharing dat a am ong dat abases and are also used as part of a backup and recovery st rat egy. Export ( exp) creat es a file t hat is essent ially a set of SQL st at em ent s t hat invoke t he DDL ( Dat a Descript ion Language) and DML ( Dat a Manipulat ion Language) required t o creat e obj ect s and insert dat a. I m port ( im p) is t he ut ilit y t hat reads t his file and execut es t he SQL st at em ent s t o re- creat e t he obj ect s and populat e t ables. A full dat abase export creat es a file t hat you can use t o re- creat e t he ent ire dat abase.

Figu r e 1 .4 . Ex por t / im por t

Unlike any of t he ot her opt ions, export and im port are st at ic. An export file cont ains t he dat a from t he t im e of t he export and cannot be updat ed. I n fact , an export file

23

Oracle Distributed Systems could easily be out of dat e before t he export j ob is finished. I n addit ion, you m ust specify t he export opt ion CONSI STENT= Y in order for all of t he dat a in t he export file t o be consist ent as of a single point in t im e. Export s are only one part of a com prehensive backup st rat egy.

1 .5 .2 D a t a ba se Lin k s Dat abase links are t he invisible glue t hat m akes locat ion t ransparency possible. I n m ore t echnical t erm s, a dat abase link defines a connect ion from one dat abase inst ance t o anot her, and t his definit ion is st ored in t he Oracle dat a dict ionary. Since dat abase link connect ions log in t o a norm al account in t he rem ot e dat abase inst ance, you have com plet e cont rol over it s privileges and quot as. Used in conj unct ion wit h synonym s, dat abase links ( shown in Figure 1.5) can m ake rem ot e obj ect s appear t o be local as far as applicat ions and users are concerned.

Figu r e 1 .5 . D a t a ba se lin k s

I f your invent ory applicat ion at a m anufact uring sit e needs t o reference t he VENDORS t able at headquart ers, you could provide locat ion t ransparency wit h t he following t hree SQL st at em ent s: CREATE PUBLIC DATABASE LINK D8CA.BIGWHEEL.COM USING 'hqaccounting.bigwheel.com' CREATE PUBLIC SYNONYM vendors FOR [email protected] GRANT SELECT ON vendors TO inventory_reader Since t he CREATE DATABASE LI NK st at em ent in t his exam ple creat es a PUBLI C link wit hout specifying an account t o connect t o in t he D8CA.BI GWHEEL.COM dat abase, t his part icular im plem ent at ion assum es t hat every applicat ion user in t he invent ory dat abase has an account in t he rem ot e dat abase wit h t he sam e password and wit h

24

Oracle Distributed Systems privileges t o see t he VENDORS t able. I f t he rem ot e dat abase is unavailable, t he VENDORS t able also will be unavailable. Of course, t here are several ways t o provide locat ion t ransparency; t hese are described in great er det ail lat er in t his book.

1 .5 .3 Re a d- On ly Sn a psh ot s I f you have an applicat ion t hat cannot risk a dependency on t he availabilit y of a rem ot e dat abase, you could use a read- only snapshot ( shown in Figure 1.6) . A readonly snapshot is essent ially a local t able whose dat a is refreshed at specified int ervals by perform ing a query against one or m ore rem ot e t ables. The invent ory applicat ion could creat e t he sam e funct ionalit y as t he dat abase link described in t he previous sect ion by following t hese st eps: CREATE PUBLIC DATABASE LINK D8CA.BIGWHEEL.COM USING 'hqaccounting.bigwheel.com' CREATE SNAPSHOT vendors REFRESH COMPLETE START WITH SYSDATE NEXT TRUNC(sysdate + 1) + 10/1440 AS SELECT vendor_id, company_name FROM [email protected] CREATE PUBLIC SYNONYM vendors FOR vendors GRANT SELECT ON vendors TO inventory_reader This snapshot is populat ed when t he CREATE SNAPSHOT st at em ent execut es, and is t hen refreshed every day from t hat point on at 10 m inut es aft er m idnight . Again, t his is j ust one exam ple of how t he t echnique could be im plem ent ed; t he det ails com e lat er. Snapshot s use t he Oracle built - in package DBMS_JOB t o schedule refreshes and require t he I NI T.ORA param et er JOB_QUEUE_PROCESSES t o be great er t han zero.

25

Oracle Distributed Systems

Figu r e 1 .6 . Re a d- on ly sn a psh ot

The benefit of read- only snapshot s over dat abase links and public synonym s is t hat t he snapshot is available even when t he rem ot e sit e is not . The disadvant ages are t hat t he dat a is neit her real t im e nor updat eable.

Oracle int roduced read- only snapshot s wit h Oracle Version 7.0. The infrast ruct ure t his feat ure required has been expanded wit h each subsequent release, wit h addit ional funct ionalit y such as updat eable snapshot s and advanced replicat ion. The base com ponent s include t he j ob queue and t riggers. The feat ure set is cont inuing t o expand.

1 .5 .4 Upda t e a ble Sn a psh ot s I f your applicat ion needs t o change dat a in a snapshot and send t he changes back t o t he m ast er sit e, you can use updat eable snapshot s, shown in Figure 1.7. A t rigger on t he snapshot t able logs updat es t hat are applied at t he m ast er sit e when t he snapshot refreshes. Updat eable snapshot s require t he advanced replicat ion facilit ies. A com m on use of updat eable snapshot s is an applicat ion t hat consolidat es dat a from

26

Oracle Distributed Systems various sit es int o a single m ast er sit e. For exam ple, a bicycle com pany m ight collect sales t ransact ions from it s dist ribut ors every night , or t ravelling salespeople m ight ent er cust om er leads on t heir lapt ops and upload t his inform at ion t o t he headquart ers dat abase when t hey ret urn t o t he office.

Figu r e 1 .7 . Upda t e a ble sn a psh ot s

Two im port ant charact erist ics of updat eable snapshot s, which dist inguish t hem from m ult i- m ast er replicat ed t ables, are: • •

They updat e only t he m ast er sit e. They can be disconnect ed from t he m ast er sit e for ext ended periods.

You also can configure an updat eable snapshot such t hat t he updat es are not sent back t o t he m ast er. You can use t his configurat ion t o perform " What if " analyses against t he local dat a wit hout fear of overwrit ing t he definit ive values at t he m ast er sit e.

1 .5 .5 Adva n ce d Re plica t ion Advanced ( or m ult i- m ast er) replicat ion ( shown in Figure 1.8) is t he m ost powerful of t he replicat ion opt ions. You can use it t o m aint ain a t able at num erous sit es, wit h

27

Oracle Distributed Systems updat es at any one locat ion being applied at all t he ot her locat ions. There is no single " m ast er" t able, alt hough t here is a m ast er definit ion sit e , from which schem a m aint enance m ust be perform ed. Unlike t he sit uat ion wit h snapshot s, you can configure a m ult i- m ast er environm ent t o provide real- t im e dat a; t his t echnique is known as synchronous replicat ion . I f you use asynchronous replicat ion ( by far t he m ore com m on im plem ent at ion) , updat es t o a t able are placed in t he deferred queue and pushed t o ot her part icipat ing sit es at user- defined int ervals.

Figu r e 1 .8 . M u lt i- m a st e r r e plica t ion

Since updat es can occur at several locat ions, t hese updat es can conflict wit h one anot her. Oracle provides a num ber of built - in m et hods t o assist in resolving t hese conflict s, such as Lat est Tim est am p and Sit e Priorit y, but t hese t echniques m ust be select ed carefully t o guarant ee t hat dat a always converges. Conflict resolut ion, described in det ail in Chapt er 15, is usually t he biggest challenge t o creat ing and m aint aining a successful im plem ent at ion. Advanced replicat ion also has som e significant lim it at ions: • • •

No support for sequences No support for LONG or LONG RAW or HHCODE dat a, alt hough Oracle8 support s replicat ion of binary large obj ect s ( BLOBs) and charact er large obj ect s ( CLOBs) Not recom m ended for applicat ions perform ing m assive updat es ( i.e., updat es t o t ens of t housands of rows per hour)

28

Oracle Distributed Systems

1 .5 .6 Pr oce du r a l Re plica t ion Procedural replicat ion ( shown in Figure 1.9) is t he preferred way t o perform t he m assive updat es t hat are not recom m ended wit h advanced replicat ion. I nst ead of queuing up row- level changes and sending t hem t o t he ot her dat abase inst ances, procedural replicat ion queues calls t o procedures and sends t hem t o t he ot her part icipant s. I f, for exam ple, you want ed t o m ark up t he prices of all your product s by five percent , you could replicat e t he procedure call UPDATE_PRI CES( pct _increase = > 5) . The procedure will execut e at every sit e wit h t he sam e param et ers.

Figu r e 1 .9 . Pr oce du r a l r e plica t ion

Oracle does not provide any conflict handlers t hat work in conj unct ion wit h procedural replicat ion, so any rout ines t hat you want t o use in t his way m ust account for conflict s. I n t he price increase exam ple, suppose t hat a price for one it em had been changed at a rem ot e sit e, and t he change had not yet propagat ed t o t he sit e init iat ing t he UPDATE_PRI CES call. The dat a would not converge t o t he sam e values at bot h sit es. Table 1.2 sum m arizes t he kinds of conflict s t hat m ay occur wit h procedural replicat ion.

Table 1.2. Potential Conflicts with Procedural Replication Time

Activity

CA Price NY Price

12: 00 Sit es agree

$100

$100

12: 05 CA calls UPDATE_PRI CES( pct _increase = > 5)

$105

$100

29

Oracle Distributed Systems

12: 10 NY sit e updat es price t o $120 before procedure replicat es

$105

$120

12: 15 Procedure call replicat es t o NY sit e

$105

$126

12: 20 Updat e from NY at 12: 10 arrives at CA sit e

$120

$126

I t is safest t o perform procedural replicat ion during periods of low or no act ivit y.

1 .6 Pe r ils of D ist r ibu t e d D a t a ba se s Nobody ever said t hat t he adm inist rat ion of dist ribut ed dat abases is easy; it 's not . For one t hing, it can be difficult t o keep t rack of who needs what sort of access t o a given dat abase inst ance, and what access needs t o be available from it t o ot her inst ances. I f users are experiencing difficult ies or applicat ions are unable t o perform , how do you know which dat abase is causing t he problem ? When you creat e a new user, what dat abase inst ances should have t he account ? What is USER_A really seeing when he references t he VENDORS t able? None of t hese difficult ies exist in a st andalone syst em . Som e of t he m ore significant perils are sum m arized here and are discussed in det ail in t he chapt ers t hat follow.

1 .6 .1 Se cu r it y Didn't t his t opic appear under t he " Benefit s" sect ion, t oo? Yes, because t here are t wo sides t o t he securit y st ory. Because it can be difficult t o know and t o cont rol who is com ing int o a dat abase via a dat abase link, t he account s t o which dat abase links connect should be given no m ore access right s t han absolut ely necessary. Sim ilarly, t he CREATE PUBLI C DATABASE LI NK syst em privilege should be grant ed sparingly because whoever has it can effect ively creat e a public doorway int o any syst em t o which she has access. I f you use operat ing syst em validat ed ( OPS$) account s, be ext rem ely careful of using t hem in t he CONNECT clause of dat abase links. Be aware t hat holes t o exploit do exist . I n an advanced replicat ion environm ent , securit y issues can becom e com plicat ed because t he user com m unit y can be t he sum of all users in all dat abases part icipat ing in replicat ion. The m aint enance of account s in and of it self can becom e a full- t im e j ob. Oracle8 alleviat es t his chore som ewhat , but you will need t o decide if replicat ed t ransact ions should be perform ed at rem ot e sit es by t he original user or by a generic replicat ion account . I t is possible t o configure an ext rem ely well cont rolled and robust dist ribut ed environm ent , but it t akes care and planning as I 'll describe in Part I I of t his book.

1 .6 .2 D a t a Con sist e n cy I f you are using m ult i- m ast er replicat ion or procedural replicat ion or if you have writ t en your own code t o perform DML on rem ot e t ables, one of your m ost form idable t asks will be t o guarant ee t hat dat a converges. This responsibilit y is shared am ong designers, developers, and DBAs ( who should be coordinat ing t heir effort s) . Designers m ust consider pot ent ial conflict s in t heir archit ect ure; developers m ust code so t hat conflict s are addressed; and DBAs m ust resolve t he unresolved conflict s. I n general, t he design and realizat ion of a replicat ed syst em necessit at es

30

Oracle Distributed Systems t he solut ion of far m ore problem s t han does a st andalone syst em , and t he bulk of t hese problem s concern dat a convergence.

1 .6 .3 Tr a n sa ct ion M a n a ge m e n t Do you want t o updat e 15,000 records in t he VENDORS t able t o reflect an area code change? Well, if t hat t ransact ion needs t o be replicat ed t o five ot her sit es, you'd bet t er t hink t wice about it because it 's going t o queue up 15,000 × 5 = 75,000 t ransact ions across your replicat ed environm ent . Do you want t o use procedural replicat ion t o do it t onight at m idnight California t im e? What about your sit e in Hong Kong where users are at work and updat ing t he t able? The point is t hat any bat ch updat es in a replicat ed environm ent m ust be carefully coordinat ed wit h all sit es in order t o avoid m assive conflict s and logj am s. The init ial load and dist ribut ion of dat a am ong sit es also requires coordinat ion. For exam ple, you m ight want t o lock users out of all inst ances unt il you can guarant ee t hat t he dat a is ident ical everywhere.

1 .6 .4 M on it or in g The addit ional workload a dist ribut ed environm ent dem ands of t he DBA can be considerable. I n addit ion t o t he norm al DBA responsibilit ies such as m onit oring space ut ilizat ion and ext ent allocat ion, t he DBA m ust m onit or obj ect s such as snapshot logs, j ob queues, t ransact ion queues, and error queues. I f left unresolved, problem s in a dist ribut ed environm ent can becom e so difficult t o solve t hat it is easier t o reload dat a from scrat ch t han t ry t o resolve specific errors. For t hat reason, m ost people consider alert m echanism s t o be essent ial in a replicat ed environm ent . For exam ple, if unresolved conflict s put ent ries int o t he error queue ( deferror ) , t he DBA should be not ified as soon as possible. You will find ut ilit ies for t his sort of aut om at ed not ificat ion in Appendix B, of t his book .

1 .6 .5 Re cove r y I f a dat abase t hat is part of a dist ribut ed environm ent fails, t he recovery process m ust ensure not only t he com plet e rest orat ion of t he local dat a but also t he rest orat ion of dist ribut ed dat a, such as snapshot s and deferred t ransact ions. I t m ay be necessary t o refresh snapshot s at rem ot e sit es, t o requeue deferred t ransact ions, and so on. The point is t hat t he recovery of t he local syst em does not necessarily m ean t hat t he overall dist ribut ed dat abase is recovered.

1 .6 .6 Pe r for m a n ce Several fact ors can affect perform ance in a dist ribut ed dat abase. I f t he applicat ion references dat a over a dat abase link, t he perform ance of t he net work will have a direct bearing on perform ance. Replicat ion com ponent s t hat ut ilize st ore- and- forward t echniques, such as snapshot s and m ult i- m ast er replicat ion, also exact t heir t oll on overall syst em perform ance. I f, for exam ple, a snapshot m ast er has a snapshot log, all DML on t hat t able will cause a row- level t rigger t o fire t hat insert s records int o t he snapshot log. Sim ilarly, DML against a replicat ed t able will eit her put ent ries int o t he

31

Oracle Distributed Systems deft ran queue ( in t he case of asynchronous replicat ion) or require t he successful delivery of every t ransact ion t o rem ot e sit es before com plet ing ( in t he case of synchronous replicat ion) . The st oring and forwarding of t ransact ions will im pact overall syst em perform ance, and you should t ake t his im pact int o considerat ion when specifying hardware requirem ent s. I n addit ion, act ivit ies such as snapshot refreshes and applicat ion of pushed t ransact ions at dest inat ion sit es im pact perform ance. Oracle has t aken great st eps t o m inim ize t he im pact of dat a dist ribut ion, but it st ill is a fact or t o consider.

1 .7 D iffe r e n ce s Be t w e e n Or a cle 7 a n d Or a cle 8 Oracle has added a wide variet y of capabilit ies int o t he Oracle8 server. Som e of t he m ore significant enhancem ent s relevant t o dist ribut ed dat abases are highlight ed here. Global users and global roles Oracle8 provides a user m anagem ent schem e t hat support s m aint enance of users and roles across m ult iple dat abase inst ances. I nst ead of having t o visit every inst ance t o grant privileges, creat e users, and so on, you can define users and roles in such a way t hat changes from a cent ral locat ion t ake effect everywhere. Syst em securit y m odel The m anagem ent of users in an advanced replicat ion environm ent is sim plified t rem endously in Oracle8, wit h t he int roduct ion of propagat or and receiver account s. I nst ead of having t o creat e a user in all inst ances part icipat ing in t he replicat ion and having t o creat e and verify privat e dat abase links for each user, you can designat e one account t o queue DML and one account t o apply DML. Parallel propagat ion Oracle8 is able t o push replicat ed t ransact ions eit her in parallel or serially. The replicat ion opt ion can det erm ine which t ransact ions are independent of one anot her so t hat t ransact ional consist ency is preserved. The net result is a significant im provem ent in t hroughput . Reduced dat a propagat ion Wit h Oracle8 you can om it colum ns in a t able from replicat ion. What t his m eans is t hat t he replicat ion facilit y does not check t he before and aft er values of t he colum ns t hat you so designat e. Since t hese colum ns are not replicat ed, less dat a is t ransm it t ed, and less t im e is spent checking for conflict s. Snapshot regist rat ion at m ast er sit es

32

Oracle Distributed Systems When you creat e a snapshot in Oracle8, it is aut om at ically regist ered at t he m ast er sit e, wit h relevant inform at ion st ored in t he DBA_REGI STERED_SNAPSHOTS dat a dict ionary view. This regist rat ion occurs regardless of whet her t he m ast er t able has a snapshot log on it , but if t here is a snapshot log, you can query DBA_REGI STERED_SNAPSHOTS and DBA_SNAPSHOTS t o obt ain inform at ion about t he lat est refreshes, and so on, as shown in t he following: SELECT r.owner, r.name, r.snapshot_site, l.current_snapshots FROM dba_registered_snapshots r, dba_snapshot_logs l WHERE r.snapshot_id = l.snapshot_id(+) Deferred const raint validat ion Oracle8 support s deferred const raint checking, which m eans t hat you can now creat e uniqueness and int egrit y const raint s on snapshot t ables. Oracle enforces deferred const raint s only aft er refreshes are com plet e, not during t he act ual snapshot refresh, during which const raint s are not necessarily respect ed. You also can use deferred const raint s during im port s so t hat records in parent t ables can be im ported aft er child t ables wit hout violat ing foreign key const raint s. Fine- grained quiesce Alt hough Oracle7 provides an API t o quiesce replicat ion ( i.e., suspend DML act ivit y against replicat ed obj ect s) at t he group level, it doesn't act ually work, even in t he lat est Version 7.3 releases. Oracle8 correct s t his problem , m aking it possible t o adm inist er m ult iple replicat ion groups com plet ely independent ly. I nt ernalized t riggers The t riggers required t o support replicat ion are int ernalized in Oracle8, which m eans t hat t hey are com piled C code as opposed t o PL/ SQL. The enhancem ent result s in im proved perform ance and easier m aint enance.

33

Oracle Distributed Systems

34

Oracle Distributed Systems

Ch a pt e r 2 . SQL* N e t a n d N e t 8 SQL* Net and Net 8 are t he net work prot ocols Oracle supplies t o support com m unicat ion wit h an Oracle dat abase over a net work. Net 8 is t he new m oniker for SQL* Net which Oracle has int roduced wit h Oracle8.

2 .1 Pr ot ocol Ove r vie w Even if a process is running on t he sam e m achine as t he dat abase inst ance, it requires SQL* Net or Net 8 t o est ablish it s dat abase connect ion and t o perform operat ions such as record fet ching. SQL* Net or Net 8 is required for com m unicat ion bet ween servers and client s and bet ween servers and ot her servers. This soft ware m akes t he ent ire net worked dat abase environm ent appear as a single m achine even t hough m ult iple m achines and net work prot ocols m ay be involved. Before delving int o t he archit ect ure and m anagem ent of SQL* Net / Net 8, I 'll provide an int roduct ion t o t his soft ware's role in a dist ribut ed dat abase environm ent .

2 .1 .1 D ist r ibu t e d Pr oce ssin g Alt hough dat abase t ransact ions are perform ed on t he dat abase server, t hey are usually not init iat ed t here. A t ransact ion m ay originat e from a m ouseclick on a web page or a bar code scan at a grocery st ore or a but t on pushed on a Touch- Tone phone—t o nam e a few exam ples. SQL* Net / Net 8 coordinat es t he com m unicat ions associat ed wit h dist ribut ed t ransact ions by est ablishing connect ions bet ween client s and servers ( or servers and servers) , t ransm it t ing dat a back and fort h, and disconnect ing cleanly. SQL* Net / Net 8 is also responsible for t ranslat ing any differences in charact er set s or dat a represent at ions t hat m ay exist at t he operat ing syst em level. SQL* Net / Net 8 does not , however, perform t asks such as convert ing a bar code or key t one int o it s respect ive ASCI I represent at ion; t hat is t he applicat ion's responsibilit y. SQL* Net / Net 8 est ablishes a connect ion from a client t o a server or a server t o a server by passing t he connect ion request t o t he Transparent Net work Subst rat e ( TNS) . TNS, in t urn, det erm ines which server should handle t he request and sends t he request using t he corresponding net work prot ocol.

2 .1 .2 N e t w or k Tr a n spa r e n cy a n d N e t w or k I n de pe n de n ce The det ails of t he SQL* Net / Net 8 configurat ion and net work prot ocols are com plet ely invisible t o dat abase applicat ions. Oracle provides net work drivers ( called prot ocol adapt ers) t hat allow SQL* Net / Net 8 t o funct ion wit h all net work prot ocols. These drivers funct ion on any m edia or t opology t hat support s t he prot ocol. For exam ple, t he TCP/ I P SQL* Net / Net 8 prot ocol adapt er works on Et hernet , t oken ring, or any ot her m edia and t opology on which TCP/ I P runs.

35

Oracle Distributed Systems

2 .1 .3 M u lt iple N e t w or k Pr ot ocol I n t e r ope r a bilit y Besides facilit at ing com m unicat ion bet ween m achines t hat are connect ed wit h t he sam e net work prot ocol, SQL* Net / Net 8 also support s com m unicat ion bet ween m achines running different net work prot ocols. Oracle accom plishes t his wit h t he Mult iProt ocol I nt erchange in Oracle7 and connect ion m anager ( CMAN) in Oracle8. A com put er t hat runs bot h net work prot ocols provides t he link bet ween net work com m unit ies, and t he Mult iProt ocol I nt erchange soft ware runs on t his m achine t o t ranslat e TNS com m unicat ions from one prot ocol t o t he ot her, as illust rat ed in Figure 2.1.

Figu r e 2 .1 . D ispa r a t e n e t w or k com m u n it ie s lin k e d w it h t h e M u lt iPr ot ocol I n t e r ch a n ge

2 .1 .4 Or a cle N a m e s Oracle Nam es is a product t hat st ores connect ion inform at ion about all dat abases in a dist ribut ed environm ent in a single locat ion. Any t im e an applicat ion issues a connect ion request , it consult s t he Oracle Nam es reposit ory t o det erm ine t he locat ion of t he dat abase server. Oracle Nam es is prim arily an adm inist rat ive aid t hat m akes t he m aint enance of t his inform at ion easier. I t s use is not required; t he alt ernat ive is t o provide local t nsnam es.ora files on every client m achine.

2 .2 Ar ch it e ct u r e Oracle supplies t hree key com ponent s t hat int eract t o locat e services, est ablish connect ions, t ransport dat a, and handle except ions. They are:

36

Oracle Distributed Systems • • •

SQL* Net / Net 8 Transparent Net work Subst rat e ( TNS) Oracle List ener

While t he int eract ion am ong t hese product s does not generally require int ervent ion beyond t he init ial inst allat ion, som e cust om izat ions are oft en beneficial in an environm ent t hat is m aking heavy use of snapshot s, sym m et ric replicat ion, or ot her dist ribut ed funct ionalit y.

2 .2 .1 SQL* N e t / N e t 8 , TN S, a n d t h e OSI Re fe r e n ce M ode l Bot h TNS and t he Oracle prot ocol adapt ers m ay be described by t he seven- layer Open Syst em s I nt erconnect ion ( OSI ) m odel, as seen in Table 2.1.

Table 2.1. TNS and Oracle Protocol Adapters in the OSI Model Client-Side Stack Client applicat ion

Layer 7 ( applicat ion)

Server-Side Stack Oracle server

SQL* Net / Net 8

6 ( present at ion)

SQL* Net / Net 8

TNS

5 ( session)

TNS

Oracle prot ocol adapt er

4 ( t ransport )

Oracle prot ocol adapt er

3 ( net work) 2 ( dat a link) 1 ( physical) The OSI m odel uses t he concept of a st ack t o describe t he int eract ion of net worked m achines. Each layer of t he st ack com m unicat es wit h it s peer on a rem ot e m achine and wit h adj acent layers on t he local m achine, where dat a is passed down from t he applicat ion t hrough t he various layers and finally passed t o t he rem ot e m achine at t he physical layer. There are different Oracle net working com ponent s associat ed wit h layers 4, 5, 6, and 7. The lower layers of t he st ack are relat ed t o rout ing and physical charact erist ics of t he net work; t hey are not specifically relevant t o t he dat a being t ransm it t ed.

2 .2 .1 .1 Applica t ion la ye r The applicat ion layer is what t he user sees and int eract s wit h. I t is a user int erface, such as a web browser or a Form s applicat ion or even a bar code scanner. The applicat ion init iat es request s on behalf of t he user, such as connect ion request s, queries, and updat es. All applicat ions t hat int eract wit h an Oracle dat abase do so t hrough t he OCI ( Oracle Call I nt erface) . This code cont ains API calls t o do t he following: • • •

Connect and disconnect from t he dat abase server Parse SQL st at em ent s Open cursors

37

Oracle Distributed Systems • • • • • •

Bind variables from t he applicat ion t o server m em ory Describe fields in t ables and views Execut e SQL st at em ent s Fet ch rows of dat a Close cursors Handle except ions

Wit hin t he applicat ion layer, OCI calls are m ade at a layer known as t he User Program m at ic I nt erface ( UPI ) on t he client side and t he Oracle Program m at ic I nt erface ( OPI ) on t he server side.

Applicat ions t hat use st ored PL/ SQL procedures and packages can significant ly reduce t he volum e of dat a t hat is sent over t he net work because t here are fewer net work round t rips bet ween t he client and t he server ( i.e., t he client does not need t o ship SQL st at em ent s t o t he server if t he SQL st at em ent s reside in a st ored procedure) .

2 .2 .1 .2 Pr e se nt a t ion la ye r Two- Task Com m on is t he SQL* Net / Net 8 code t hat resides on t he present at ion layer and is used by t he OCI . I f and when necessary, t his code t ranslat es bet ween charact er set s and dat a represent at ions on t he client and t he server.

2 .2 .1 .3 Se ssion la ye r Thesession layer est ablishes and t erm inat es dat abase connect ions and carries dat a and dat a request s. I t also det erm ines whet her dat a can be t ransport ed asynchronously or synchronously. The session layer is t he realm of TNS, which is layered wit hin t he session layer. TNS t ranslat es OCI m essages from t he applicat ion layer ( t he m essages have been t ranslat ed if necessary at t he present at ion layer) int o SEND m essages. Sim ilarly, it passes RECEI VE m essages up t he st ack in OCI form at . TNS exchanges dat a wit h t he Oracle prot ocol adapt er, which form at s for t he t ransport layer using st andards t hat are specific t o t he prot ocol in use. TNS also provides error and int errupt handling.

2 .2 .1 .4 Tr a n spor t , n e t w or k , da t a lin k , a n d ph ysica l la ye r s The act ivit y t hat t akes place at t hese lower levels of t he OSI st ack are specific t o t he prot ocols and m edia in use. The Oracle soft ware residing at t he session layer shields us from any involvem ent at t his level.

38

Oracle Distributed Systems

SQL* N e t a n d W AN s As you can im agine, t he t ranslat ions t hat occur bet ween and wit hin various levels of t he OSI st ack have an im pact on perform ance, and when a wide area net work ( WAN) is involved, t he im pact can be significant . SQL* Net and TNS are essent ially layered prot ocols, which in t urn are layered on a net work prot ocol. Every fram e of every prot ocol layer has a header port ion and a dat a port ion. The m ore layers, t he m ore headers, and t he m ore headers, t he less dat a. Consider t he overhead encount ered t ranslat ing a single 1514- byt e Et hernet fram e from Et hernet t o I P t o TCP t o TNS: •

• • •

Et hernet fram e: 14 byt es header, 1500 byt es dat a. ( This is an I P fram e.) I P fram e: 20 byt es header, 1480 byt es dat a. ( This is an I P fram e.) TCP fram e: 20 byt es header, 1460 byt es dat a. ( This is an I P fram e.) TNS fram e: 10 byt es header, 1450 byt es dat a. Not e t hat t he TNS fram e size is configurable wit h t he SDU param et er in t he configurat ion files list ener.ora, t nsnam es.ora, and, in t he case of t he m ult i- t hreaded server ( MTS) in Oracle8, I NI T.ORA.

Here we see t hat 64 byt es ( approxim at ely four percent ) of t he Et hernet fram e was lost t o overhead. I n t est s we ran wit h a Form s applicat ion on a PC connect ed t o a Unix dat abase server, we saw an average of only 60 byt es of act ual dat a per fram e. And for each SQL* Net packet sent t o a dest inat ion, an acknowledgm ent SQL* Net packet m ust com e back. The acknowledgm ent m essages can cause a severe perform ance degradat ion on a WAN because of m essage lat ency and a pot ent ially high num ber of raindrop m essages.

2 .2 .2 SQL* N e t / N e t 8 Ele m e n t s SQL* Net / Net 8 consist s of t hree com ponent s: The client The client is t he applicat ion or soft ware t hat init iat es t he connect ion. I t m ay be an end user applicat ion, such as a web page, or it m ay be anot her Oracle server. The server This is t he soft ware t o which t he client connect s; it m ay be an Oracle server or an ext ernal procedure. The list ener The list ener ( also known as t he TNS list ener or t he SQL* Net list ener) creat es list en end point s on t he m achine housing t he Oracle server or ext ernal

39

Oracle Distributed Systems procedure. The addresses of t hese end point s are est ablished in advance and published in t he t nsnam es.ora file, st ored in an Oracle Nam es server ( t he locat ion of which is published in t he nam es.ora file) or st ored in som e ot her nam e server.

2 .2 .3 Con n e ct ion Sce n a r ios There are t wo scenarios for which SQL* Net est ablishes a connect ion t o a dat abase: •

•

When a user or program specifically init iat es a connect ion ( e.g., a Form s login screen) . When one server needs t o com m unicat e wit h anot her, as t he result of eit her an explicit or im plicit request . An exam ple of t his t ype of connect ion is an applicat ion t hat accesses a t able over a dat abase link in a dist ribut ed dat abase environm ent .

I n bot h cases, t he init iat or sends a connect ion request t o a predefined address on which a list eneris accept ing request s. The list ener passes t he request t o t he appropriat e server.

2 .2 .4 Be qu e a t h e d a n d Re dir e ct e d Con n e ct ion s The TNS list ener est ablishes all connect ions by perform ing eit her a bequeat h or a redirect . A bequeat hed connect ion is one t hat t he list ener passes t o t he Oracle server direct ly. I n t he case of a redirect , t he list ener redirect s t he client t o est ablish a connect ion t o a different address in order t o connect t o t he t arget ed server. You have cont rol over whet her t he TNS list ener perform s bequeat hed or redirect ed connect ions. Table 2.2 com pares t he t wo t ypes of connect ions.

Table 2.2. Bequeathed Versus Redirected Connections Connection Type

Operating System and Protocol Requirements

Operat ing syst em can pass a connect ion end point t o anot her process during creat ion of Bequeat hed connect ion process. Prot ocol m ust allow connect ion t o be given t o anot her process. Redirect ed

Examples Most Oracle server dedicat ed processes are bequeat hed.

All Oracle m ult iNo operat ing syst em requirem ent s. Prot ocol t hreaded server ( MTS) m ust allow process t o perform a wildcard list en processes are or else use configurat ion files. redirect ed.

I f an operat ing syst em and net work prot ocol are capable of handing a list ener end point from t he list ener t o t he server during t he creat ion of an operat ing syst em process, t hen a bequeat hed connect ion m ay be used.

2 .2 .4 .1 H ow a be que a t he d conne ct ion is e st a blish e d on Un ix

40

Oracle Distributed Systems I f t he TNS list ener and t he Oracle server have a parent - child relat ionship, t hen t he list ener can est ablish bequeat hed connect ions. The series of event s is as follows: 1. The TNS list ener is st art ed, and it list ens on an address it obt ained from t he list ener.ora file or an appropriat e default . 2. The client sends a connect ion request t o t he TNS list ener's address. The client det erm ines t his address from t he t nsnam es.ora file, t he Oracle Nam es server, or anot her nam e server. 3. The client and TNS list ener perform a handshake, during which t he client supplies t he connect st ring. The TNS list ener accept s or rej ect s t he connect ion request based on t he inform at ion supplied. I f t he connect ion is rej ect ed, it sends a REFUSE t o t he client and cont inues wait ing for m ore connect ion request s. 4. I f t he TNS list ener accept s t he connect ion request , it spawns a new operat ing syst em process which inherit s t he TNS list ener's open connect ions. 5. The TNS list ener closes it s open connect ion, and cont inues wait ing for m ore connect ion request s. 6. The new operat ing syst em process creat ed in St ep 4 uses t he connect ion it inherit ed t o com m unicat e wit h t he client .

2 .2 .4 .2 H ow a r e dir e ct e d con n e ct ion is e st a blish e d I f t he TNS list ener and t he Oracle server do not have a parent - child relat ionship, t hen t he TNS list ener will use redirect ed connect ions. This is t he m et hod used by t he m ult i- t hreaded server and from any configurat ion in which t he TNS list ener is on a different m achine from t he Oracle server. The TNS list ener also uses redirect ed connect ions when t he prot ocol and/ or operat ing syst em in use cannot pass connect ion end point s bet ween processes. The first t hree st eps of est ablishing a redirect ed connect ion are t he sam e as for est ablishing a bequeat hed connect ion. I f t he TNS list ener accept s t he connect ion request , t he following event s com plet e t he request : 1. The TNS list ener eit her creat es a new operat ing syst em process or ( in t he case of a m ult i- t hreaded server configurat ion) com m unicat es wit h an exist ing operat ing syst em process ( t he MTS dispat cher) . This operat ing syst em process est ablishes a list ening end point of it s own, and t he TNS list ener is inform ed of t he end point 's address. This end point is usually a wildcard list en, which m eans t hat t he operat ing syst em process t ells t he underlying prot ocol st ack t hat it does not care what address is used. Most operat ing syst em s t hen choose a list ening address t hat is not in use and assign it t o t he process. 2. The TNS list ener com m unicat es t he new list ening address t o t he client . This st ep is known as t he REDI RECT. 3. The client disconnect s from t he TNS list ener, issues a new connect ion request t o t he address provided in t he redirect m essage, and est ablishes a connect ion. Because redirect ed connect ions generally do not have t he overhead of st art ing a new process, t hese connect ions are generally fast er t o est ablish, and t he m et hodology is port able across m ore operat ing syst em s and prot ocols.

41

Oracle Distributed Systems

Because t he TNS list ener's role is only t o process new connect ion request s, you can st op and st art it at any t im e wit hout affect ing connect ions t hat are already est ablished.

2 .2 .5 Ex a m ple : Con n e ct in g t o a M u lt i- Th r e a de d Se r ve r The m ult i- t hreaded server allows you t o service m any client connect ions wit h a relat ively sm all num ber of server processes, t hereby reducing m em ory and processing requirem ent s. This t echnique is well suit ed for applicat ions t hat m ust support a high num ber of connect ions t hat do not t ransm it a high volum e of dat a. A Form s- based applicat ion would be a good candidat e for MTS connect ions. Oracle export / im port ut ilit ies, on t he ot her hand, are exam ples of applicat ions t hat should use dedicat ed server processes. I n order t o use t he m ult i- t hreaded server opt ion wit h a dat abase inst ance, you m ust set param et ers in t he inst ance's I NI T.ORA file, as out lined in Table 2.3.

Table 2.3. Multi-Threaded Server INIT.ORA Parameters Parameter Name

Description

MTS_DI SPATCHERS

Used t o configure a group of dispat chers. This is t he only required param et er in Oracle8i.

MTS_LI STENER_ADDRESS

The address on which t he list ener is t o list en; specify at least one address per prot ocol. Obsolet e in Oracle8.

MTS_MAX_DI SPATCHERS

The m axim um num ber of dispat cher processes t hat can run sim ult aneously. Opt ional.

MTS_MAX_SERVERS

The m axim um num ber of shared server processes t hat can run sim ult aneously. Opt ional.

MTS_MULTI PLE_LI STENERS

I f TRUE, synt ax of MTS_LI STENER_ADDRESS can support m ult iple prot ocols. Obsolet e in Oracle8.

MTS_RATE_LOG_SI ZE

The sam ple size used t o calculat e dispat cher st at ist ics. Oracle8 only. Deprecat ed in Oracle8i.

MTS_RATE_SCALE

The scale, in hundredt hs of a second, wit h which dispat cher st at ist ics are calculat ed. Oracle8 only. Deprecat ed in Oracle8i.

MTS_SERVERS

The init ial num ber of server processes. Opt ional in Oracle8i.

MTS_SERVI CE

The nam e of t he service t o which t he dispat cher connect s. Typically t he ORACLE_SI D default s t o DB_NAME. Deprecat ed in Oracle8i.

When a m ult i- t hreaded server Oracle inst ance and list ener st art up, t he following event s t ypically t ake place:

42

Oracle Distributed Systems 1. The TNS list ener begins list ening on t he addresses configured in t he list ener.ora file. 2. The Oracle m ult i- t hreaded server background processes ( dispat chers and servers) st art wit h t he dat abase inst ance, using t he configurat ion specified in t he I NI T.ORA file. Each dispat cher list ens on it s prot ocol on t he specified ( or dynam ically generat ed) address. 3. Each dispat cher inform s t he TNS list ener of t he wildcard address it is list ening on. I n Oracle7, each dispat cher connect s t o each list ener. I n Oracle8, t he PMON background process connect s t o each list ener. Alt hough you can st art t he dat abase before you st art t he TNS list ener, Oracle Corporat ion recom m ends t hat you st art t he list ener first . The reason is t hat if you st art t he Oracle inst ance first , t he dispat chers ( Oracle7) or PMON ( Oracle8) will not cont act t he list ener as described in St ep 3. I n t his case, t he dispat cher or PMON processes loop and at t em pt t o reconnect t o t he list ener every 60 seconds.

At t his point , t he m ult i- t hreaded server processes and TNS list ener are ready t o accept connect ions. The com m and:

lsnrctl services listener_name report s what dispat chers are regist ered wit h t he TNS list ener, as shown in t he following exam ple: oracle@socrates% lsnrctl services LISTENER LSNRCTL for Solaris: Version 8.0.4.0.0 - Production on 23-NOV-98 23:26:08 (c) Copyright 1997 Oracle Corporation.

All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=prodsales.bigwheel.com)) Services Summary... PSLS has 9 service handler(s) DEDICATED SERVER established:1401 refused:0 LOCAL SERVER DISPATCHER established:174381 refused:0 current:28 max:254 state:ready D000 (ADDRESS=(PROTOCOL=tcp)(DEV=21)(HOST=199.172.152.166)(PORT=63409)) DISPATCHER established:211990 refused:0 current:28 max:254 state:ready D001 (ADDRESS=(PROTOCOL=tcp)(DEV=21)(HOST=199.172.152.166)(PORT=63415)) DISPATCHER established:220539 refused:0 current:28 max:254 state:ready D004 (ADDRESS=(PROTOCOL=tcp)(DEV=21)(HOST=199.172.152.166)(PORT=63439))

43

Oracle Distributed Systems DISPATCHER established:179663 refused:0 current:28 max:254 state:ready D003 (ADDRESS=(PROTOCOL=tcp)(DEV=21)(HOST=199.172.152.166)(PORT=63436)) DISPATCHER established:175661 refused:0 current:28 max:254 state:ready D002 (ADDRESS=(PROTOCOL=tcp)(DEV=21)(HOST=199.172.152.166)(PORT=63428)) DISPATCHER established:184766 refused:0 current:28 max:254 state:ready D005 (ADDRESS=(PROTOCOL=tcp)(DEV=21)(HOST=199.172.152.166)(PORT=63446)) DISPATCHER established:218292 refused:0 current:27 max:254 state:ready D006 (ADDRESS=(PROTOCOL=tcp)(DEV=21)(HOST=199.172.152.166)(PORT=63455)) DISPATCHER established:204115 refused:0 current:27 max:254 state:ready D007 (ADDRESS=(PROTOCOL=tcp)(DEV=21)(HOST=199.172.152.166)(PORT=63458)) The command completed successfully The st eps for handling connect ion request s wit h t he m ult i- t hreaded server are as follows: 1. The client sends a connect ion request t o t he TNS list ener's address. The client det erm ines t his address from t he t nsnam es.ora file, t he Oracle Nam es server, or anot her nam e server. 2. The TNS list ener receives t he request and perform s t he handshake t o det erm ine whet her t he client can connect . I f t he connect ion is denied, t he TNS list ener sends a REFUSE t o t he client and cont inues list ening for ot her request s. 3. I f t he client request is accept ed, t he TNS list ener sends a REDI RECT t o t he client , inform ing it of t he address of t he dispat cher t hat is list ening on t he client 's prot ocol. 4. The client t erm inat es it s connect ion wit h t he TNS list ener and est ablishes a new connect ion wit h t he dispat cher using t he address t he TNS list ener provided. 5. The TNS list ener cont inues list ening for connect ion request s. A client can override t he m ult i- t hreaded server and use a dedicat ed server by specifying SERVER= DEDI CATED in t he connect st ring. I n addit ion, if all m ult i- t hreaded server connect ions are exhaust ed, subsequent connect ion request s will use dedicat ed servers.

2 .2 .6 Ex a m ple : Con n e ct in g t o a Pr e spa w n e d Se r ve r Pr oce ss As t he nam e suggest s, prespawned server processes are processes t hat t he TNS list ener st art s at st art up t im e. These processes can be handed off t o client s t hat are

44

Oracle Distributed Systems request ing dedicat ed processes. Prespawned processes are t ypically not used in conj unct ion wit h t he m ult i- t hreaded server. The list ener.ora file cont ains configurat ion inform at ion required t o use prespawned servers. The relevant param et ers are described in Table 2.4.

Table 2.4. listener.ora Parameters Governing Prespawned Servers Parameter Name POOL_SI ZE

Description Num ber of unused prespawned processes t o m aint ain for each prot ocol. This num ber should be bet ween 1 and PRESPAWN_MAX, inclusive.

PRESPAWN_MAX Num ber of prespawned processes t o creat e for each prot ocol. TI MEOUT

Num ber of seconds an inact ive server should wait for a new connect ion before shut t ing down. Affect s only processes t hat have carried a client connect ion.

These param et ers can be set individually for each ORACLE_SI D t he TNS list ener services. The sequence of event s for using prespawned server processes is as follows: 1. The TNS list ener st art s and list ens on t he addresses specified in list ener.ora. 2. The TNS list ener spawns POOL_SI ZE server processes for each ORACLE_SI D defined in list ener.ora. 3. Each prespawned server process perform s a wildcard list en and inform s t he TNS list ener of t he address it is using. 4. The client sends a connect ion request t o t he TNS list ener's address. The client det erm ines t his address from t he t nsnam es.ora file or from t he Oracle Nam es server. 5. The TNS list ener receives t he request , and perform s t he handshake t o det erm ine whet her t he client can connect . I f t he connect ion is denied, t he TNS list ener sends a REFUSE t o t he client and cont inues list ening for ot her request s. 6. I f t he client 's request is accept ed, t he TNS list ener sends t he client a REDI RECT m essage inform ing it of t he address of one of t he prespawned processes. Then t he TNS list ener m arks t he prespawned process as ACTI VE. 7. The client t erm inat es it s connect ion wit h t he TNS list ener and est ablishes a new connect ion wit h t he prespawned process using t he address t he TNS list ener provided. 8. I f PRESPAWN_MAX is less t han t he num ber of act ive and idle prespawned processes, t he TNS list ener spawns a new process t o replace t he one t hat t he client t ook. 9. The TNS list ener cont inues list ening for new connect ions. When PRESPAWN_MAX processes exist for t he ORACLE_SI D, t he TNS list ener st ops prespawning server processes. When a client disconnect s from one of t he prespawned processes, it is m arked as I DLE ( i.e., available) and, if m ore t han POOL_SI ZE servers are not ACTI VE, it rem ains alive for TI MEOUT seconds. I f no

45

Oracle Distributed Systems connect ion has been est ablished in t hat t im e, t he idle prespawned process t erm inat es. Prespawned connect ions are an aging t echnology t hat was prim arily int ended for use wit h operat ing syst em s on which process st art up cost s are high ( m ost not ably VMS) . I n t his day and age, t he m ult i- t hreaded server t echnology is a preferable choice.

2 .3 SQL* N e t / N e t 8 Tu n in g The m ost effect ive net work t uning you can do for SQL* Net / Net 8 is t o reduce t he num ber of round- t rip m essages bet ween t he client m achines and dat abase server. You can cont rol t his behavior in various ways, such as set t ing your applicat ion's ARRAY_SI ZE ( t he num ber of records t hat are processed wit h each fet ch) , t he size of t he session dat a unit ( SDU) , and t he use of st ored procedures. I n addit ion, scalabilit y issues can be im proved by t uning your MTS configurat ion. Net 8 int roduces addit ional m ult iplexing and connect ion pooling capabilit ies which scale t o support t ens of t housands of users.

2 .3 .1 D o You H a ve a Pr oble m ? The first st ep in addressing SQL* Net / Net 8 scalabilit y is t o recognize whet her your syst em is experiencing a perform ance degradat ion and act accordingly. I f you are using m ult i- t hreaded server, your prim ary concerns are whet her t he dispat chers are keeping up wit h t he rat e of request s and whet her t he server processes are able t o handle t he volum e of act ivit y. I f you are using prespawned servers, your concerns are whet her you have enough servers and whet her t he m achine has t he resources t o accom m odat e t heir m em ory and CPU usage. Met hods of diagnosing all of t hese sit uat ion are included here.

2 .3 .1 .1 Tuning t he m ult i- t hr e a de d se r ve r Tuning t he m ult i- t hreaded server am ount s t o configuring m ore dispat chers and adding or reducing server processes. The book Oracle Perform ance Tuning, 2nd edit ion, by Mark Gurry and Pet er Corrigan ( O'Reilly & Associat es, 1996) includes SQL script s t hat help t o diagnose m ult i- t hreaded usage. Slight ly m odified versions of t hese script s, which are useful prim arily for Oracle7, follow. To det erm ine whet her you have enough dispat cher processes t o service t he rat e of connect ion request s, you can query t he V$DI SPATCHER dynam ic dat a dict ionary view: --------------------------------------------------------------------------- Filename: busydisp.sql -- Purpose: Provides stats indicating whether the dispatcher processes -are overly taxed. -- Author: Chas. Dye ([email protected])

46

Oracle Distributed Systems -- Date: 6-Aug-1998 -------------------------------------------------------------------------column network heading "Protocol" format a40 column rate heading "Total Busy Rate|>50%=>Add Dispatchers" format 99.99 SELECT

network, 100*(sum(busy)/(sum(busy)+sum(idle))) rate FROM v$dispatcher GROUP BY network / column protocol heading "Protocol" a40 column Wait heading "Average Wait|(hundredths of seconds)" a30

format format

SELECT

network Protocol, decode( sum(totalq), 0, 'No Responses', to_char(sum(wait)/sum(totalq), 'FM9999.90')) Wait FROM v$queue q, v$dispatcher d WHERE q.type = 'DISPATCHER' AND q.paddr = d.paddr GROUP BY network / Here is sam ple out put from t his script : Total Busy Rate Protocol >50%=>Add Dispatchers ---------------------------- --------------------ipc .00 tcp .48 2 rows selected.

Protocol ---------------ipc tcp

Average Wait (hundredths of seconds) -----------------------------No Responses .00

2 rows selected. The m et rics from t he V$DI SPATCHER are cum ulat ive since t he t im e t hat t he dat abase inst ance was st art ed. I f t he workload on your dat abase varies over t im e, you should exam ine t he delt a in values from V$DI SPATCHER over a set int erval. I n Oracle8, t he dat a dict ionary view V$DI SPATCHER_RATE provides m et rics t hat reflect current ut ilizat ion rat es. I n t his case, we see t hat t he dispat chers are not overly t axed. Had we seen a Busy Rat e above approxim at ely 50% or an appreciable value for Average Wait , we would

47

Oracle Distributed Systems be advised t o add m ore dispat chers dynam ically ( as follows) or by m odifying t he I NI T.ORA file. Oracle7 synt ax: ALTER SYSTEM SET mts_dispatchers = 'tcp, 5'; Oracle8 synt ax: SQL> ALTER SYSTEM SET mts_dispatchers = '(PROTOCOL=TCP)(DISPATCHERS=5)'; Not e t hat adding dispat cher processes can lead t o excessive cont ext swit ching, which m ay degrade perform ance.

Changes in Oracle8 m ake t his t uning advice som ewhat less relevant . I n Oracle8, t he BUSY and I DLE fields in V$DI SPATCHER are cum ulat ive and t herefore do not reflect t he current st at ist ics. You m ust query V$DI SPATCHER at set int ervals and observe t he change in BUSY/ I DLE over t im e.

2 .3 .1 .2 Tuning m ult i- t hr e a de d se r ve r dispa t ch e r s in Or a cle 8 I n Oracle8, t he dynam ic dat a dict ionary view V$DI SPATCHER_RATE provides st at ist ics t hat can help t o det erm ine whet her you have an appropriat e num ber of dispat chers. The following script report s on dispat chers in an Oracle8 dat abase: --------------------------------------------------------------------------- Filename: disprate.sql -- Purpose: Queries v$dispatcher_rate. -- Author: Chas. Dye ([email protected]) -- Date: 24-Nov-1998 -------------------------------------------------------------------------col name format a8 col CUR_MSG_RATE col MAX_MSG_RATE col AVG_MSG_RATE

format 999999 format 999999 format 999999

SELECT name, CUR_MSG_RATE, MAX_MSG_RATE, AVG_MSG_RATE

48

Oracle Distributed Systems FROM / col col col col col col

v$dispatcher_rate

CUR_SVR_BYTE_PER_BUF CUR_CLT_BYTE_PER_BUF MAX_SVR_BYTE_PER_BUF MAX_CLT_BYTE_PER_BUF AVG_SVR_BYTE_PER_BUF AVG_CLT_BYTE_PER_BUF

format format format format format format

999999 999999 999999 999999 999999 999999

heading heading heading heading heading heading

"CUR|SVR|BYTE|PER|BUF" "CUR|CLT|BYTE|PER|BUF" "MAX|SVR|BYTE|PER|BUF" "MAX|CLT|BYTE|PER|BUF" "AVG|SVR|BYTE|PER|BUF" "AVG|CLT|BYTE|PER|BUF"

SELECT name, CUR_SVR_BYTE_PER_BUF, CUR_CLT_BYTE_PER_BUF, MAX_SVR_BYTE_PER_BUF, MAX_CLT_BYTE_PER_BUF, AVG_SVR_BYTE_PER_BUF, MAX_CLT_BYTE_PER_BUF FROM v$dispatcher_rate / Here is sam ple out put : SQL> @disprate NAME CUR_MSG_RATE MAX_MSG_RATE AVG_MSG_RATE -------- ------------ ------------ -----------D000 62 8000 1937 D001 233 8500 2099 D002 26 7300 1770 D003 269 7900 2836 D004 333 8100 2158 D005 274 9400 2968 D006 339 8600 2171 D007 212 8300 2372 8 rows selected.

CUR CUR MAX MAX AVG MAX SVR CLT SVR CLT SVR CLT BYTE BYTE BYTE BYTE BYTE BYTE PER PER PER PER PER PER NAME BUF BUF BUF BUF BUF BUF ------ ------ ------- ------- ------- ------- ------D000 155 973 7446 40465 14 40465 D001 263 593 6169 49080 37 49080 D002 161 1380 7709 45152 83 45152 D003 319 980 9508 50433 9 50433 D004 254 337 19246 37949 41 37949 D005 228 753 5837 43968 8 43968 D006 374 1347 44276 36661 43 36661 D007 103 119 21710 56071 21 56071 8 rows selected.

2 .3 .1 .3 Tuning m ult i- t hr e a de d se r ve r se r ve r pr oce sse s 49

Oracle Distributed Systems The ot her concern wit h m ult i- t hreaded servers is whet her t he server processes are overly busy. I f you see m any request s on t he COMMON queue ( visible in t he dynam ic dat a dict ionary via V$QUEUE) , you should consider adding m ore servers. The following script provides useful st at ist ics: --------------------------------------------------------------------------- Filename: busyq.sql -- Purpose: Provides stats indicating whether a given queue is overly -taxed in a Multi-Threaded Server environment. -If the COMMON queue is overly taxed, consider adding more -servers. -- Author: Chas. Dye ([email protected]) -- Date: 6-Aug-1998 -------------------------------------------------------------------------column type column circuit column queued column wait column totalq 999,999,999,999 column avgwait

heading heading heading heading heading

"Queue|Type" "Name" "Items|Queued" "Total|Time|Waited" "Total|Items|Processed"

heading "Average|Wait"

format format format format format

a10 a8 999,999 999,999,999

format 9,999.90

set head off set feedback off SELECT sysdate FROM dual / set head on set feedback on SELECT paddr, type, queued, wait, totalq, decode(totalq, 0, 0, wait)/decode(totalq, 0, 1, totalq) avgwait FROM v$queue / Here is sam ple out put : system@live SQL> @busyq 24-Nov-1998 00:36:30 Total Total Queue Items Time Items Average PADDR Type Queued Waited Processed Wait -------- ---------- -------- ------- ---------------- --------00 COMMON 0 0 484,422,948 .20

50

Oracle Distributed Systems 8C612E88 8C60C1D8 8C614BE8 8C614028 8C6151C8 8C608A08 8C60D958 8C610B48

DISPATCHER DISPATCHER DISPATCHER DISPATCHER DISPATCHER DISPATCHER DISPATCHER DISPATCHER

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

74,413,276 81,077,489 68,060,821 98,532,257 83,142,628 102,410,058 83,688,178 86,438,327

.04 .04 .05 .04 .04 .04 .05 .06

9 rows selected. Because t he COMMON queue does not show any it em s queued and an average wait t im e of zero, we can conclude t hat t he server allocat ion for t his syst em is adequat e. I f you see a high num ber of it em s on t he COMMON queue, and t here are no significant wait event s occurring ( such as lat ch wait s) you should consider adding m ore m ult i- t hreaded server processes ( cont rolled wit h t he I NI T.ORA param et ers MTS_SERVERS and MTS_MAX_SERVERS) .

2 .3 .1 .4 M e a su r in g m u lt i- t h r e a de d se r ve r se r ve r a ct ivit y Finally, we also can check t he volum e of act ivit y of t he individual connect ions t hat are associat ed wit h a given server. The query is as follows: --------------------------------------------------------------------------- Filename: busycirc.sql -- Purpose: Provides stats indicating whether a given circuit is -overly taxed in a Multi-Threaded Server environment. -- Author: Chas. Dye ([email protected]) -- Date: 6-Aug-1998 -------------------------------------------------------------------------column server heading "Server" format a8 column circuit heading "Name" format a8 column status heading "Status" format a8 column message0 heading "Bytes|in|First|Msg|Buf" format 9,999 column message1 heading "Bytes|in|Second|Msg|Buf" format 9,999 column messages heading "Messages|Processed" format 999,999 column queue heading "Queue" format a10 column bytes heading "Bytes" format 9,999,999 column breaks heading "Brks" format 999 SELECT

server, circuit, status, queue, message0, message1, messages, bytes, breaks

51

Oracle Distributed Systems FROM v$circuit ORDER BY server / Here is sam ple out put : Bytes

Server Brks --------00 5 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 11 00 11 00 12 00 9 00 14 00 0 00 3 00 0 00 0 00 5

Bytes

Name

Status

Queue

in in First Second Msg Msg Buf Buf

Messages Processed

Bytes

-------- -------

------- ------ ------ ---------- ----------

D7009B30 NORMAL

NONE

0

0

4,687

428,048

D7009F54 NORMAL

NONE

0

0

4,217

469,556

D700A378 NORMAL

NONE

0

0

8

273

D700A79C NORMAL

NONE

0

0

4,405

500,308

D700ABC0 NORMAL

NONE

0

0

2,328

246,359

D700AFE4 NORMAL

NONE

0

0

2,328

246,352

D700B408 NORMAL

NONE

0

0

4,432

471,695

D700B82C NORMAL

NONE

0

0

4,013

449,682

D700BC50 NORMAL

NONE

0

0

2,328

246,355

D700C074 NORMAL

NONE

0

0

2,328

246,361

D700C498 NORMAL

NONE

0

0

2,328

246,365

D700C8BC NORMAL

NONE

0

0

5,357

559,594

D700CCE0 NORMAL

NONE

0

0

5,260

537,766

D700D104 NORMAL

NONE

0

0

5,499

582,824

D700D528 NORMAL

NONE

0

0

5,195

535,113

D700D94C NORMAL

NONE

0

0

5,546

584,801

D7011B8C NORMAL

NONE

0

0

2,328

246,352

D7011768 NORMAL

NONE

0

0

4,439

421,834

D7011344 NORMAL

NONE

0

0

2,328

246,355

D7010F20 NORMAL

NONE

0

0

2,340

248,940

D7010AFC NORMAL

NONE

0

0

4,761

435,934

52

Oracle Distributed Systems 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 4 00 0 00 0 00 0 00 0 D805482C 1

D70102B4 NORMAL

NONE

0

0

40,402

8,519,935

D700FE90 NORMAL

NONE

0

0

42,936

9,030,261

D700DD70 NORMAL

NONE

0

0

2,328

246,352

D7012C1C NORMAL

NONE

0

0

2,328

246,352

D70123D4 NORMAL

NONE

0

0

8

283

D7011FB0 NORMAL

NONE

0

0

2,328

246,352

D700E194 NORMAL

NONE

0

0

45,406

9,534,634

D700E5B8 NORMAL

NONE

0

0

4,569

425,801

D700E9DC NORMAL

NONE

0

0

8

283

D700EE00 NORMAL

NONE

0

0

4,337

409,904

D700F224 NORMAL

NONE

0

0

41,002

8,628,613

D700F648 NORMAL

NONE

0

0

3,926

439,282

D700FA6C NORMAL

SERVER

0

235

521

68,737

34 rows selected. Here we see t hat all but one of t he circuit s are idle and t hat t here are no clogged m essage buffers, indicat ing t hat t he net work is able t o keep up wit h t he t raffic volum e. I f you do see m essages accum ulat ing in t he buffer, you can consider adding m ore m ult i- t hreaded server processes over which t o spread t he load. The possible values of t he STATUS and QUEUE fields of V$CI RCUI T are list ed in Table 2.5.

Table 2.5. V$CIRCUIT STATUS and QUEUE Fields Field

Values

BREAK ( circuit has been int errupt ed) ; EOF ( circuit is about t o exit ) ; NORMAL STATUS ( norm al circuit for t he local dat abase) ; OUTBOUND ( wait ing t o est ablish an out bound connect ion) COMMON ( circuit is on t he com m on queue, available t o be picked up by a server process) ; DI SPATCHER ( wait ing for a dispat cher) ; SERVER ( current ly QUEUE in user) ; OUTBOUND ( wait ing t o est ablish an out bound connect ion) ; NONE ( circuit is idle)

53

Oracle Distributed Systems

2 .3 .2 Tu n in g D e dica t e d Pr oce sse s a n d Pr e spa w n e d Pr oce sse s Unlike wit h a m ult i- t hreaded server configurat ion, a DBA usingdedicat ed or prespawned processes does not have an arsenal of V$ t ables t o assist in diagnosing connect ion- specific perform ance problem s. Since dedicat ed processes ( whet her prespawned or not ) require an operat ing syst em process for each user connect ion, one of t he problem s you are likely t o encount er is a m em ory short age. Mem ory problem s m anifest t hem selves in different ways on different operat ing syst em s, and it is not our int ent ion t o provide a prim er on syst em adm inist rat ion. However, suffice it t o say t hat if you plan t o support a large num ber of users wit h dedicat ed processes, you should be prepared t o configure your m achine wit h a large am ount of m em ory. Apart from m em ory problem s, you and your user com m unit y m ay find t hat it t akes t hem a long t im e t o connect wit h a dedicat ed process configurat ion. I f t his is t he case, and you are not current ly using prespawned processes, you should consider doing so, part icularly if your operat ing syst em is one t hat does not creat e processes quickly ( e.g., VMS) .

2 .3 .3 Br e a k Ou t t h e Sn iffe r I f you have exhaust ed t he rem edies indicat ed by t he V$ t ables and operat ing syst em st at ist ics, but perform ance is st ill slow, you m ay have t o perform an analysis of your net work t raffic wit h a sniffer in order t o analyze t he efficiency of your net work t raffic. SQL* Net sends dat a in packet s of session dat a unit ( SDU) byt es. The default value for SDU is 2048 byt es. That m eans t hat if you want t o send 4097 byt es of dat a, SQL* Net will act ually send 2048 + 2048 + 2048 = 3 packet s. You can experim ent wit h changing t he value of SDU t o see how it affect s your perform ance, but t here is no m agic form ula t o help you. However, you will benefit significant ly by t uning t he SDU if your applicat ion does at least one of t he following: • • • •

Sends m ult iple packet s of dat a Sends consist ent ly sized packet s Sends large am ount s of dat a Runs over a WAN

I f you elect t o change SDU, bear in m ind t hat it is negot iat ed t o t he lower of t he values configured for t he client and t he server. The server configurat ion file is list ener.ora ( for dedicat ed connect ions) or I NI T.ORA ( for MTS) . The client configurat ion file is t nsnam es.ora. Here is a sam ple port ion of t nsnam es.ora : D7CA.BIGWHEEL.COM = (DESCRIPTION = (SDU=8192) (ADDRESS = .......... Here is a sam ple port ion of list ener.ora :

54

Oracle Distributed Systems SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SDU = 8192) (SID_NAME = V7323) ............................... You also have ot her t uning opt ions t hat are not really specific t o SQL* Net and whose benefit s can be confirm ed only by analyzing your net work t raffic. Am ong t hese ot her opt ions are: •

•

I ncrease ARRAYSI ZE. Most Oracle applicat ions allow you t o set t he num ber of records t hat are sent at one t im e. I n SQL* Plus, t he param et er is ARRAYSI ZE. Form s has an analogous set t ing. By increasing t he value of t his set t ing, you oft en can im prove t he efficiency of your net work t ransm issions dram at ically by reducing t he num ber of round- t rip m essages. Set MTU ( m axim um t ransm ission unit ) on t he WAN.

2 .4 Loa d Ba la n cin g I f your applicat ionis one t hat m ust process a high volum e of connect ion request s in a short am ount of t im e ( e.g., a popular web sit e) , you m ight consider TNS list enerload balancing. You can configure m ult iple TNS list eners t o process your connect ion request s t o a single dat abase. Or, if you have a sym m et ric replicat ion environm ent t hat allows client s t o connect t o any of several m ast ers, you can configure TNS list eners t hat send connect ion request s t o t he m ast ers wit h t he least busy dispat chers ( assum ing t hat you are also using a m ult i- t hreaded server) .

2 .4 .1 M u lt iple TN S List e n e r s a n d M u lt i- Th r e a de d Se r ve r w it h a Sin gle D a t a ba se I n st a n ce I f you are usinga m ult i- t hreaded server, you can run TNS list eners on m ult iple nodes for your dat abase inst ance. The TNS list ener does not need t o run on t he sam e node as t he dat abase because dispat chers are able t o regist er wit h list eners on what ever node( s) you specify wit h t he I NI T.ORA param et er MTS_LI STENER_ADDRESS ( Oracle7) . I n Oracle8, use t he LI STENER at t ribut e of t he MTS_DI SPATCHERS param et er. Figure 2.2 depict s a configurat ion wit h m ult iple list eners on m ult iple m achines for a single dat abase.

Figu r e 2 .2 . M u lt iple list e n e r s on m u lt iple n ode s for a sin gle da t a ba se in st a n ce

55

Oracle Distributed Systems

The relevant m ult i- t hreaded server I NI T.ORA param et ers for t his configurat ion are as follows: mts_multiple_listeners = TRUE mts_listener_address = "(ADDRESS=(PROTOCOL=TCP)(host=eggman)(port=1521))" mts_listener_address = "(ADDRESS=(PROTOCOL=TCP)(host=walrus)(port=1521))" On t he client side, t he t nsnam es.ora file m ust also reflect t hat t he dat abase inst ance has t wo list eners by having t wo DESCRI PTI ON sect ions for t he sam e CONNECT_DATA sect ion. The client will pick one of t he t wo list eners at random . However, if t he connect ion fails, t he client will reat t em pt t he connect ion wit h t he second list ener. penguin = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (Host = eggman) (Port = 1521) ) ) (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (Host = walrus) (Port = 1521) ) ) (CONNECT_DATA = (SID = D7CA) )

56

Oracle Distributed Systems ) Not e t hat t he list eners do not have t o be list ening on t he sam e prot ocol.

2 .4 .2 M u lt iple TN S List e n e r s a n d M u lt i- Th r e a de d Se r ve r w it h M u lt iple D a t a ba se I n st a n ce s I f you are configuring a sym m et ric replicat ion or Oracle parallel server environm ent t hat allows client s t o connect t o any of several m ast ers, you can configure your list eners such t hat t hey hand off connect ions t o t he least busy dispat chers am ong all your m ast ers. You will recall t hat t he dispat cher processes updat e t he TNS list ener wit h inform at ion relevant t o load balancing. Figure 2.3 depict s such a configurat ion.

Figu r e 2 .3 . M u lt iple list e n e r s on m u lt iple n ode s for m u lt iple da t a ba se in st a n ce s

I n t his case, you m ust updat e t he t nsnam es.ora client configurat ion files t o reflect t he fact t hat t here are t wo separat e dat abase inst ances available for t he alias penguin : penguin = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (Host = eggman) (Port = 1521) ) (CONNECT_DATA = (SID=D7NY) ) )

57

Oracle Distributed Systems (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (Host = walrus) (Port = 1521) ) (CONNECT_DATA = (SID = D7CA) ) ) ) I n t his case, t here are t wo CONNECT_DATA sect ions, one for each DESCRI PTI ON_LI ST. As wit h t he m ult iple TNS list eners for a single dat abase configurat ion, client s will random ly select a list ener t o process t heir connect ion request s but will fail over t o t he ot her list ener if t he connect ion fails. I f you are using dedicat ed processes, all list eners m ust reside on t he sam e m achine as t he dat abase inst ance. For a m ult i- t hreaded server configurat ion, you can run m ult iple list eners on m ult iple m achines because dispat chers are able t o regist er wit h list eners on different nodes.

2 .4 .3 M u lt iple TN S List e n e r s a n d D e dica t e d Pr oce sse s To configure m ult iple TNS list eners for dedicat ed process connect ions, eit her you can creat e individual list ener.ora files for each one and st ore t hem in different locat ions or you can use one list ener.ora file wit h m ult iple nam ed list eners in it . The processes t hat st art t he list eners m ust each have t he appropriat e environm ent variable set t o t he locat ion of list ener.ora. I n Unix, t his environm ent variable is TNS_ADMI N. I f you are finding t hat your list ener is not able t o handle all of t he connect ion request s, you should consider set t ing t he QUEUESI ZE in your list ener.ora file ( boldfaced in t he following exam ple) . This param et er set s t he num ber of connect ion request s t he list ener can queue—t hat is, t he num ber of request s t hat it will allow t o wait while it processes earlier request s. I f your client s are experiencing t im eout s when t rying t o connect , set t ing t his param et er can alleviat e t he problem , but only by m aking t he connect ion request s wait for t he list ener t o process t hem . I f you are st ill experiencing t im eout s, you should run addit ional list eners. ################ # Filename......: listener.ora # Name..........: walrus # Date..........: 08-SEP-98 11:44:31 ################ LISTENER = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = walrus) (Port = 1521) (Queuesize = 20) ) )

58

Oracle Distributed Systems STARTUP_WAIT_TIME_LISTENER = 0 CONNECT_TIMEOUT_LISTENER = 10 TRACE_LEVEL_LISTENER = OFF SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = D7CA) (ORACLE_HOME = /usr/home/oracle/product/7.3.3) ) )

2 .5 Or a cle 8 Sca la bilit y Opt ion s Oracle has int roduced connect ion pooling and m ult iplexing wit h Net 8, t he net work com ponent of Oracle8. Bot h of t hese feat ures build on t he funct ionalit y t hat exist s wit h t he m ult i- t hreaded server t hat first shipped wit h Oracle7. Wit h t he added benefit s of connect ion pooling and m ult iplexing, Oracle has racked up som e very im pressive benchm ark result s wit h t ens of t housands of users. Your m ileage m ay vary.

2 .5 .1 Con n e ct ion Poolin g Connect ion pooling m axim izes t he ut ilizat ion of a dispat cher's exist ing net work connect ions by det ect ing client s t hat are connect ed but idle for a predet erm ined t im e and reallocat ing t heir t ransport connect ion t o an incom ing client connect ion. The default t im eout value is det erm ined by Net 8 and m ay vary by plat form . I f t he idle client resum es act ivit y, t he connect ion is reest ablished. You enable connect ion pooling by specifying t he POOL at t ribut e of t he MTS_DI SPATCHERS I NI T.ORA param et er—for exam ple: mts_dispatchers="(PROTOCOL=TCP)(POOL=ON)" This enables connect ion pooling for t he dispat cher, using t he default values. Connect ion pooling applies t o bot h incom ing and out going connect ions, and you can specify t he t im eout ( in net work t icks) for bot h t ypes of connect ions: mts_dispatchers="(PROTOCOL=TCP)(POOL=(IN=20)(OUT=100))" You can also enable connect ion pooling for inbound ( or out bound) connect ions only: mts_dispatchers="(PROTOCOL=TCP)(POOL=(IN=20))" Obviously, connect ion pooling works bet t er wit h som e t ypes of applicat ions t han ot hers. I n order t o profit from it , your applicat ion should be charact erized by a relat ively low rat io of act ive dat a request s t o concurrent sessions. Exam ples include decision support syst em s ( DSS) , online t ransact ion processing ( OLTP) , and m essaging applicat ions.

59

Oracle Distributed Systems

2 .5 .2 Se ssion M u lt iple x in g Mult iplexing is a solut ion for applicat ions t hat m ust support a high num ber of act ive users, for t hose t hat use connect ion m anager already, or for t hose t hat have a high reconnect cost ( WAN or sat ellit e) . I t uses t he Oracle connect ion m anager t o service m ult iple net work sessions t hrough a single t ransport connect ion. The connect ion m anager is essent ially a concent rat or for client sessions. The connect ion m anager has t hree com ponent s, each wit h a corresponding execut able, described in Table 2.6.

Table 2.6. Connection Manager Components Executable Name (Unix and VMS/Desktop)

Description

cm gw/ cm gw80

The gat eway process. This process regist ers wit h t he connect ion m anager adm inist rat ive process, list ens for incom ing SQL* Net / Net 8 connect ion request s, init iat es connect ion request t o Net 8 list eners for client s, and answers request s init iat ed by cm ct l.

cm adm / cm adm 80

The connect ion m anager adm inist rat ive process. Prim arily responsible for m aint aining address inform at ion in t he Oracle Nam es server ( if any) . I t also processes cm gw and list ener regist rat ion, locat es t he local nam e server ( if any) , ident ifies all list eners t hat are serving one or m ore dat abase inst ances, updat es t he Oracle Nam es server ( if any) wit h net work updat es, and answers request s init iat ed by cm ct l. Not e t hat all com m unicat ion bet ween cm gw and cm adm is via I PC. The connect ion m anager ut ilit y program , analogous t o lsnrct l. This ut ilit y includes four basic com m ands:

cm ct l/ cm ct l80

START [ cm an | cm | adm ] st art s eit her or bot h t he gat eway process and adm inist rat ive process. STOP [ cm ] st ops t he connect ion m anager. St opping t he gat eway process also st ops t he adm inist rat ive process. STATUS [ cm an | cm | adm in] provides st at us inform at ion about t he t hree com ponent s. VERSI ON provides version inform at ion.

I f you are using TCP/ I P, you can enable t he default behavior of t he connect ion m anager sim ply by m odifying t he following I NI T.ORA param et er: mts_dispatchers="(PROTOCOL=TCP)(MULTIPLEX=ON)" You can also enable m ult iplexing for incom ing or out going connect ions individually: mts_dispatchers="(PROTOCOL=TCP)(MULTIPLEX=IN)" mts_dispatchers="(PROTOCOL=TCP)(MULTIPLEX=OUT)"

60

Oracle Distributed Systems By default , t he connect ion m anager list ens on port 1600, and you can st art it by issuing t he com m andcm ct l st art . I n order t o cust om ize t he behavior of m ult iplexing and t he connect ion m anager, you m ust creat e a configurat ion file, called cm an.ora. # Connection Manager config file # cman.ora - The file is used by cman and cman_admin. # # These are cman's listening addresses (one or more) for the purpose of # relaying TNS sessions. # CMAN=(ADDRESS=(PROTOCOL=TCP)(Host=walrus.bigwheel.com)(Port=1600))) CMAN= (ADDRESS_LIST= (ADDRESS= (PROTOCOL=TCP) (HOST=walrus.bigwheel.com) (PORT=1600) ) ) # # # These parameters control the connection managers logging and capacity. CMAN_PROFILE = (PARAMETER_LIST= (MAXIMUM_RELAYS=10240) (LOG_LEVEL=ADMIN) (TRACING=no) (RELAY_STATISTICS=no) (SHOW_TNS_INFO=no) (USE_ASYNC_CALL=yes) (AUTHENTICATION_LEVEL=0) (ANSWER_TIMEOUT=0) ) # CMAN_RULES defines where connections are accepted or rejected. CMAN_RULES=(RULE=(SRC=x.x.x.x)(DST=189.221.84.120)(SRV=D8CA)(ACT=accept )) The usage of t he param et ers CMAN, CMAN_PROFI LE, and CMAN_RULES is sum m arized in Table 2.7 t hrough Table 2.9.

Table 2.7. cman.ora: CMAN Section Parameter Name CMAN

Description CMAN cont ains one or m ore addresses for t he port s on which t he connect ion m anager is processing connect ion request s. You m ust specify t he address param et ers PROTOCOL, HOST, and PORT.

Table 2.8. cman.ora: CMAN_PROFILE Section

61

Oracle Distributed Systems

Parameter Name

ANSWER_TI MEOUT

Default

0

Value Range

Description

Num ber of seconds t he connect ion m anager uses t o inst ruct NS ( Net work 0 Services) t o t im e out a connect ion unlim it ed request . A value of 0 indicat es t hat no t im eout s should occur.

AUTHENTI CATI ON_LEVEL 0

0, 1

0 im plies no aut hent icat ion. 1 causes t he connect ion m anager t o rej ect connect ion at t em pt s t hat are not using SNS ( Secure Net work Services) t o perform client aut hent icat ion.

LOG_LEVEL

0

0 - 4

Level of logging perform ed.

MAXI MUM_RELAYS

8

1- 10,240

The m axim um num ber of hops t hat t he connect ion m anager will support .

RELAY_STATI STI CS

no

no, yes

I f " yes," connect ion m anager m aint ains st at ist ics about relay I / O.

SHOW_TNS_I NFO

no

no, yes

I f " yes," connect ion m anager m aint ains TNS inform at ion in it s logging.

TRACI NG

no

no, yes

I f " yes," connect ion m anager will creat e t race files.

USE_ASYNC_CALL

no

no, yes

I f " yes," connect ion m anager uses asynchronous NS funct ions nsanwer, nsaccept , and nscall.

The opt ional CMAN_RULES param et er provides a m et hod of rest rict ing access t o t he dat abase based on t he originat ion of t he connect ion request , it s t arget host , and it s t arget ORACLE_SI D. The param et er is included in t he cm an.ora file using t his synt ax: CMAN_RULES = (RULE_LIST=...)

Table 2.9. cman.ora: CMAN_RULES Section Parameter

Description

ACT

The act ion t o perform : " accept " t o accept t he connect ion request or " rej ect " t o rej ect it .

DST

The t arget ( dest inat ion) host nam e or I P address. The charact er " x" m ay be used as a wildcard in I P addresses.

SRC

Nam e or I P address of t he source of t he connect ion request . The charact er " x" m ay be used as a wildcard in I P addresses.

SRV

The ORACLE_SI D of t he t arget dat abase.

I f t he CMAN_RULES param et er is present , t hen t he only connect ion request s t hat are accept ed are t hose t hat m eet t he rules defined. Not e t hat CMAN_RULES is applicable only in a TCP/ I P net work. You m ust also m odify t he t nsnam es.ora on t he client side t o " t each" it t o use t he correct addressing t o t he connect ion m anager. I f you are running a single prot ocol, you would m odify t he t nsnam es.ora t o look som et hing like t his:

62

Oracle Distributed Systems d8ca.bigwheel.com = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS= (PROTOCOL=TCP) (HOST=walrus.bigwheel.com) (PORT=1600) ) (ADDRESS = (PROTOCOL = TCP) (Host = eggman.bigwheel.com) (Port = 1521) ) ) (CONNECT_DATA = (SID = D8CA) ) (SOURCE_ROUTE=YES) ) The ADDRESS sect ion inst ruct s t he client t o connect t o WALRUS.BI GWHEEL.COM on port 1600 ( where it will find t he connect ion m anager wait ing) . Then, it t ells t he connect ion m anager t o connect t o t he list ener t hat is list ening on port 1521. Essent ially, t he ADDRESS sect ion is t he rout e t hat t he client will use t o connect t o t he dat abase. The really nice t hing about t he connect ion m anager is t hat you can specify a rout e t hat has m ult iple prot ocols in it . I n fact , Oracle's st at ed direct ion is t o replace t he Mult iProt ocol I nt erchange wit h t he connect ion m anager. I n t he preceding exam ple, t he prot ocol bet ween t he client and t he connect ion m anager could have been, for exam ple, SPX, and t he t nsnam es.ora ent ry would t hen look like t his: d8ca.bigwheel.com = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS= (PROTOCOL=SPX) (HOST=walrus.bigwheel.com) (PORT=1600) ) (ADDRESS = (PROTOCOL = TCP) (Host = eggman.bigwheel.com) (Port = 1521) ) ) (CONNECT_DATA = (SID = D8CA) ) (SOURCE_ROUTE=YES) ) You can even have a rout e t o a connect ion m anager t hat m aps t o anot her connect ion m anager on anot her node.

63

Oracle Distributed Systems

2 .5 .3 Sca la bilit y: Su m m a r y Net 8 provides addit ional net work scalabilit y capacit y by offering connect ion pooling and m ult iplexing. Connect ion pooling is well suit ed for applicat ions t hat m ay service a high num ber of connect ions wit h a high proport ion of idle connect ions. Mult iplexing is int ended for applicat ions t hat m ust support a high volum e of connect ions, all of which are act ive. The dynam ic perform ance t ables V$DI SPATCHER and V$DI SPATCHER_RATE provide st at ist ics about t he efficiency of bot h connect ion pooling and m ult iplexing .

2 .6 SQL* N e t / N e t 8 Clie n t Con figu r a t ion The sqlnet .ora file on a client m achine cont ains param et ers t hat govern t he client 's behavior. The at t ribut es t hat can be m odified fall int o five cat egories: • • • • •

Dead connect ion det ect ion Tracing and logging Default dom ains Oracle Nam es param et ers Ot her opt ional param et ers

These at t ribut es are described in t he sect ions t hat follow.

2 .6 .1 D e a d Con n e ct ion D e t e ct ion SQL* Net / Net 8 can aut om at icallydet ect and t erm inat e connect ions t hat are no longer valid. This feat ure is part icularly useful for environm ent s in which t he client s are PCs, because users m ay reboot t heir PCs or ot herwise t erm inat e t heir sessions wit hout logging out of t he dat abase. Reboot ing a PC does not in and of it self cause t he corresponding dat abase session t o t erm inat e, because t he underlying t ransport , such as TCP/ I P, does not recognize it as such. The worst - case scenario is t hat t he user reboot s his PC while he has a lock on a t able! Alt hough you can assign a profile t o your users t hat lim it s connect t im e and idle t im e, you usually have t o set t hese lim it s high enough t o accom m odat e users who want t o go out t o lunch wit hout logging out of t he applicat ion ( e.g., several hours) . You can use dead connect ion det ect ion t o search and dest roy invalid connect ions every 10 m inut es or so. To do so, you m ust specify t he opt ional param et er SQLNET.EXPI RE_TI ME in t he sqlnet .ora file. The num ber you specify is t he frequency in m inut es wit h which SQL* Net / Net 8 probes connect ions t o confirm t heir validit y. Sessions t hat are dead or invalid are t erm inat ed. I f dead connect ion det ect ion is enabled, SQL* Net sends a probe periodically t o det erm ine whet her t here is an invalid connect ion t hat should be t erm inat ed. I f it finds a dead connect ion, or a connect ion t hat ret urns an error, it causes t he server t o t erm inat e t he connect ion. Of course, t here is a cert ain am ount of overhead associat ed wit h using dead connect ion det ect ion:

64

Oracle Distributed Systems •

•

Addit ional net work t raffic for t he dead connect ion probes every SQLNET.EXPI RE_TI ME m inut es. Pot ent ial perform ance degradat ion on t he Oracle server which m ust dist inguish bet ween connect ion probing event s and ot her event s. You should perform your own analysis t o det erm ine whet her your plat form is adversely affect ed.

Som e prot ocols have t heir own dead connect ion det ect ion algorit hm s, which m ay obviat e t he need t o use SQL* Net / Net 8's version.

2 .6 .2 Tr a cin g a n d Loggin g The sqlnet .ora file cont ains several opt ional param et ers forlogging and t racing t hat you can use t o collect st at ist ics on client / server act ivit y. You can use t he param et ers described in Table 2.10 t o analyze net work act ivit y.

Table 2.10. sqlnet.ora: Tracing and Logging Parameters Parameter Name

Description

LOG_DI RECTORY_CLI ENT

Direct ory in which t o place out put log file. Default locat ion is t he current working direct ory.

LOG_FI LE_CLI ENT

Nam e of t he out put file for logging inform at ion. Default filenam e is sqlnet .log.

TNSPI NG.TRACE_DI RECTORY

Direct ory in which t o place TNSPI NG log files. Default locat ion is plat form - specific. Det erm ines level of t racing for TNSPI NG act ivit y. Possible values are OFF, USER, and ADMI N.

TNSPI NG.TRACE_LEVEL

OFF indicat es no t racing. USER indicat es end- user t racing ( inform at ion includes such diagnost ics as invalid address) . ADMI N indicat es full t racing is enabled, including prot ocol and configurat ion errors.

TRACE_DI RECTORY_CLI ENT

Locat ion of t race file. Default value is current direct ory.

TRACE_FI LE_CLI ENT

Nam e of t race file. Default value is sqlnet .t rc. Det erm ines level of t race file det ails for client act ivit ies. Possible values are OFF, USER, and ADMI N.

TRACE_LEVEL_CLI ENT

OFF indicat es not t racing. USER indicat es t racing of errors such as addressing errors and m issing prot ocol st ack errors. ADMI N provides full t racing capabilit ies, including t hird- part y soft ware inconsist encies.

65

Oracle Distributed Systems

2 .6 .3 D e fa u lt D om a in s The sqlnet .ora param et er DEFAULT_DOMAI N specifies t he dom ain t o use when t he client 's connect st ring does not specify a fully qualified pat h. For exam ple, if t he sqlnet .ora file cont ains t he ent ry: NAMES.DEFAULT_DOMAIN = BIGWHEEL.COM t hen t he connect st ring: SCOTT@SALES will resolve t o: [email protected] This param et er m ay be present in sqlnet .ora regardless of whet her you are using Oracle Nam es.

2 .6 .4 Or a cle N a m e s Pa r a m e t e r s Theparam et er NAMES.DI RECTORY_PATH det erm ines t he order in which nam e resolut ion services are at t em pt ed. The default value is TNSNAMES, ONAMES. The default set t ing NAMES.DIRECTORY_PATH = (TNSNAMES, ONAMES) indicat es t hat t he t nsnam es.ora file is probed first t o resolve t he SQL* Net alias, followed by t he Oracle Nam es server. I f you are using Oracle Nam es, you m ust specify t he param et er NAMES.PREFERRED_SERVERS, which includes one or m ore addresses of t he nam e servers t he client should use.

2 .6 .5 Addit ion a l Pa r a m e t e r s Table 2.11 describes addit ional,opt ional param et ers you can include in t he client sqlnet .ora file.

Table 2.11. sqlnet.ora: Optional Parameters Default

Value Range

AUTOMATI C_I PC

ON

ON, OFF

I f OFF, client connect ions will not at t em pt t o use an I PC address t o est ablish connect ions.

DI SABLE_OOB

OF

ON, OFF

Disables use of Out - of- Band Breaks. Not e t hat t his m ay boost perform ance for

Parameter Name

Description

66

Oracle Distributed Systems

applicat ions t hat ret urn m any rows of dat a at a t im e because t he server does not check for breaks aft er each SEND. USE_DEDI CATED_SERVER OFF

ON, OFF

Forces use of dedicat ed processes for client connect ion.

2 .7 SN M P Su ppor t Beginning wit h Oracle Version 7.2 and SQL* Net Version 2.2, Oracle has included SNMP ( Sim ple Net work Managem ent Prot ocol) support in it s product s. This funct ionalit y provides adm inist rat ors wit h " hooks" t hey can use t o gat her perform ance and diagnost ic inform at ion from Oracle for analysis in a t hird- part y t ool ( such as Hewlet t - Packard's OpenView) . The SNMP hooks are int egrat ed int o t he Oracle product line; however, you m ust run an SNMP m ast er agent in order t o run Oracle's subagent . Oracle does not provide t he SNMP m ast er agent ; t hey provide SNMP subagent s t hat com m unicat e wit h t he m ast er agent . Oracle's subagent is a separat e execut able ( dbsnm p on t he Unix port ) . The prim ary use of Oracle SNMP is t hat DBAs or dat a cent er operat ors can use a t ool such as OpenView t o m onit or t he st at us of all Oracle dat abases and list eners on t he net work. The range of inform at ion includes: • • • •

•

Dat abase inst ance st at us Perform ance problem s Discovery of new dat abases Abilit y t o set alert s for various event s and configure aut om at ic not ificat ion of t he appropriat e personnel Abilit y t o st ore and report on hist orical dat a

2 .7 .1 Con figu r in g SN M P Su ppor t Essent ially, t he only way t o configure t he Oracle SNMP subagent s is wit h t he Oracle Net work Manager product , which ( as of t his writ ing) exist s only on t he Windows NT plat form . The Net work Manager provides an int erface for set t ing param et ers and generat ing t he SNMP.ORA configurat ion file, which is required for each m anaged node. The SNMP.ORA file resides in t he sam e direct ory as t he ot her net work configurat ion files ( t nsnam es.ora, et c.) . The param et ers you can set are: • • • • •

SNMP VI SI BLE SNMP I NDEX SNMP CONTACT USERNAME ( if subagent m onit ors an Oracle dat abase server) PASSWORD ( if subagent m onit ors an Oracle dat abase server)

Aft er creat ing t he SNMP.ORA files, you m ust also run t he CATSNMP.SQL script t o creat e t he SNMPAGEN role and DBSNMP user, which are bot h required in dat abases t hat are visible t o SNMP.

67

Oracle Distributed Systems

2 .7 .2 Usin g SN M P I n addit ion t o st art ing t he m ast er agent , encapsulat or, and nat ive SNMP agent for your plat form , you also m ust st art t he Oracle SNMP subagent s for t he Oracle dat abase and for t he Oracle net work services. Use t he lsnrct l ut ilit y t o cont rol t he Oracle dat abase subagent : LSNRCTL> dbsnmp_start starts the database subagent LSNRCTL> dbsnmp_stop stops the database subagent LSNRCTL> dbsnmp_status reports status information for the database subagent The subagent s for t he TNS list ener, Mult iProt ocol I nt erchange, and Oracle Nam es server are st art ed aut om at ically wit h t he respect ive service.

2 .8 Se cu r it y Oracle has been bundling securit y product s wit h SQL* Net and t he RDBMS since Version 7.1.4 of t he dat abase. They have m oved t he securit y soft ware from Secure Net work Services int o t he Advanced Net working Opt ion, which includes addit ional nam ing services as well. But what ever t he nam e, t he product provides encrypt ion and aut hent icat ion services for SQL* Net / Net 8. Table 2.12 depict s t he m at rix of RDBMS releases, bundled securit y soft ware, and funct ionalit y. The inst allat ion and configurat ion of t hese services is plat form - specific.

Table 2.12. Security Products Provided with the RDBMS RDBMS Version

Security Product

Encryption Services

Authentication Services

7.1.4

Secure Net work Services 1.0.1

RSA RC4 40

NA

7.1.5

Secure Net work Services 1.0.2

RSA RC4 40

NA

7.1.6

Secure Net work Services 1.0.3

RSA RC4 40

NA

7.2.2

Secure Net work Services 1.1.x

RSA RC4 40, 56

NA

DES 40, 56 7.2.x

Secure Net work Services 2.0.x

RSA RC4 40, 56

Kerberos, CyberSAFE, SecurI D

DES 40, 56

68

Oracle Distributed Systems

7.3.x

RSA RC4 40, Advanced Net working 56 Opt ion 2.3.x DES 40, 56

Kerberos, CyberSAFE, SecurI D

RSA RC4 40, 56, 128

8.0.x

DES 40, 56 Advanced Net working Kerberos, CyberSAFE, SecurI D, Opt ion 8.0.x Diffie- Hellm an I dent ix TouchNet I I , DCE GSSAPI Key Fold- I n MD5

69

Oracle Distributed Systems

70

Oracle Distributed Systems

Ch a pt e r 3 . Con figu r a t ion a n d Adm in ist r a t ion The ease wit h which you can adm inist er a dist ribut ed dat abase environm ent is, t o a large degree, a funct ion of how well it is configured. Wit h proper planning and im plem ent at ion, your dist ribut ed dat abase environm ent can at t ain a very high degree of locat ion t ransparency, expandabilit y, and securit y regardless of how m any individual dat abase inst ances com prise it . These obj ect ives are not t he only goals; syst em s m ust also be: Maint ainable The DBA has t he flexibilit y t o m ove dat abases t o different m achines, change ORACLE_SI Ds, apply pat ches, relocat e t ables, and so on, wit hout requiring changes t o applicat ion code or changes t o client configurat ions. The int eroperabilit y and int erdependencies of t he various dat abases m ust be readily underst ood. Robust The failure of one dat abase inst ance does not render ot hers inoperable. Concurrent Dist ribut ed t ransact ions m eet t he ACI D crit eria ( aut onom ous, consist ent , isolat ed, durable) . I n t his chapt er, we exam ine t he DBA's responsibilit ies and concerns for providing such an environm ent . I n Chapt er 5, we consider t he applicat ion designer's point of view.

3 .1 I n it ia liza t ion Pa r a m e t e r s Oracle provides a num ber of init ializat ion param et ers ( sum m arized in Table 3.1) t hat govern various aspect s of your dist ribut ed environm ent . These param et ers are specified in t he I NI T.ORA file, t he locat ion of which is plat form - specific. This sect ion describes how and when you should use t hese param et ers.

Table 3.1. Initialization Parameters Relevant to Distributed Databases Parameter Name

Description

COMMI T_POI NT_STRENGTH

Det erm ines t he com m it point sit e in dist ribut ed t ransact ions

DB_DOMAI N

St ring ident ifying t he dom ain in which t he dat abase inst ance resides

DBLI NK_ENCRYPT_LOGI N ( Oracle8)

Det erm ines whet her connect ions over dat abase

71

Oracle Distributed Systems

links should send encrypt ed passwords DI STRI BUTED_LOCK_TI MEOUT

Num ber of seconds a dist ribut ed t ransact ion will wait t o acquire a lock

Num ber of seconds t o hold a connect ion open in t he event DI STRI BUTED_RECOVERY_CONNECTI ON_HOLD_TI ME t hat a dist ribut ed t ransact ion fails DI STRI BUTED_TRANSACTI ONS

Maxim um num ber of concurrent dist ribut ed t ransact ions

GLOBAL_NAMES

Enforces t he use of global nam ing

JOB_QUEUE_I NTERVAL

Period ( in seconds) of dorm ancy for j ob queue background processes

JOB_QUEUE_PROCESSES

Num ber of j ob queue background processes

MAX_TRANSACTI ON_BRANCHES

Maxim um num ber of dat abase inst ances t hat can part icipat e in a dist ribut ed t ransact ion

OPEN_LI NKS

Maxim um num ber of open dat abase links per session

OPEN_LI NKS_PER_I NSTANCE ( Oracle8)

Maxim um num ber of open dat abase links for t he dat abase inst ance

REMOTE_DEPENDENCI ES_MODE

Specifies algorit hm for det erm ining validit y of st ored procedures ( TI MESTAMP or SI GNATURE)

REMOTE_LOGI N_PASSWORD_FI LE

Det erm ines m et hod of validat ing privileged account s

REMOTE_OS_AUTHENT

Det erm ines whet her operat ing syst em validat ed account s are allowed from rem ot e m achines

REMOTE_OS_ROLES

Det erm ines whet her t o use operat ing syst em roles or dat abase roles for rem ot e client s

REPLI CATI ON_DEPENDENCY_TRACKI NG ( Oracle8)

Enables or disables dependency t racking

SNAPSHOT_REFRESH_I NTERVAL

Period ( in seconds) of dorm ancy for snapshot background processes

SNAPSHOT_REFRESH_PROCESSES

Num ber of snapshot background processes

72

Oracle Distributed Systems

3 .1 .1 COM M I T_ POI N T_ STREN GTH Dat at ype: I nt eger Default : 10 Range: 0 t hrough 255 The dat abase inst ance wit h t he highest COMMI T_POI NT_STRENGTH is t he com m it point sit e in a dist ribut ed t ransact ion. The com m it point sit e ret ains inform at ion required for t ransact ions t hat use a t wo- phase com m it . I n general, t he higher a dat abase's availabilit y, t he higher it s COMMI T_POI NT_STRENGTH should be.

3 .1 .2 D B_ D OM AI N Dat at ype: Charact er st ring Default : WORLD Range: Any st ring st art ing wit h an alphanum eric charact er and consist ing only of alphanum eric charact ers and periods ( .) , underscores ( _ ) , and pound signs ( # ) . The global nam e of every Oracle dat abase is of t he form DB_NAME.DB_DOMAI N so t he nam e you select for DB_DOMAI N should m at ch t he dom ain nam e of your sit e, for exam ple, US.ORACLE.COM. The set t ing of t he NAMES.DEFAULT_DOMAI N param et er in your sqlnet .ora file should also have t he sam e value. Following t hese convent ions sim plifies t he adm inist rat ion of your dist ribut ed environm ent .

3 .1 .3 D BLI N K_ EN CRYPT_ LOGI N ( Or a cle 8 ) Dat at ype: Boolean Default : FALSE Range: TRUE or FALSE By default , Oracle sends encrypt ed passwords over t he net work t o est ablish connect ions over dat abase links. I f t he connect ion at t em pt fails, Oracle t ries again wit h an unencrypt ed password. Set t ing DBLI NK_ENCRYPT_LOGI N t o TRUE prevent s Oracle from reat t em pt ing t he connect ion wit h t he unencrypt ed password.

3 .1 .4 D I STRI BUTED _ LOCK_ TI M EOUT Dat at ype: I nt eger Default : 60 ( seconds) Range: Minim um value 1; no m axim um lim it

73

Oracle Distributed Systems Alt hough you can set DI STRI BUTED_LOCK_TI MEOUT t o an arbit rarily high value, t he highest value Oracle uses is 2,808,348,671 ( seconds) . Since t his value equat es t o m ore t han 88 years, it is not likely t o be a lim it at ion. I f you are using t he advanced replicat ion facilit ies, t he default value of 60 seconds m ay not be adequat e; a set t ing of 300 is a reasonable st art ing point .

3 .1 .5 D I STRI BUTED _ RECOVERY_ CON N ECTI ON _ H OLD _ TI M E Dat at ype: I nt eger Default : 200 ( seconds) Range: Minim um value 0; no m axim um lim it The DI STRI BUTED_RECOVERY_CONNECTI ON_HOLD_TI ME param et er dict at es how long Oracle will keep a failed t ransact ion's connect ion open. I f t he t ransact ion is reat t em pt ed, it will not have t o spend t im e reest ablishing t he connect ion. Alt hough you can specify an arbit rarily high value for t his param et er in t he I NI T.ORA file, t he highest value Oracle uses is 4,294,967,295. However, since t he recoverer ( RECO) background process wakes up every 30 m inut es t o resolve failed dist ribut ed t ransact ions, any value above t he following: 30 m inut es × 60 seconds/ m inut e = 1800 seconds effect ively specifies an infinit e hold t im e. Maint aining a failed t ransact ion's open connect ion consum es syst em resources; t his could be an issue if you have a large num ber of dist ribut ed t ransact ions.

3 .1 .6 D I STRI BUTED _ TRAN SACTI ON S Dat at ype: I nt eger Default : Operat ing- syst em specific; derived from TRANSACTI ONS Range: 0 t hrough TRANSACTI ONS The DI STRI BUTED_TRANSACTI ONS param et er set s t he m axim um num ber of dist ribut ed t ransact ions in which t he dat abase can sim ult aneously part icipat e. This value m ust be less t han or equal t o t he value of TRANACTI ONS. By default , Oracle set s DI STRI BUTED_TRANSACTI ONS t o TRANSACTI ONS/ 4. ( Unless ot herwise specified, TRANSACTI ONS = 1.1 × PROCESSES.) Oracle does not st art t he recoverer ( RECO) background process if DI STRI BUTED_TRANSACTI ONS is zero, which m eans t hat no dist ribut ed t ransact ions are perm it t ed. The derived value for DI STRI BUTED_TRANSACTI ONS is suit ably high for m ost applicat ions; in fact , it m ay be t oo high. I f you experience a high num ber of failed dist ribut ed t ransact ions, you should consider reducing DI STRI BUTED_TRANSACTI ONS t o decrease t he num ber of concurrent dist ribut ed t ransact ions and t herefore t he num ber of in- doubt t ransact ions.

74

Oracle Distributed Systems

3 .1 .7 GLOBAL_ N AM ES Dat at ype: Boolean Default : FALSE Range: TRUE or FALSE Set t ing GLOBAL_NAMES t o TRUE enforces t he global nam ing of dat abase links. That is, t he nam e of a dat abase link m ust be t he sam e as t he global nam e of t he dat abase t o which it connect s. By default , a dat abase's global nam e is DB_NAME.DB_DOMAI N ( e.g., D7NY.BI GWHEEL.COM) . You m ust set GLOBAL_NAMES t o TRUE in order t o use any com ponent s of advanced replicat ion. Even if you are not using replicat ion, it is a good idea t o enforce global nam ing because t he result ing consist ency eases dat abase adm inist rat ion.

3 .1 .8 JOB_ QUEUE_ I N TERVAL Dat at ype: I nt eger Default : 60 ( seconds) Range: 1 t hrough 3600 ( seconds) The JOB_QUEUE_I NTERVAL param et er specifies how oft en t he snapshot background processes ( SNPn ) wake up t o check for snapshot s t o fire or j obs t o execut e. ( The values for n range from 0- 9 and A- Z.) Alt hough use of t he j ob queue is not rest rict ed t o dist ribut ed environm ent s, it plays a crit ical role in advanced replicat ion, so we include it here. I n an environm ent using snapshot s and/ or m ult i- m ast er replicat ion, JOB_QUEUE_I NTERVAL should be less t han t he t im e it t akes t o perform all of t he snapshot refreshes and queue pushes and less t han t he int erval at which your j obs are scheduled. Jobs in t he DBMS_JOB queue cannot run m ore oft en t han every JOB_QUEUE_I NTERVAL seconds. This param et er replaces SNAPSHOT_REFRESH_I NTERVAL, which st ill exist s in Oracle8 as an undocum ent ed param et er.

3 .1 .9 JOB_ QUEUE_ PROCESSES Dat at ype: I nt eger Default : 0 Range: 0 t hrough 36 The JOB_QUEUE_PROCESSES param et er specifies how m any snapshot background processes ( SNPn) t he dat abase inst ance should use. ( The values for n range from 09 and A- Z.) Since t he default is zero, you m ust specify t his param et er if you wish t o run t hese background processes. I f you have num erous snapshot s or scheduled j obs t hat run sim ult aneously, you m ust have m ult iple SNPn background processes. A

75

Oracle Distributed Systems single SNPn process perform s snapshot refreshes and j ob execut ions serially. Oracle recom m ends set t ing JOB_QUEUE_PROCESSES t o at least t wo at sit es using m ult im ast er replicat ions. This param et er replaces SNAPSHOT_REFRESH_PROCESSES, which st ill exist s in Oracle8 as an undocum ent ed param et er.

3 .1 .1 0 M AX_ TRAN SACTI ON _ BRAN CH ES Dat at ype: I nt eger Default : 8 Range: 1 t hrough 32 The MAX_TRANSACTI ON_BRANCHES param et er specifies t he m axim um num ber of branches t he session t ree of a dist ribut ed t ransact ion can have. Oracle int roduced t his param et er wit h Version 7.1.6, presum ably t o alleviat e rest rict ions t hat t he kernel had been im posing on cert ain t ransact ion process m onit oring soft ware: Here is a not e from t he 7.1.6 README.doc: This param et er cont rols t he num ber of branches in a dist ribut ed t ransact ion. For exam ple, t he TopEnd TP Monit or uses one branch per process involved in a dist ribut ed t ransact ion. The Tuxedo TP m onit or uses one branch per process group involved in a dist ribut ed t ransact ion. The previously fixed m axim um num ber of branches lim it ed t he num ber of TopEnd servers involved in a dist ribut ed t ransact ion t o 8 per Oracle inst ance. Wit h t he MAX_TRANSACTI ON_BRANCHES param et er, t he m axim um num ber of branches can be increased t o 32, allowing for 32 TopEnd processes per Oracle inst ance t o work on one dist ribut ed t ransact ion. Set t ing MAX_TRANSACTI ON_BRANCHES t o a lower value will reduce shared pool m em ory usage slight ly ( n × dist ribut ed_t ransact ions × 72 byt es) .

3 .1 .1 1 OPEN _ LI N KS Dat at ype: I nt eger Default : 4 Range: 0 t hrough 255 The OPEN_LI NKS param et er specifies t he m axim um num ber of open dat abase links a single session can have; it should be at least as large as t he m axim um num ber of dat abases referenced in a single t ransact ion.

3 .1 .1 2 OPEN _ LI N KS_ PER_ I N STAN CE ( Or a cle 8 ) Dat at ype: I nt eger Default : 4 Range: 0 t hrough 255

76

Oracle Distributed Systems The OPEN_LI NKS_PER_I NSTANCE param et er set s t he m axim um num ber of open dat abase links t hat can exist sim ult aneously in t he ent ire dat abase inst ance.

3 .1 .1 3 REM OTE_ D EPEN D EN CI ES_ M OD E Dat at ype: Charact er st ring Default : TI MESTAMP Range: TI MESTAMP or SI GNATURE The REMOTE_DEPENDENCI ES_MODE param et er designat es t he m et hod of validat ing PL/ SQL obj ect s ( packages, procedures, and t riggers) t hat have rem ot e dependencies. I f you specify t he TI MESTAMP dependencies m ode, obj ect s require recom pilat ion if t he rem ot e obj ect has a m odificat ion t im e t hat is lat er t han t he local obj ect . I n SI GNATURE m ode, no recom pilat ion is required as long as t he rem ot e obj ect s exist .

3 .1 .1 4 REM OTE_ LOGI N _ PASSW ORD _ FI LE Dat at ype: Charact er st ring Default : None Range: NONE, SHARED, or EXCLUSI VE The REMOTE_LOGI N_PASSWORD_FI LE param et er specifies whet her users are t o be validat ed t hrough a password file. A set t ing of NONE indicat es t hat t here is no password file. SHARED indicat es t hat t he sam e password file is used by user SYS ( or I NTERNAL) for m ult iple dat abases. EXCLUSI VE indicat es t hat t he password file is for a single dat abase, wit h all nam ed users represent ed in t he file.

3 .1 .1 5 REM OTE_ OS_ AUTH EN T Dat at ype: Boolean Default : FALSE Range: TRUE or FALSE The REMOTE_OS_AUTHENT param et er enables or disables operat ing syst em validat ed ( OPS$) account s from rem ot e m achines. I f you specify TRUE, t hen t hese account s can log in regardless of t he m achine from which t he process originat es. I f you specify FALSE, t hen operat ing syst em validat ed account s work only for processes t hat are running on t he sam e m achine as t he dat abase inst ance. I f you set t his param et er t o TRUE, you should be very careful not t o creat e privileged OPS$ account s ( such as OPS$ORACLE) because it is quit e easy t o m asquerade as a different user from , for exam ple, a com put er running Windows.

77

Oracle Distributed Systems

3 .1 .1 6 REM OTE_ OS_ ROLES Dat at ype: Boolean Default : FALSE Range: TRUE or FALSE The REMOTE_OS_ROLES param et er det erm ines how Oracle enforces role privileges. I f you specify FALSE, Oracle uses t he role definit ions from t he dat abase, as seen in DBA_ROLE_PRI VS. I f you specify TRUE, Oracle uses operat ing syst em roles for rem ot e client s. This m et hod is relevant only for roles using operat ing syst em validat ion, t hat is, t hose t hat have been creat ed wit h t he following synt ax: CREATE ROLE {rolename} IDENTIFIED EXTERNALLY which im plies t hat t he param et er REMOTE_OS_ROLES is also set t o TRUE. Oracle validat es users of operat ing syst em validat ed roles different ly for each operat ing syst em . For exam ple, under Unix, m em bers of group ora_sid_role are m em bers of t he OS validat ed group role in t he dat abase inst ance wit h ORACLE_SI D sid.

3 .1 .1 7 REPLI CATI ON _ D EPEN D EN CY_ TRACKI N G ( Or a cle 8 ) Dat at ype: Boolean Default : TRUE Range: TRUE or FALSE The REPLI CATI ON_DEPENDENCY_TRACKI NG param et er det erm ines whet her Oracle m aint ains inform at ion about t ransact ional dependency which is required for parallel propagat ion of replicat ed DML. Oracle recom m ends using t he default value of TRUE unless your replicat ed t ables do not undergo DML.

3 .1 .1 8 SN APSH OT_ REFRESH _ I N TERVAL Dat at ype: I nt eger Default : 60 Range: 1 t hrough 3600 The SNAPSHOT_REFRESH_I NTERVAL param et er is obsolet e. See t he JOB_QUEUE_I NTERVAL param et er.

78

Oracle Distributed Systems

3 .1 .1 9 SN APSH OT_ REFRESH _ PROCESSES Dat at ype: I nt eger Default : 0 Range: 0 t hrough 36 The SNAPSHOT_REFRESH_PROCESSES param et er is obsolet e. See t he JOB_QUEUE_I NTERVAL param et er.

3 .2 D a t a ba se Lin k s Dist ribut ed Oracle dat abases are built on dat abase links. I n a nut shell, a dat abase link is a connect ion from one dat abase t o anot her t hat is available t o users having proper privileges any t im e bot h dat abases are available. The purpose of dat abase links is t o m ake rem ot e dat a available for queries and, in som e cases, updat es. Because a dat abase link is essent ially a stored login t o a rem ot e dat abase, t he DBA m ust t ake care t o ensure t hat it does not com prom ise t he securit y of eit her t he local or t he rem ot e dat abase. This sect ion discusses dat abase link nam ing convent ions, t he different t ypes of dat abase links, different m et hods of creat ing t hem , rest rict ions, securit y concerns, and how t o report on t hem .

3 .2 .1 Globa l N a m e s a n d D a t a ba se Lin k s I f t he GLOBAL_NAMES I NI T.ORA param et er is set t o it s default value of FALSE, you can use any nam e you want for a dat abase link. I worked at one sit e where one developer was part ial t o t he nam e " Fred" for t he links he creat ed. I nform alit y m ay be accept able in a sm all organizat ion, but not where m ore t han t hree or four dat abases are in use. The m ost int uit ive approach is t o use t he nam ing convent ion DB_NAME .DB_DOMAI N for all dat abase links, for exam ple, D7CA.BI GWHEEL.COM. Set t ing GLOBAL_NAMES t o TRUE enforces t his convent ion of dat abase links having t he sam e nam e as t he dat abase t o which t hey connect . I f you are using advanced replicat ion, you m ust set t his param et er t o TRUE. Not e t hat you can change t he global nam e of any dat abase inst ance wit h an ALTER DATABASE st at em ent : ALTER DATABASE RENAME GLOBAL_NAME TO new_name The global nam ing convent ion offers several advant ages: Consist ency Adm inist rat ors and users know im m ediat ely t o what dat abase a given link connect s, whet her t hey are reviewing t race files or source code or sim ply browsing t he dat abase.

79

Oracle Distributed Systems Uniqueness Set t ing GLOBAL_NAMES t o TRUE guarant ees t hat all dat abases in t he net work com m unit y will have a unique nam e. Com pat ibilit y wit h fut ure releases Oracle has hint ed in various docum ent s t hat global nam ing will be a requirem ent in t he fut ure. For exam ple, t he release not es for Version 7.0.13 st at e: " You are encouraged t o set t his init ializat ion param et er t o TRUE as fut ure releases m ay depend on it ." I n short , t here is really no reason not t o use global nam ing.

Oracle's Designer 2000 t ool requires t hat GLOBAL_NAMES be set t o FALSE if you want t o use it t o reverse- engineer a schem a from a rem ot e dat abase, because it creat es dat abase links nam ed for t he schem a. We have set t he param et er t o FALSE during t he reverse- engineering procedure and set it back t o TRUE when t he procedure was com plet e.

3 .2 .2 Pu blic, Pr iva t e , a n d Globa l D a t a ba se Lin k s Dat abase links can be eit her public or privat e. Public links are available t o all dat abase users, while privat e links are available only t o t he creat or. These levels of visibilit y are analogous t o public and privat e synonym s. Because public dat abase links provide a window int o t he rem ot e dat abase t hrough which any user can peer, t hey should not be used indiscrim inat ely.

3 .2 .2 .1 W he n t o u se pu blic da t a ba se lin k s A public dat abase link is appropriat e if m any users of an applicat ion m ust access a rem ot e obj ect and it is unreasonable or im possible t o creat e individual account s for each of t hem in t he rem ot e dat abase. I n t his sit uat ion, t he DBA can creat e a single account in t he rem ot e dat abase t o which t he dat abase link connect s. Remote Site (D7NY.BIGWHEEL.COM): CREATE USER fromd7ca IDENTIFIED BY waxwings / GRANT CREATE SESSION TO fromd7ca / GRANT remote_browse TO fromd7ca /

Application Site (D7CA.BIGWHEEL.COM): CREATE PUBLIC DATABASE LINK D7NY.BIGWHEEL.COM CONNECT TO fromd7ca IDENTIFIED BY waxwings USING 'remotesite';

80

Oracle Distributed Systems I f you are t he DBA at t he rem ot e sit e ( D7NY.BI GWHEEL.COM) , you m ight also consider assigning a profile t o " from d7ca" which lim it s t he account 's connect t im e, concurrent sessions, and so on. Public dat abase links are also required for cert ain configurat ions of advanced replicat ion. Refer t o Chapt er 10, for det ails.

3 .2 .2 .2 W he n t o u se pr iva t e da t a ba se lin k s From a securit y st andpoint , privat e dat abase links are preferable t o public links because privat e links are available only t o t heir creat or. I n general, you should opt for a privat e dat abase link whenever possible and view t he public link as a special case or last resort . Specific scenarios t hat call for privat e links include: • • • •

Links t hat are used for snapshot refreshes Links t hat are used in t riggers Links t hat connect t o a privileged account in t he rem ot e dat abase Cert ain configurat ions of advanced replicat ion ( see Chapt er 10)

I n short , use privat e dat abase links if you can, public dat abase links if you m ust .

3 .2 .2 .3 W h e n t o u se globa l da t a ba se lin k s The Oracle Nam es product aut om at ically creat es global dat abase links bet ween all dat abases in your net worked environm ent . Unlike public and privat e dat abase links, which Oracle st ores in t he dat a dict ionary, global dat abase links reside in t he net work definit ion file. This feat ure offers t he obvious advant age of elim inat ing t he need t o creat e dat abase links m anually for all of your dat abase inst ances. By default , global dat abase links do not use a CONNECT TO clause, which m eans t hat a user account can view dat a over a global dat abase link only if t he sam e user account exist s in t he rem ot e dat abase wit h t he sam e password. These links provide t he sam e level of securit y as privat e dat abase links and can be used according t o t he sam e guidelines. You can also override Oracle Nam es' default behavior and creat e global dat abase links t hat do use a CONNECT TO clause by supplying t his inform at ion in t he Net work Manager configurat ion t ool. I f you choose t o creat e t his t ype of global dat abase link, you should consider t he link t o be public and t ake precaut ions accordingly.

3 .2 .3 Cr e a t in g D a t a ba se Lin k s The CREATE DATABASE LI NK st at em ent has a num ber of com ponent s t hat det erm ine various propert ies of t hedat abase link. These include: • • •

The PUBLI C qualifier The SHARED qualifier ( Oracle8) The connect ion qualifier

81

Oracle Distributed Systems • • • •

The The The The

CONNECT clause CURRENT_USER qualifier ( Oracle8) USI NG clause AUTHENTI CATED clause ( Oracle8)

The synt ax for t he CREATE DATABASE LI NK st at em ent has m any opt ions. The creat ion of a dat abase link can be as sim ple as CREATE DATABASE LINK D7CA.BIGWHEEL.COM / or as com plex as CREATE SHARED PUBLIC DATABASE LINK D7CA.BIGWHEEL.COM@TCPIP CONNECT TO cdye IDENTIFIED BY yankeeclip AUTHENTICATED BY linkauth IDENTIFIED BY fingerprints USING 'prodsales' /

Ge t t in g I t Righ t t h e Fir st Tim e Whenever you creat e a dat abase link, it is well wort h t he effort t o confirm t he validit y of t he link im m ediat ely. Doing so can save hours of debugging and t roubleshoot ing lat er on. For exam ple: SQL> 2 3 4

CREATE DATABASE LINK D7NY.BIGWHEEL.COM CONNECT TO cdye IDENTIFIED BY yankeeclip USING 'd7ny' /

Database link created. SQL> SELECT * FROM [email protected] 2 / GLOBAL_NAME -----------------------------------------------------------------D7NY.BIGWHEEL.COM 1 row selected. I n t he sect ions t hat follow, we'll exam ine t he com ponent s of t he CREATE DATABASE LI NK st at em ent in det ail.

3 .2 .3 .1 Pr e r e qu isit e s for cr e a t in g da t a ba se lin k s

82

Oracle Distributed Systems To creat e a privat e dat abase link, users m ust have t he CREATE DATABASE LI NK syst em privilege. To creat e a public dat abase link, users m ust have t he CREATE PUBLI C DATABASE LI NK syst em privilege. I n addit ion, t he account t o which t he dat abase link connect s m ust have CREATE SESSI ON privileges. Not e t hat t hese privileges m ay be grant ed t hrough a role; direct grant s of t he syst em privileges are not required.

3 .2 .3 .2 Th e PUBLI C qu a lifie r The opt ional PUBLI C qualifier specifies a public dat abase link. Guidelines for when and why t o use public dat abase links are included earlier in Sect ion 3.2.2.1.

3 .2 .3 .3 The SH ARED qua lifie r The opt ional SHARED qualifier is a new feat ure of Oracle8. Shared dat abase links can pot ent ially reduce t he num ber of net work connect ions bet ween t he local and rem ot e dat abases. Not e t hat shared dat abase links require t hat t he local dat abase be running m ult i- t hreaded server ( MTS) and t hat you supply an AUTHENTI CATED clause. Shared dat abase links work by reusing an exist ing connect ion from a local MTS server process t o t he rem ot e dat abase. A session can share t he exist ing connect ion t o t he rem ot e dat abase only if it uses t he sam e dat abase link. Thus, applicat ions t hat are good candidat es for shared dat abase links are t hose whose users ut ilize t he sam e public dat abase link and t hose whose users log on t o a single user account , as is t he case wit h several t hird- part y Oracle applicat ions.

Shared dat abase links can act ually increase t he num ber of net work connect ions. This undesirable sit uat ion can arise because repeat ed access t o a shared link can pot ent ially est ablish as m any connect ions as you have m ult i- t hreaded server processes. Thus, if t he link has fewer users t han you have m ult i- t hreaded server processes, it should not be a shared link.

3 .2 .3 .4 Th e con n e ct ion qu a lifie r Oracle8 allows you t o specify m ult iple connect ion pat hs t o t he sam e dat abase, which is useful if you are running Oracle parallel server or m ult iple net work prot ocols. For exam ple, a sit e t hat runs bot h TCP/ I P and DECnet could creat e t wo dat abase links t o t he sam e dat abase using each prot ocol: CREATE DATABASE LINK D7CA.BIGWHEEL.COM@TCPIP USING 'prodsales_tcpip' / CREATE DATABASE LINK D7CA.BIGWHEEL.COM@DECNET USING 'prodsales_decnet' /

83

Oracle Distributed Systems The connect ion qualifier is t he port ion following t he " @" sign in t he dat abase link nam e. I n order for t he preceding exam ple t o funct ion as desired, t he connect st rings " prodsales_t cpip" and " prodsales_decnet " would have t o be configured t o use t he appropriat e prot ocol; t he connect ion qualifier it self is m erely a m nem onic. I n t his case, t he t nsnam es.ora file cont ains t he following ent ries: prodsales_tcpip.bigwheel.com = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = TCPIP) (PROTOCOL = TCP) (Host = socrates.bigwheel.com) (Port = 1521) ) ) (CONNECT_DATA = (SID = D7CA) (GLOBAL_NAME = d7ca.bigwheel.com) ) ) prodsales_decnet.bigwheel.com = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = DECNET) (NODE = socrates.bigwheel.com) (OBJECT = LSNR) ) ) (CONNECT_DATA = (SID = D7CA) (GLOBAL_NAME = d7ca.bigwheel.com) ) )

3 .2 .3 .5 Th e CON N ECT cla u se The CONNECT clause is t he opt ional port ion of t he CREATE DATABASE LI NK st at em ent which supplies a usernam e and password; for exam ple: CONNECT TO cdye IDENTIFIED BY yankeeclip The connect clause creat es a fixed- user dat abase link, which m eans t hat everybody who accesses it will connect t o t he rem ot e dat abase wit h t he sam e usernam e and password. Fixed- user dat abase links can be appropriat e for public dat abase links for which a specially designat ed account exist s at t he rem ot e dat abase or for privat e links t hat connect t o a different user at t he rem ot e dat abase. I f you om it t he CONNECT clause, t he dat abase link will at t em pt t o connect t o t he rem ot e dat abase using t he sam e usernam e and password as t he user who creat ed t he link.

84

Oracle Distributed Systems

3 .2 .3 .6 Th e CURREN T_ USER qua lifie r The opt ional CURRENT_USER qualifier causes t he dat abase link t o connect t o t he rem ot e dat abase under t he session's current securit y cont ext . Thus, if t he user is execut ing a procedure, package, or t rigger from anot her schem a when it accesses t he dat abase link, t he link will connect t o t he rem ot e dat abase as t he owner of t he obj ect being execut ed. I f t he session is not execut ing an obj ect from anot her schem a, t he link will connect under t he sam e account as t he session. This opt ion is available only if you have configured t he current user as a global user wit h an ent erprise aut hent icat ion service such as Oracle Securit y Server ( OSS) .

3 .2 .3 .7 Th e USI N G cla u se The opt ional USI NG clause supplies t he connect st ring t hat t he dat abase link is t o use: USING 'prodsales' Alt hough t his clause is opt ional, you m ust supply it unless t here is already a public dat abase link t o t he dest inat ion dat abase using t he desired connect st ring. ( See Sect ion 3.2.6 for m ore inform at ion.)

3 .2 .3 .8 The AUTH EN TI CATED cla use The AUTHENTI CATED clause is required if you are using shared dat abase links: AUTHENTICATED BY linkauth IDENTIFIED BY fingerprints The account specified in t he AUTHENTI CATED clause m ust exist in t he rem ot e dat abase wit h CREATE SESSI ON privileges. This link does not connect as t his user. Rat her, Oracle uses t his clause as an added m easure of securit y.

3 .2 .4 D r oppin g D a t a ba se Lin k s The DROP DATABASE LI NK st at em ent has t he synt ax: DROP [PUBLIC] DATABASE LINK dblink; where dblink is t he nam e of t he link. To drop a privat e dat abase link, you m ust be connect ed as t he owner of t he dat abase link. You can neit her creat e nor drop privat e dat abase links out side of your own schem a. I n order t o drop a public dat abase link, you m ust have t he DROP PUBLI C DATABASE LI NK syst em privilege, eit her t hrough a direct grant or t hrough a role.

85

Oracle Distributed Systems

3 .2 .5 Acce ssin g D a t a ove r a D a t a ba se Lin k You can use a dat abase link t o access rem ot e dat a essent ially as t hough it were local. Oracle does handle dist ribut ed queries and updat es different ly from local ones, but t o t he end user t hese differences are irrelevant . ( The DBA and developer, however, should consult t he upcom ing Sect ion 3.3.) Oracle est ablishes your securit y cont ext in t he rem ot e dat abase based on t he rem ot e schem a t o which t he link connect s. This schem a is • • •

The user specified in t he link's CONNECT TO clause, if t his clause is used. The sam e as t he current user in t he local dat abase if t he link is creat ed wit h t he CURRENT USER qualifier, and t he local user is execut ing a PL/ SQL obj ect ( procedure, package, or t rigger) . The sam e as t he local connect ed user if neit her of t he preceding is t rue.

To reference a rem ot e obj ect , append an " @" sign and t he nam e of t he dat abase link t o t he nam e of t he obj ect : SQL> SELECT product_id, catalog_id, description, audit_date 2 FROM [email protected] 3 / PRODUCT_ID -------------1000001 11:16:53 1000002 11:16:53 1000003 11:16:53 1000004 11:16:54 1000005 11:16:54 1000006 11:16:54 1000007 11:16:54 1000008 11:16:54 1000010 11:16:54 1000011 11:16:54 1000012 11:16:54 1000013 11:16:54 1000014 11:16:54 1000015 11:16:54

CATALOG_ID DESCRIPTION ---------- -----------------------------

AUDIT_DATE ---------------

BIKE-0002

Boys 5 Speed Touring

28-Oct-1997

BIKE-0003

Girls 5 Speed Touring

28-Oct-1997

BIKE-0004

Mens 10 Speed Touring

28-Oct-1997

BIKE-0005

Mens 18 Speed Touring

28-Oct-1997

BIKE-0006

Mixte 10 Speed Touring

28-Oct-1997

BIKE-0007

Mixte 18 Speed Touring

28-Oct-1997

BIKE-0008

Mens 12 Speed Mountain Bike

28-Oct-1997

BIKE-0009

Mens 18 Speed Mountain Bike

28-Oct-1997

BIKE-0011

Mens 10 Speed Alloy Touring

28-Oct-1997

BIKE-0013

Mens 12 Speed Racing

28-Oct-1997

BIKE-0014

Mens 18 Speed Racing

28-Oct-1997

BIKE-0015

Mens 12 Speed Alloy Racing

28-Oct-1997

BIKE-0016

Mens 18 Speed Alloy Racing

28-Oct-1997

BIKE-0017

Womens 18 Speed Alloy Racing

28-Oct-1997

86

Oracle Distributed Systems 14 rows selected.

3 .2 .6 H ow D a t a ba se Lin k s Ar e Re solve d A dat abase can easily have m ult iple dat abase links wit h t he sam e nam e. For exam ple, several users m ay have privat e links t o t he sam e rem ot e dat abase, and t here m ay also be a public dat abase link t o t his rem ot e sit e. Oracle requires a usernam e and a connect st ring t o est ablish a connect ion over a dat abase link. Oracle does not necessarily obt ain t hese t wo pieces of inform at ion from a single dat abase link. So, when a user references an obj ect at t he rem ot e sit e, how does Oracle det erm ine how t o est ablish t he rem ot e connect ion?

3 .2 .6 .1 Th e a lgor it hm When a user references a rem ot e obj ect , Oracle const ruct s t he access pat h t o t he obj ect following t hese st eps: 1. I f t he reference t o t he dat abase link cont ains only t he dat abase nam e port ion, append t he local dom ain nam e t o t he dat abase nam e. For exam ple, " d7ca" becom es D7CA.BI GWHEEL.COM. 2. I f t he user has a privat e dat abase link t o t he rem ot e dat abase: a. I f t he privat e link cont ains bot h a CONNECT TO clause and a USI NG clause, use t his inform at ion t o est ablish t he connect ion. b. I f t he privat e link cont ains a USI NG clause only, est ablish t he connect ion using t he local user's usernam e and password at t he rem ot e dat abase. c. I f t he privat e link cont ains a CONNECT TO clause only, look for a public dat abase link t o det erm ine t he USI NG clause. d. I f t he privat e link cont ains neit her a CONNECT TO clause nor a USI NG clause, look for a public dat abase link t o det erm ine t he USI NG clause. 3. I f t here is a public dat abase link t o t he rem ot e dat abase: a. I f a privat e dat abase link also exist s but wit hout a USI NG clause, obt ain t he USI NG clause from t his link if possible. b. I f no privat e dat abase link exist s, and t he public link cont ains a CONNECT TO and a USI NG clause, use t his inform at ion t o est ablish t he connect ion. c. I f no privat e dat abase link exist s, and t he public link cont ains a USI NG clause only, est ablish t he connect ion using t he local user's usernam e and password at t he rem ot e dat abase. d. I f no privat e dat abase link exist s, and t he public link does not cont ain a USI NG clause, look for a global dat abase link t o det erm ine t he USI NG clause. 4. I f a global dat abase link t o t he rem ot e dat abase exist s: a. I f neit her a privat e nor a public dat abase link exist s, use t his link t o det erm ine t he USI NG clause for t he rem ot e dest inat ion. I f t his link cont ains a CONNECT clause, use t he specified usernam e and password; ot herwise, use t he local user's usernam e and password at t he rem ot e sit e. b. I f a privat e and/ or public dat abase link exist s, but t he USI NG clause is not specified, use t his link t o det erm ine t he USI NG clause.

87

Oracle Distributed Systems

3 .2 .6 .2 Ex a m ple of da t a ba se lin k r e solu t ion I f we creat e a public dat abase link specifying a USI NG clause only, we can t hen creat e privat e dat abase links wit hout having t o specify eit her a CONNECT clause or a USI NG clause for all users who have account s at t he rem ot e dat abase, wit h t he sam e password: SQL> connect system@d7ny Enter password: Connected. SQL> CREATE PUBLIC DATABASE LINK D7CA.BIGWHEEL.COM 2 USING 'd7ca' 3 / Database link created. SQL> connect cdye Enter password: Connected. system@d7ny SQL> CREATE DATABASE LINK D7CA.BIGWHEEL.COM 2 / Database link created. system@d7ny SQL> SELECT * FROM [email protected] 2 / GLOBAL_NAME --------------------------------------------------------------------D7CA.BIGWHEEL.COM 1 row selected. I n t his exam ple, t he st at em ent SELECT * FROM [email protected] uses cdye's privat e dat abase link t o det erm ine t he usernam e and password t o use at t he rem ot e sit e, and uses t he public dat abase link t o det erm ine t he connect st ring for D7CA.BI GWHEEL.COM, t hat is, " d7ca" .

This exam ple works because t he cdye account exist s in t he local and rem ot e dat abases wit h t he sam e password, and t he local dat abase has t he I NI T.ORA param et er GLOBAL_NAMES set t o TRUE.

3 .2 .7 List in g I n for m a t ion Abou t D a t a ba se Lin k s The dat a dict ionary views for dat abase link inform at ion are DBA_DB_LI NKS, A LL_DB_LI NKS, and USER_DB_LI NKS. Table 3.2 describes t he fields in t hese views.

88

Oracle Distributed Systems

Table 3.2. DBA_DB_LINKS, ALL_DB_LINKS, and USER_DB_LINKS Field Descriptions Field Name

Description

Owner ( DBA_DB_LI NKS and The owner of t he dat abase link. ALL_DB_LI NKS only) DB_LI NK

The nam e of t he dat abase link. This is t he rem ot e dat abase nam e and t he dom ain nam e.

Usernam e

The usernam e specified in t he CONNECT TO clause. NULL if t he CONNECT TO clause is not supplied.

Password ( USER_DB_LI NKS The password specified in t he CONNECT TO clause. only) NULL if t he CONNECT TO clause is not supplied. Host

The SQL* Net connect st ring t o t he rem ot e dat abase. This corresponds t o t he USI NG clause. NULL if t he USI NG clause is not supplied.

Creat ed

Dat e t he dat abase link was creat ed.

The following script list s all dat abase links t hat exist in t he dat abase . --------------------------------------------------------------------------- Filename: links.sql -- Purpose: Reports all database links in the database. -- Author: Chas. Dye ([email protected]) -- Date: 28-May-1997 -------------------------------------------------------------------------column column column column column

owner db_link username host created

heading heading heading heading heading

"Owner" "DB Link" "Username" "Host" "Created"

format format format format format

a10 a20 a12 a12 a20

SELECT

owner, db_link, username, host, TO_CHAR(created, 'DD-Mon-YYYY HH24:MI:SS') created FROM dba_db_links ORDER BY db_link, owner / Here is a sam ple of t he out put : system@d7ny SQL> @links Owner ------------CDYE 12:19:53

DB Link -----------------D7CA.BIGWHEEL.COM

Username ----------

Host ------

Created ----------------04-Dec-1997

89

Oracle Distributed Systems PUBLIC 22:24:35 REPADMIN 22:32:05 SPROCKET 22:42:24 SYS 22:27:21

D7CA.BIGWHEEL.COM

d7ca

01-Oct-1997

D7CA.BIGWHEEL.COM

REPADMIN

01-Oct-1997

D7CA.BIGWHEEL.COM

SPROCKET

01-Oct-1997

D7CA.BIGWHEEL.COM

REPSYS

01-Oct-1997

5 rows selected. Not e t hat alt hough t he password field appears only in t he USER_DB_LI NKS dat a dict ionary view, t he unencrypt ed password is visible in t he SYS.LI NK$ t able. Anybody wit h t he DBA role or t he SELECT ANY TABLE syst em privilege can see t his t able; for exam ple: SQL> select userid, password 2 from sys.link$ 3 where password is not null; USERID ------------REPSYS SPROCKET REPSYS REPADMIN OCLASS

PASSWORD -----------------------------ASHTABULA PEPPERPIKE ORCHARDPARK HAVERFORD NICHOLS

5 rows selected. Sim ilarly, t he usernam e and password supplied in t he Oracle8 AUTHENTI CATED clause are visible in t he SYS.LI NK$ fields AUTHUSR and AUTHPWD, respect ively. For t his reason, you should exercise ext rem e discret ion when creat ing dat abase links t hat specify a CONNECT TO or AUTHENTI CATED clause.

3 .2 .8 D a t a Re loca t ion w it h D a t a ba se Lin k s Moving dat a from one dat abase t o anot her is com m onplace for DBAs and developers. For exam ple, DBAs m ay need t o ext ract dat a from a product ion online t ransact ion processing ( OLTP) syst em int o a dat a warehouse, or developers m ay need t o copy a subset of dat a from a product ion dat abase int o a m aint enance dat abase t o analyze a problem or t o t est soft ware against product ion dat a volum es. Alt hough t he export and im port ut ilit ies provide t he funct ionalit y t o m ove ent ire t ables from one dat abase t o anot her, t hey do not allow for t he horizont al and/ or vert ical dat a part it ioning t hat is oft en required; t he export and im port ut ilit ies have only t able- level granularit y. The dat abase link is t he answer when you need t o copy a horizont al or vert ical subset of dat a from one dat abase t o another. For exam ple, suppose we have a t able SALES_I TEMS t hat logs sales t ransact ions, defined as follows: SQL> desc sales_items Name Null? ------------------------

Type -----------------

90

Oracle Distributed Systems SALES_ITEM_ID STORE_ID REGISTER_ID SALES_ASSOC_ID PRODUCT_ID PRICE PAY_METHOD CUST_POSTCODE AUDIT_DATE AUDIT_USER GLOBAL_NAME

NOT NOT NOT NOT NOT NOT NOT

NULL NULL NULL NULL NULL NULL NULL

NOT NULL NOT NULL NOT NULL

NUMBER(9) NUMBER(9) NUMBER(9) NUMBER(9) NUMBER(9) NUMBER(10, 2), CHAR(1) VARCHAR2(12) DATE VARCHAR2(30) VARCHAR2(20)

We wish t o ext ract sales t ransact ions from t he norm alized SALES_I TEMS t able in t he OLTP dat abase int o t he SALES_FACTS t able in our dat a warehouse where t he m arket ing expert s can generat e t heir m arket ing segm ent at ion report s. SQL> desc sales_facts Name Null? ---------------------JULIAN_DAY NOT NULL PRODUCT_ID NOT NULL STORE_ID NOT NULL DOLLARS_SOLD NOT NULL UNITS_SOLD NOT NULL

Type ----------------NUMBER(9) NUMBER(9) NUMBER(9) NUMBER(10, 2) NUMBER(6)

The following exam ple loads sum m arized sales dat a from t he SALES_I TEMS t able at t he rem ot e dat abase D7CA.BI GWHEEL.COM int o t he SALES_FACTS t able: INSERT INTO sales_facts ( julian_day, product_id, store_id, dollars_sold, units_sold ) ( SELECT TO_CHAR( audit_date, 'J'), product_id, store_id, sum(dollars_sold), count(*) FROM [email protected] GROUP BY audit_date, product_id, store_id ) / An ext ract of t his t ype is sim ply not possible wit h t he export / im port ut ilit ies.

You cannot use t he I NSERT I NTO t able_nam e ... SELECT ... t o load LONG, LONG RAW, or LOB dat a. This rest rict ion exist s regardless of whet her a dat abase link is involved; it is a rest rict ion of SQL. You can use t he COPY com m and t o relocat e dat a, including

91

Oracle Distributed Systems

LONG and LONG RAW dat a ( under 32K) from one dat abase t o anot her. Alt hough t he COPY com m and does not use a dat abase link, it funct ions in a sim ilar way.

3 .2 .9 Re st r ict ion s on D ist r ibu t e d Ope r a t ion s ove r D a t a ba se Lin k s Not e t he following rest rict ions: • • • •

Cert ain operat ions and const ruct s are not support ed over dat abase links; for exam ple, it is not possible t o grant privileges on rem ot e obj ect s referenced t hrough a dat abase link, and in Oarcle8 it is not possible t o DESCRI BE rem ot e t ables and views. Referent ial int egrit y cannot be defined or enforced over a dat abase link. Dat abase roles cannot be grant ed t o users in a rem ot e dat abase. Queries using hash query j oins cannot use m ult i- t hreaded server ( MTS) connect ions.

3 .3 D ist r ibu t e d Qu e r ie s a n d Tr a n sa ct ion s The dat abase link is t he key t o locat ion t ransparency in Oracle; you can perform operat ions on obj ect s in m ult iple dat abases unfet t ered wit h det ails about where obj ect s reside, net work prot ocols, dat abase nam es, and so on. However, if you are a DBA or a developer, you can creat e m ore efficient and robust syst em s by underst anding t he m echanism s behinddist ribut ed queries and t ransact ions. Table 3.3 list s t he operat ions t hat Oracle support s in a dist ribut ed environm ent .

Table 3.3. Supported Distributed Operations Supported DML

Supported Transaction Control

SELECT

COMMI T

SELECT FOR UPDATE

ROLLBACK

I NSERT SAVEPOI NT UPDATE

ROLLBACK TO SAVEPOI NT

DELETE LOCK TABLE

3 .3 .1 Be h in d t h e Sce n e s of a D ist r ibu t e d Tr a n sa ct ion As wit h local t ransact ions, consist ency is a fundam ent al requirem ent of dist ribut ed t ransact ions. A dist ribut ed t ransact ion m ust eit her succeed at all part icipat ing nodes

92

Oracle Distributed Systems or fail at all part icipat ing nodes. The classic exam ple is t he t ransfer of funds from one inst it ut ion t o anot her, each wit h it s own dat abase. The t ransfer m ust debit t he payer in one dat abase and credit t he payee in t he ot her. These updat es m ust eit her succeed in bot h dat abases or fail in bot h dat abases. Oracle ensures t his t ransact ional consist ency t hrough a m echanism called t he t wophase com m it , so nam ed because t ransact ion com m it s occur in t wo st ages, t he prepare phase and t he com m it phase. I 'll exam ine t he act ivit ies associat ed wit h t hese phases in t he sect ions t hat follow.

3 .3 .1 .1 Tw o- pha se com m it : The pa r t icipa nt s Each part icipant in a dist ribut ed t ransact ion fulfills one or m ore roles, each wit h specific responsibilit ies during t he t wo- phase com m it . The roles are: Client A client is a m achine t hat references dat a in one or m ore rem ot e dat abases. A client m ay or m ay not be a dat abase server. Local coordinat or A local coordinat or is a dat abase server t hat part icipat es in a dist ribut ed t ransact ion t hat accesses dat a on rem ot e dat abase servers. The local coordinat or is responsible for t he following t asks: •

•

•

•

Passing t ransact ion st at us inform at ion am ong t he dat abase servers whose dat a it accesses I nit iat ing queries on t he rem ot e dat abase servers, possibly on behalf of ot her dat abase servers ( if necessary) Processing queries originat ing from rem ot e dat abase servers ( if necessary) Ret urning result s of queries t o t he ot her dat abase servers ( if necessary)

Com m it point sit e The com m it point sit e effect s com m it s or rollbacks at all part icipat ing nodes, as inst ruct ed by t he global coordinat or. ( The com m it point sit e and t he global coordinat or can be one and t he sam e.) The sit e wit h t he highest set t ing of t he I NI T.ORA param et er COMMI T_POI NT_STRENGTH is t he com m it point sit e, wit h t he following except ions: • •

•

A read- only node cannot be a com m it point sit e. I f t wo or m ore nodes have t he sam e COMMI T_POI NT_STRENGTH, t he det erm inat ion of t he com m it point sit e is not specified. I f t he global coordinat or is unable t o init iat e t he prepare phase at all part icipat ing nodes, no com m it point sit e is designat ed and t he global coordinat or init iat es a rollback at all relevant sit es.

Global coordinat or

93

Oracle Distributed Systems The global coordinat or is t he dat abase server from which t he dist ribut ed t ransact ion originat es. I t is responsible for t he following: • • •

•

•

Passing SQL inst ruct ions t o all direct ly referenced dat abase servers I nit iat ing t he prepare phase of t he t wo- phase com m it on all part icipat ing nodes except for t he com m it point sit e Upon successful com plet ion of t he prepare phase at all part icipat ing sit es, request ing t he com m it point sit e t o com m it t he t ransact ion Upon unsuccessful com plet ion of t he prepare phase at one or m ore part icipat ing sit es, init iat ing a rollback of t he t ransact ion at all nodes Ensuring t hat all part icipant s conclude t he t ransact ion wit h t he sam e out com e as t he com m it point sit e—t hat is, t he t ransact ion eit her succeeds everywhere or fails everywhere

The chain of connect ions from t he global coordinat or t o t he local coordinat or( s) and com m it point sit e is known as t he session t ree. The global coordinat or is always at t he t op of t he session t ree.

3 .3 .1 .2 Tw o- ph a se com m it : Ex pla in e d As m ent ioned earlier, t he t wo phases of t he t wo- phase com m it are t he prepare phase and t he com m it phase. During t he prepare phase, t he global coordinat or cont act s all local coordinat ors and inst ruct s t hem t o perform what ever st eps are necessary t o be in a posit ion t o com m it t heir port ion of t he dist ribut ed t ransact ion. These st eps include t he following: • • • •

Det erm ining whet her t he t ransact ion perform s any local DML Request ing any ot her dependent nodes t o prepare ( t his st age is called " collect ing" ) ; t he global coordinat or m ust always perform t he collect ing st ep; local coordinat ors perform it only if t hey have dependent s perform it Obt aining requisit e locks Writ ing t he changes required by t he t ransact ion t o t he redo log

Aft er com plet ing ( or at t em pt ing t o com plet e) t hese t asks, t he local coordinat or report s one of t hree possible st at uses t o t he global coordinat or: Prepared The sit e has m ade all changes required by t he t ransact ion and has writ t en t he changes t o t he redo log. Any dependent sit es have done t he sam e. Read- only The sit e has det erm ined t hat t he t ransact ion does not m odify any local dat a, so it need not prepare and does not part icipat e in t he com m it phase of t he t ransact ion. Abort

94

Oracle Distributed Systems The sit e is unable t o prepare. The t ransact ion will release any lat ches or locks it m ay have obt ained before failing. When t he global coordinat or receives an abort st at us from a sit e, it rolls back t he t ransact ion at all ot her sit es. Not e t hat t he com m it point sit e does not part icipat e in t he prepare phase. The rat ionale is t hat t he com m it point sit e is t he m ost reliable sit e and t herefore is t he m ost likely t o be able t o com m it it s port ion of t he t ransact ion. Since t he com m it point sit e is t he m ost reliable, it is t he m ost crit ical as well, and t herefore should not be required t o allocat e resources for t he prepare phase t o a t ransact ion t hat requires success on several ot her less reliable nodes. I f all local coordinat ors report back t o t he global coordinat or wit h a st at us of prepared, t he t ransact ion is in a st at e of in- doubt unt il a com m it or rollback is issued. We are now ready for t he com m it phase, which consist s of t he t ransact ion's act ual com m it or rollback. During t he com m it phase: •

• • •

• •

The global coordinat or inst ruct s t he com m it point sit e t o com m it it s port ion of t he t ransact ion. The com m it point sit e perform s it s com m it . At t his point t he ent ire dist ribut ed t ransact ion is considered t o be com m it t ed because even if t here is a com m unicat ion failure, all ot her sit es will aut om at ically com m it t heir port ion( s) of t he t ransact ion when com m unicat ion is reest ablished. The com m it point sit e inform s t he global coordinat or t hat it has com plet ed t he com m it . The com m it point sit e ret ains inform at ion about t he t ransact ion in t he dat a dict ionary. The global coordinat or inst ruct s t he local coordinat ors t o com m it , and com m it s it s port ion of t he t ransact ion t oo. All non- com m it point sit es writ e an addit ional ent ry t o t heir redo logs indicat ing t hat t he t ransact ion is com m it t ed, and release any locks t hat t hey m ay have acquired for t he t ransact ion. They also inform any of t heir children on t he session t ree t o perform com m it s. Local coordinat ors inform t he global coordinat or of t heir com m it s. The global coordinat or inform s t he com m it point sit e of t he com m it . At t his point , t he com m it point sit e " forget s" about t he t ransact ion; inform at ion about it no longer exist s in it s dat a dict ionary.

When Oracle com m it s a dist ribut ed t ransact ion, t he syst em change num ber ( SCN) for t he t ransact ion is t he sam e at all part icipat ing sit es. Oracle uses t he highest SCN of all t he part icipat ing sit es as t he global SCN. The coordinat ion of SCNs am ong part icipant s in t he dist ribut ed t ransact ion sim plifies recovery procedures.

3 .3 .2 W h e n Th in gs Go W r on g Of course, dist ribut ed t ransact ions can fail at any point of t he t wo- phase com m it . For exam ple, a connect ion t o a local coordinat or could go down aft er t he com m it point sit e com m it s but before t he local coordinat or is inst ruct ed t o com m it . For t he m ost part , Oracle is able t o det ect and resolve t hese kinds of problem s, but in som e cases DBA int ervent ion is warrant ed.

95

Oracle Distributed Systems

Error m essages pert aining t o dist ribut ed t ransact ions fall in t he range ORA- 02040 t o ORA- 02099. Applicat ions t hat use dist ribut ed t ransact ions should include except ion handlers for all of t hese errors. Applicat ions t hat depend on t he t wo- phase com m it prot ocol m ust have det ailed st rat egies for dealing wit h t he unavailabilit y of one or m ore com m it sit es. Exam ples include having t he applicat ion ret ry t he operat ion or logging inform at ion about t he failure in an error t able t hat can be used t o execut e t he t ransact ions when t he underlying problem s are correct ed.

3 .3 .2 .1 Type s of dist r ibu t e d t r a n sa ct ion fa ilu r e s How do you know t hat you have a problem in t he first place? Abnorm al condit ions t hat occur during t he t wo- phase com m it generally are caused by a net work or server failure t hat occurs bet ween t he prepare and com m it phases. Since t he lengt h of t im e bet ween t hese phases is infinit esim al, t hese problem s are rare. The errors t hat you m ay see in t he alert log are: ORA- 02050 t ransact ion id rolled back, som e rem ot e DBs m ay be in- doubt A com m unicat ion error occurred during t he t wo- phase com m it . ORA- 02053 t ransact ion id com m it t ed, som e rem ot e DBs m ay be in- doubt The t ransact ion was com m it t ed locally, but com m unicat ion wit h one or m ore local coordinat ors has been lost . ORA- 02054 t ransact ion id in- doubt The t ransact ion is neit her com m it t ed nor rolled back locally, and com m unicat ion wit h t he global coordinat or has been lost . I n all t hree cases, t he RECO background process will resolve t he error when com m unicat ions are reest ablished, oft en before t he user or DBA discovers t he problem . Oracle will not close t hese connect ions unt il DI STRI BUTED_RECOVER_CONNECTI ON_HOLD_TI ME seconds have elapsed. I n rare cases, an in- doubt t ransact ion can cont inue t o hold locks on obj ect s if t he RECO process is not able t o resolve t he problem . I f a user at t em pt s t o perform DML on an obj ect so locked, Oracle ret urns t he error: ORA-01591 lock held by in-doubt distributed transaction id

96

Oracle Distributed Systems I n t his case, Oracle rolls back t he user's at t em pt ed t ransact ion. The DBA should now m anually com m it or roll back t he in- doubt t ransact ion. A less rare and m ore t roublesom e scenario arises when dist ribut ed t ransact ions t im e out wait ing t o acquire locks or hold locks t hem selves for an excessive am ount of t im e. I f a dist ribut ed t ransact ion cannot obt ain a required lock aft er DI STRI BUTED_LOCK_TI MEOUT seconds, Oracle ret urns an error: ORA-02049 timeout: distributed transaction waiting for lock Your only recourse is t o ret ry t he operat ion. Of course, you should det erm ine what ot her t ransact ion is holding t he lock and verify t hat no ot her problem s exist .

3 .3 .2 .2 For cin g com m it s a n d r ollba ck s of dist r ibu t e d t r a n sa ct ion s I n cases in which in- doubt t ransact ions hold locks, blocking access t o dat a, t he DBA( s) of t he sit es involved in t he dist ribut ed t ransact ion can force a com m it or rollback, t hereby releasing t he locks. I n- doubt t ransact ions m ay also hold ext ent s of a rollback segm ent , prevent ing ot her t ransact ions from using it . The dat a dict ionary views DBA_2PC_PENDI NG and DBA_2PC_NEI GHBORS provide inform at ion about t ransact ions in need of recovery so t hat t he DBA can decide whet her a com m it or rollback is appropriat e. Tables Table 3.4 and Table 3.5 sum m arize t he colum ns in t hese views.

Table 3.4. DBA_ 2PC_PENDING Data Dictionary View Column Name LOCAL_TRAN_I D

Description Local I D of t he t ransact ion. The first port ion of t his value is t he I D of t he rollback segm ent ( as seen in DBA_ROLLBACK_SEGS) for t he local t ransact ion.

GLOBAL_TRAN_I D Global t ransact ion I D, unique t o all sit es. One of t he following:

STATE

MI XED

Collect ing Prepared Com m it t ed Forced Com m it Forced Rollback D im plies t hat port ions of t he t ransact ion have been com m it t ed and port ions rolled back ( forcibly) . C indicat es Com m it

ADVI CE

R indicat es Rollback. This field is populat ed only if t he applicat ion has issued one of

97

Oracle Distributed Systems

t he st at em ent s: ALTER SESSION ADVISE COMMIT or ALTER SESSION ADVISE ROLLBACK before beginning t he dist ribut ed t ransact ion. TRAN_COMMENT

Com m it com m ent t ext . This field is populat ed only if t he applicat ion has issued a COMMI T USI NG wit h a com m ent : COMMIT COMMENT "comment text here."

FAI L_TI ME

Tim e t he record was insert ed int o t he view.

FORCE_TI ME

Tim e t he t ransact ion was forced. NULL if t he t ransact ion has not been forced.

RETRY_TI ME

Tim e t he RECO background process last at t em pt ed t o resolve t he t ransact ion.

OS_USER

Operat ing syst em user I D of t he local user who creat ed t he t ransact ion.

OS_TERMI NAL

Term inal from which t he local port ion of t he t ransact ion originat ed.

HOST

Nam e of t he m achine from which t he local t ransact ion originat ed.

DB_USER

Oracle I D of t he usernam e originat ing t he dist ribut ed t ransact ion.

GLOBAL_COMMI T# Global com m it num ber of t he t ransact ion ( if com m it t ed) .

Table 3.5. DBA_2PC_NEIGHBORS Data Dictionary View Column Name

Description

LOCAL_TRAN_I D Local I D of t he t ransact ion. Connect ion t ype: I N_OUT

I N for incom ing OUT for out going

DATABASE

For incom ing connect ions, t he client dat abase global nam e. For out going connect ions, t he dat abase link.

DBUSER_OWNER

For incom ing connect ions, t he Oracle usernam e. For out going connect ions, t he owner of t he dat abase link. Used t o locat e t he com m it point sit e.

I NTERFACE

For incom ing links, C indicat es t hat t his sit e or one of t he descendant s on an out going link is t he com m it point sit e. For out going links, C indicat es t hat t he dest inat ion dat abase DBI D is t he com m it point sit e.

98

Oracle Distributed Systems

I f we are in- doubt , I NTERFACE is N and t hen t he t op- level dat abase eit her is t he com m it point sit e or can locat e t he com m it point sit e. DBI D

The global nam e of t he rem ot e dat abase.

SESS#

Local session num ber for t he connect ion. Sessions are num bered consecut ively, st art ing wit h 1.

BRANCH

Transact ion branch. Branch I Ds for incom ing connect ions are t wobyt e hexadecim al num bers; t he first byt e is t he rem ot e parent 's session I D, and t he second byt e is it s branch I D.

The DBA can use t hese views t o det erm ine how t he dist ribut ed t ransact ion has been resolved at ot her part icipat ing sit es and act accordingly. First , query DBA_2PC_NEI GHBORS t o det erm ine whet her t he com m it point sit e is a parent ( I NTERFACE = N) . I f so, query t his dat a dict ionary view in t he DBI D dat abase; cont inue t his t race unt il you find t he dat abase where I NTERFACE is C. At t his dat abase, you can det erm ine t he st at e of t he dist ribut ed t ransact ion by querying t he DBA_2PC_PENDI NG dat a dict ionary view. I f STATE is Com m it t ed or Forced Com m it , you can com m it t he local t ransact ion: COMMIT FORCE 'local_tran_id' I f t he GLOBAL_COMMI T# is available in DBA_2PC_PENDI NG for t his t ransact ion, you should use it when you force t he t ransact ion: COMMIT FORCE 'transaction_id', GLOBAL_COMMIT# Ot herwise, if t he t ransact ion has not been com m it t ed at t he com m it point sit e, you can roll back t he local t ransact ion: ROLLBACK FORCE 'transaction_id';

3 .3 .2 .3 Te st in g r e cove r y of fa ile d dist r ibu t e d t r a n sa ct ion s Oracle provides a m eans t o force dist ribut ed t ransact ions t o fail m anually so t hat you can t est your dist ribut ed t ransact ion recovery procedures. I f you issued a com m it wit h a com m ent ORA- 2PC- CRASH- TEST- n, you can t est a variet y of scenarios, according t o t he value of n, as shown in Table 3.6.

Table 3.6. V alues of n in ORA-2PC-CRASH-TEST-n n 1

Type of Failure Induced Crash com m it point sit e aft er collect .

2

Crash non- com m it point sit e aft er collect .

3

Crash non- com m it point sit e before prepare.

4

Crash non- com m it point sit e aft er prepare.

5

Crash com m it point sit e before com m it .

6

Crash com m it point sit e aft er com m it .

7

Crash non- com m it point sit e before com m it .

99

Oracle Distributed Systems

8

Crash non- com m it point sit e aft er com m it .

9

Crash com m it point sit e before forget .

11

Crash com m it point sit e aft er forget .

3 .3 .3 Re st r ict ion s on D ist r ibu t e d Tr a n sa ct ion s Oracle im poses t he following rest rict ions on dist ribut ed t ransact ions: • • • •

All referenced LONG and LONG RAW dat a m ust be on a single server. DDL over dat abase links is not support ed. ANALYZE TABLE LI ST CHAI NED ROWS is not support ed over a dat abase link. Queries t hat begin aft er t he PREPARE phase of a dist ribut ed t ransact ion cannot access locked dat a unt il t he t ransact ion is com m it t ed or rolled back.

3 .4 D ist r ibu t e d Ba ck u p a n d Re cove r y I f you arerecovering a dat abase t hat part icipat es in dist ribut ed t ransact ions, you m ay need t o coordinat e your recovery wit h t he ot her dat abase inst ances. The good news is t hat if you perform com plet e recovery ( t he m ost com m on t ype of recovery) , you have not hing t o worry about .

We are lim it ing our discussion t o m edia recovery only, which is based on SCNs. Alt ernat ive m et hods, such as t he im port / export ut ilit ies, are not based on SCNs, and t herefore you cannot coordinat e t hem wit h dist ribut ed t ransact ions in ot her dat abases.

Table 3.7 list s t he possible recovery scenarios.

Table 3.7. Distributed Recovery Scenarios Recovery Method

Impact on Databases Participating in Distributed Transactions

Rest ore from a cold backup

All ot her dat abases m ust also be rest ored t o t he sam e point in t im e.

Com plet e m edia recovery

No act ion required.

I ncom plet e m edia recovery

All ot her dat abases m ust also be rest ored t o t he sam e point in t im e.

As Table 3.7 indicat es, t he only recovery scenarios t hat im pact ot her dat abases in t he dist ribut ed environm ent are t hose in which t he recovery is incom plet e—t hat is, up t o som e t im e in t he past . The obvious issue is t hat an incom plet e recovery m ay result in dat a t hat is inconsist ent globally because a dist ribut ed t ransact ion m ay have been com m it t ed som e t im e aft er t he t im e t o which you rest ore. Of course, if you can guarant ee t hat no such t ransact ions exist , you can recover t o a t im e in t he past wit hout involving t he ot her dist ribut ed dat abases.

100

Oracle Distributed Systems

I f you are using t he advanced replicat ion facilit ies, you m ust always perform com plet e m edia recovery in order t o guarant ee t he int egrit y of t he replicat ed environm ent .

3 .4 .1 D ist r ibu t e d Re cove r y I f you cannot avoid t he requirem ent t o recover a dat abase t o a t im e in t he past , you m ust roll all ot her dat abases back t o t he sam e point in t im e. How do you perform global t ransact ion t im e- based recovery? 1. Det erm ine t he SCN t o which you have recovered. This is available in t he alert log; look for an ent ry of t he form : RESETLOGS after incomplete recovery UNTIL CHANGE xxxxxx 2. Rest ore all ot her dat abases t o t he sam e SCN. ( Recall t hat dist ribut ed t ransact ions coordinat e SCNs.) Obviously, such a recovery can pot ent ially force you t o discard dat a in a healt hy dat abase j ust because of a failure in anot her. You can m it igat e t he im pact if you export t he dat a t hat you know you want t o keep beforehand. Also, if you have applicat ions t hat rely heavily on dist ribut ed t ransact ions, you can t ry t o isolat e t he t ables in t hese t ransact ions t o a single schem a so t hat you can m axim ize t he use of export / im port t o save as m uch of t he nondist ribut ed dat a as possible. Unfort unat ely, you cannot perform m edia recovery for a single schem a.

3 .4 .2 Sn a psh ot s I f you perform part ial recovery t o a dat abase t hat is t he m ast er for one or m ore snapshot s, t he snapshot s m ay cont ain dat a from t he " fut ure." All snapshot sit es should perform a com plet e refresh t o ensure t hat t hey are consist ent .

3 .4 .3 Ba ck u p St r a t e gy Con side r a t ion s I f it is conceivable t hat you will need t o perform an incom plet e backup of a dat abase involved in dist ribut ed t ransact ions, it is im port ant t hat you have valid backups of all ot her part icipat ing dat abases from t he sam e t im e. Alt hough it is not oft en pract ical or feasible t o t ake backups of m ult iple dat abases at exact ly t he sam e t im e, you should cert ainly have all of your syst em s on a sim ilar backup schedule ( e.g., weekly) . Your choices for t he t im e for recovery are lim it ed by your backup supply.

101

Oracle Distributed Systems

3 .5 M u lt ive r sion I n t e r ope r a bilit y Oracle perm it s dat abase links bet ween any t wo RDBMS versions bet ween Version 6 and Version 8, inclusive. However, t here are rest rict ions, part icularly when a Version 6 dat abase is involved. For dat abase links going from an Oracle Version 6 dat abase t o an Oracle7 dat abase: •

•

Com parisons of fixed- lengt h st rings use blank- padded sem ant ics in t he Oracle7 dat abase, even t hough Oracle Version 6 it self does not . The link m ust be over a SQL* Net V2 connect ion if t he Oracle Version is 7.3 or higher.

From an Oracle7 or Oracle8 dat abase t o an Oracle Version 6 dat abase: • • •

The dat abase link m ust be over a SQL* Net V2 or Net 8 connect ion. The link can updat e only a single Version 6 dat abase in a given st at em ent . The link cannot perform dist ribut ed t ransact ions wit h an Oracle Version 6 dat abase.

102

Oracle Distributed Systems

Ch a pt e r 4 . D ist r ibu t e d D a t a ba se Se cu r it y The m anager of a dist ribut ed dat abase environm ent has securit y considerat ions over and above t he t ypical user aut hent icat ion and access level concerns of t he single dat abase environm ent . The DBA is responsible for ensuring t he privacy and int egrit y of t he dat a t hat t ravels t he net work and for im plem ent ing an appropriat ely secure user aut hent icat ion policy. At t he sam e t im e, any single dat abase in a dist ribut ed environm ent m ust m aint ain a high degree of aut onom y from t he dat abases and m achines wit h which it int eract s. Oracle provides securit y m echanism s at several layers, including t he levels of t he dat abase, operat ing syst em , and net work. This chapt er discusses how t o im plem ent a secure environm ent wit h t hese various levels and point s out som e sit uat ions t hat you should avoid.

4 .1 Pr ivile ge M a n a ge m e n t You have a variet y o f choices for m anaging access t o obj ect s in rem ot e dat abases; t hese choices fall int o one of t he following cat egories: The sim plist ic approach Rem ot e obj ect s are accessed over a public dat abase link, wit h a local public synonym for each rem ot e obj ect . The m irrored account approach Rem ot e obj ect s are accessed over privat e dat abase links for all user account s, wit h a local public synonym for each rem ot e obj ect . The local view approach A local view is creat ed for rem ot e t ables. Access t o rem ot e obj ect s is via t hese local obj ect s. The local wrapper approach Rem ot e PL/ SQL obj ect s ( procedures and packages) are called from local procedures; t he rem ot e procedures t hem selves are not available t o local users. The guidelines provided here will help you decide what is best for your applicat ions.

4 .1 .1 Th e Sim plist ic Appr oa ch The easiest way t o provide users access t o rem ot e obj ect s is t o creat e a public dat abase link t o t he rem ot e dat abase and creat e public synonym s for t he obj ect s t here. For exam ple, t he DBA at t he sit e D7NY.BI GWHEEL.COM could provide access t o t he SPROCKET.PRODUCTS t able in D7CA.BI GWHEEL.COM by following t hese st eps: 1. Creat e apublic dat abase link t o D7CA.BI GWHEEL.COM:

103

Oracle Distributed Systems 2. 3.

CREATE PUBLIC DATABASE LINK D7CA.BIGWHEEL.COM CONNECT TO d7nydba IDENTIFIED BY masquerade USING 'prodcal'; We assum e t hat t he account " d7nydba" exist s in D7CA.BI GWHEEL.COM, and t hat it has sufficient privileges t o SELECT from t he SPROCKET.PRODUCTS t able.

4. Creat e a public synonym for t he rem ot e SPROCKET.PRODUCTS t able: 5. CREATE PUBLIC SYNONYM products FOR [email protected]; Act ually, t he public synonym is not required for users t o access t he rem ot e obj ect ; t hey could also reference it by specifying t he dat abase link; for exam ple: SELECT * FROM [email protected]; Now any user in t he local dat abase D7NY.BI GWHEEL.COM can access t he rem ot e t able SPROCKETS.PRODUCTS as t hough it were local and enj oy t he privileges t hat have been grant ed t o d7nydba.

4 .1 .1 .1 Adva n t a ge s of t h e sim plist ic a ppr oa ch The prim ary advant age of t his m eans of rem ot e access is t hat it is ext rem ely easy t o im plem ent , and it requires a m inim al am ount of coordinat ion wit h t he DBA at t he rem ot e sit e. I n ot her words, t his is t he quick and dirt y m et hod, but be advised t hat it is dirt y !

4 .1 .1 .2 D isa dva n t a ge s of t h e sim plist ic a ppr oa ch What does it m ean t o say t his m et hod is dirt y? Consider t he following: The sim plist ic approach opens t he door t o t he rem ot e dat abase Since we creat ed a public dat abase link t o t he rem ot e dat abase, which connect s t o a specific user I D, we have pot ent ially ( and probably) built a securit y hole. Any account in t he local dat abase can reference obj ect s in t he rem ot e dat abase wit h t he privilege level of t he account t o which t he public dat abase link connect s. Access is not rest rict ed t o t he SPROCKET.PRODUCTS t able for which we creat ed t he public synonym ; any t able, view, procedure, or package t hat d7nydba can access is available t o all users in t he local dat abase. For exam ple, curious users m ight help t hem selves t o sensit ive dat a as follows: SELECT last_name, first_name, salary FROM [email protected]; Of course, t he d7nydba account in D7CA.BI GWHEEL.COM could be creat ed wit h lim it ed privileges, but it will always be able t o see m ore t han j ust t he

104

Oracle Distributed Systems SPROCKET.PRODUCTS t able since any obj ect s accessible t o PUBLI C are also accessible t o d7nydba. The sim plist ic approach provides no local cont rol over access t o rem ot e obj ect s This issue is sim ilar t o t hat described in t he previous it em . Not only have we provided m ore access t han is necessary t o t he rem ot e dat abase, but also we have no cont rol over which local users can see t he SPROCKET.PRODUCTS t able; t hey all can. I n addit ion, all users enj oy t he sam e level of privileges on t he t able, as det erm ined by d7nydba's privilege level in D7CA.BI GWHEEL.COM. I n ot her words, we cannot use dat abase roles in t he local dat abase t o define access levels. One size fit s all, whet her you like it or not .

4 .1 .2 Th e M ir r or e d Accou n t Appr oa ch Them irrored account approach ent ails creat ing user account s in all dat abases in which t hey require access t o dat a and privat e dat abase links for t hese account s from each dat abase t o all ot her dat abases t hey m ust reference. The privat e dat abase links need not be creat ed wit h a CONNECT or USI NG clause if a public dat abase link exist s t o resolve link nam es. This is one of Oracle's recom m ended configurat ions for t he advanced replicat ion facilit ies wit h Oracle7. Suppose we wish t o creat e account s for users " cdye" and " j blow" in dat abase D7NY.BI GWHEEL.COM so t hat t hese account s can reference rem ot e obj ect s in dat abase D7CA.BI GWHEEL.COM. Here are t he st eps we would t ake: 1. Creat e t he user account s in D7NY.BI GWHEEL.COM and in D7CA.BI GWHEEL.COM. I f t he account s have t he sam e passwords in bot h dat abases, we can creat e privat e dat abase links wit hout t he CONNECT clause: 2. CREATE USER cdye IDENTIFIED BY yankeeclip 3. DEFAULT TABLESPACE users 4. TEMPORARY TABLESPACE temp; 5. 6. GRANT CREATE SESSION TO cdye; 7. 8. GRANT app_admin TO cdye; 9. 10. CREATE USER jblow IDENTIFIED BY aoldotcom 11. DEFAULT TABLESPACE users 12. TEMPORARY TABLESPACE temp; 13. 14. GRANT CREATE SESSION TO jblow; 15. GRANT app_user to jblow; Not e t hat in t his exam ple we have grant ed different roles t o t he different users ( app_adm in for cdye, and app_user for j blow ) ; t he m irrored account m et hod allows you t o t ailor privileges t o specific users.

105

Oracle Distributed Systems 16. Creat e a public dat abase link from D7NY.BI GWHEEL.COM t o D7CA.BI GWHEEL.COM so t hat t he privat e dat abase links can be creat ed wit hout t he USI NG clause: 17. CREATE PUBLIC DATABASE LINK D7CA.BIGWHEEL.COM USING 'prodcal' You can creat e t his link from any account t hat has sufficient privileges t o creat e public dat abase links. 18. Creat e privat e dat abase links from t he cdye and j blow account s. Connect ed as cdye: CREATE DATABASE LINK D7CA.BIGWHEEL.COM Connect ed as j blow: CREATE DATABASE LINK D7CA.BIGWHEEL.COM 19. Creat e synonym s for t he rem ot e obj ect s in D7CA.BI GWHEEL.COM: 20. CREATE PUBLIC SYNONYM products FOR [email protected] The synonym s can be eit her public or privat e. From a pract ical st andpoint , however, public synonym s m ake m ore sense since you only have t o creat e one per obj ect . I f you do not creat e t he synonym s, users can st ill reference t he rem ot e obj ect s by specifying t he dat abase link, for exam ple: SELECT product_id, product_name FROM [email protected]; Once you have creat ed t hese account s and links, t he specified users can access rem ot e obj ect s, each wit h t he access level you have grant ed.

4 .1 .2 .1 Adva n t a ge s of t h e m ir r or e d a ccou n t a ppr oa ch Mirrored account s allow you t o grant access t o rem ot e obj ect s only for t hose users who require it , and you can grant different privileges t o different users according t o t heir j ob funct ions and responsibilit ies. I n addit ion, since t he public dat abase link we creat ed does not include a CONNECT clause, t here is no " open door" t o t he rem ot e dat abase.

4 .1 .2 .2 D isa dva n t a ge s of t h e m ir r or e d a ccou n t a ppr oa ch Alt hough m irrored account s offer significant advant ages over t he sim plist ic approach, som e t roublesom e issues persist : •

Users wit h rem ot e account s can see any obj ect s t hat are available t o PUBLI C, in addit ion t o t he obj ect s t o which t hey have been grant ed access eit her explicit ly or t hrough roles.

106

Oracle Distributed Systems • •

•

Since users have account s in t he rem ot e dat abases, t hey can log in t o t hese dat abases direct ly, which m ay or m ay not be an issue depending on t he sit e's securit y policy. The m aint enance of user account s, passwords, and roles in m ult iple dat abases can quickly becom e an adm inist rat ive night m are if t here are large num bers of users or dat abase inst ances. The adm inist rat ors of rem ot e dat abase inst ances m ust sacrifice a degree of aut onom y t o support t hese users. There is no local cont rol over access t o rem ot e obj ect s. This is st ill an issue, as wit h t he sim plist ic approach.

4 .1 .3 Th e Loca l Vie w Appr oa ch The local view approach ent ails creat ing a single privileged account in t he rem ot e dat abase which has sufficient privileges on all applicat ion t ables t here. A local account creat es a privat e dat abase link t hat connect s t o t he privileged account and t hen builds views t hat reference t he rem ot e obj ect s. Since t hese views are local, we can use roles t o define access levels. Consider t he SPROCKET.PRODUCTS t able described in t he previous exam ples. This t able resides in t he dat abase inst ance D7CA.BI GWHEEL.COM, but users in D7NY.BI GWHEEL.COM m ust access it . What if som e users need read- only access while ot her users m ust updat e it ? Here is t he solut ion: 1. Creat e a privileged account in D7CA.BI GWHEEL.COM t hat has SELECT, I NSERT, UPDATE, and DELETE privileges on SPROCKET.PRODUCTS. ( Assum e t hese privileges are grant ed t o t he role product _adm in.) 2. CREATE USER d7nydba IDENTIFIED BY masquerade 3. DEFAULT TABLESPACE USERS 4. TEMPORARY TABLESPACE temp; 5. 6. GRANT CREATE SESSION TO d7nydba; 7. GRANT product_admin TO d7nydba; 8. I n D7NY.BI GWHEEL.COM, creat e a privat e dat abase link t o D7CA.BI GWHEEL.COM t hat connect s t o t he account creat ed in St ep 1. For t he sake of clean design, t his link should be creat ed under t he account t hat owns t he applicat ion schem a, but it could be m ade under any account t hat has sufficient privileges t o creat e views. I n our case, we creat e t he link under t he SPROCKET account : 9. CREATE DATABASE LINK D7CA.BIGWHEEL.COM 10. CONNECT TO d7nydba IDENTIFIED BY masquerade USING 'prodcal'; 11. From t he account t hat creat ed t he dat abase link in St ep 2, creat e a privat e synonym for [email protected] GWHEEL.COM: CREATE SYNONYM hq_products FOR [email protected];

107

Oracle Distributed Systems St rict ly speaking, t his st ep is opt ional. However, it is advisable because it elim inat es t he necessit y t o creat e a view t hat cont ains a dat abase link nam e in t he query t ext . This m akes adm inist rat ive t asks sim pler, as we shall see in Chapt er 6. 12. Creat e a view t hat select s from t he rem ot e t able: 13. CREATE VIEW products AS 14. SELECT product_id, 15. product_type, 16. catalog_id, 17. description, 18. rev_level, 19. production_date, 20. production_status FROM hq_products; 21. Creat e roles and grant privileges on t he view, as appropriat e: 22. CREATE ROLE product_viewer; 23. 24. GRANT SELECT ON products TO product_viewer; 25. 26. CREATE ROLE product_admin; 27. GRANT SELECT, INSERT, UPDATE, DELETE ON products TO product_admin 28. Opt ionally creat e a public synonym for t he view: CREATE PUBLIC SYNONYM products FOR sprocket.products;

4 .1 .3 .1 Adva n t a ge s of t h e loca l vie w a ppr oa ch The local view approach solves t he problem of cont rolling access t o rem ot e obj ect s wit h local roles. You can creat e as m any roles as you need t o provide appropriat e levels of access. I n addit ion, t here is no public dat abase link involved and t herefore no open door t o t he rem ot e dat abase. I n fact , in t he im plem ent at ion out lined here, t he local account t hat owns t he dat abase link and t he view does not even need t o have CREATE SESSI ON privileges once t he view is in place! Then nobody can use t he account t o exploit t he privat e link t o t he rem ot e dat abase. ( I always revoke CREATE SESSI ON from schem a owner account s once t he schem a obj ect s are creat ed.)

The local view approach would also work wit h privat e dat abase links from each of t he user account s t hat need t o reference t he rem ot e obj ect . You could, t herefore, require t hat local users have account s in t he rem ot e dat abase. This adds an addit ional level of securit y.

4 .1 .3 .2 D isa dva n t a ge s of t h e loca l vie w a ppr oa ch

108

Oracle Distributed Systems Truly t here are no disadvant ages t o t his approach ot her t han t he fact t hat t he init ial set up is slight ly m ore involved t han t he ot her t echniques because you m ust creat e t he local view and roles. However, t his is a sm all price t o pay for t he flexibilit y and securit y t hat you realize.

4 .1 .4 Th e Loca l W r a ppe r Appr oa ch Just as you can creat e local views on rem ot e t ables t o cont rol privileges, you can also writ e local PL/ SQL procedures which execut e rem ot e procedures. By writ ing a local procedure or package t hat calls a rem ot e procedure or package, you can use local roles t o adm inist er privileges t o t he rem ot e obj ect s. The alt ernat ive is t o creat e dat abase links t hat provide access t o t he rem ot e procedures and packages and sacrifice all local cont rol over who can execut e t hem . Consider t he package Product Maint , which allows users t o add new product s t o t he product t able: CREATE OR REPLACE PACKAGE ProductMaint IS PROCEDURE AddProduct (product_type_IN IN catalog_id_IN IN description_IN IN rev_level_IN IN production_date_IN IN product_status_IN IN END ProductMaint; / CREATE OR REPLACE PACKAGE BODY ProductMaint IS PROCEDURE AddProduct(product_type_IN catalog_id_IN description_IN rev_level_IN production_date_IN product_status_IN BEGIN INSERT INTO products (product_id, product_type, catalog_id, description, rev_level, production_date, production_status, audit_date, audit_user, global_name ) VALUES (seq_products.nextval, product_type_IN, catalog_id_IN, description_IN, rev_level_IN, production_date_IN, product_status_IN, SYSDATE, USER,

IN IN IN IN IN IN

NUMBER, VARCHAR2, VARCHAR2, VARCHAR2, DATE, VARCHAR);

NUMBER, VARCHAR2, VARCHAR2, VARCHAR2, DATE, VARCHAR) IS

109

Oracle Distributed Systems DBMS_REPUTIL.GLOBAL_NAME); END AddProduct; END ProductMaint; / I f t his package exist s in t he dat abase D7CA.BI GWHEEL.COM, how can we give som e ( but not all ! ) users in D7NY.BI GWHEEL.COM access t o it ? Specifically, we wish t o allow t hose users in D7NY.BI GWHEEL.COM wit h t he product _adm in role t he abilit y t o execut e Product Maint .AddProduct . The solut ion, of course, is t o creat e a local procedure ( or " wrapper" ) in D7NY.BI GWHEEL.COM which calls t he rem ot e Product Maint .AddProduct . Then we can grant EXECUTE on t he wrapper t o t he product _adm in role. Here's how: 1. Creat e a privileged account in D7CA.BI GWHEEL.COM t hat has EXECUTE privileges on Product Maint . ( Assum e t hese privileges are grant ed t o t he role product _adm in.) 2. CREATE USER d7nydba IDENTIFIED BY masquerade 3. DEFAULT TABLESPACE USERS 4. TEMPORARY TABLESPACE temp; 5. 6. GRANT CREATE SESSION TO d7nydba; 7. GRANT product_admin TO d7nydba; 8. I n D7NY.BI GWHEEL.COM, creat e a privat e dat abase link t o D7CA.BI GWHEEL.COM which connect s t o t he account creat ed in St ep 1. For t he sake of clean design, t his link should be creat ed under t he account t hat owns t he applicat ion schem a, but it could be m ade under any account t hat has sufficient privileges t o creat e views. I n our case, we creat e t he link under t he SPROCKET account : 9. CREATE DATABASE LINK D7CA.BIGWHEEL.COM 10. CONNECT TO d7nydba IDENTIFIED BY masquerade USING 'prodcal'; 11. From t he account t hat creat ed t he dat abase link in St ep 2, creat e a privat e synonym for SPROCKET.PRODUCTMAI [email protected] GWHEEL.COM: 12. CREATE SYNONYM hq_productmaint FOR [email protected]; St rict ly speaking, t his st ep is opt ional. However, it is advisable because it elim inat es t he necessit y t o creat e a procedure t hat cont ains a dat abase link nam e. This m akes adm inist rat ive t asks sim pler, as we shall see in Chapt er 6. 13. Creat e t he " wrapper" procedure: 14. CREATE OR REPLACE PACKAGE ProductMaint IS 15. PROCEDURE AddProduct(product_type_IN 16. catalog_id_IN 17. description_IN 18. rev_level_IN 19. production_date_IN 20. product_status_IN

IN IN IN IN IN IN

NUMBER, VARCHAR2, VARCHAR2, VARCHAR2, DATE, VARCHAR);

110

Oracle Distributed Systems 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. /

END ProductMaint; / CREATE OR REPLACE PACKAGE BODY ProductMaint IS PROCEDURE AddProduct (product_type_IN IN NUMBER, catalog_id_IN IN VARCHAR2, description_IN IN VARCHAR2, rev_level_IN IN VARCHAR2, production_date_IN IN DATE, product_status_IN IN VARCHAR) IS BEGIN hq_ProductMaint.AddProduct(product_type_IN, catalog_id_IN, description_IN, rev_level_IN, production_date_IN, product_status_IN); END AddProduct; END ProductMaint;

41. Grant EXECUTE privileges on t he local package as appropriat e: GRANT EXECUTE ON ProductMaint TO product_admin;

4 .1 .4 .1 Adva nt a ge s of t h e loca l w r a ppe r a ppr oa ch Just as a local view of a rem ot e obj ect facilit at es local privilege adm inist rat ion over rem ot e t ables, so a local wrapper facilit at es local privilege adm inist rat ion over rem ot e procedures and packages. I n addit ion, t he wrapper can help t o ensure dat a consist ency by perform ing edit checks, set t ing param et er values, and so on.

4 .1 .4 .2 D isa dva n t a ge s of t h e loca l w r a ppe r a ppr oa ch As wit h local views, t he local wrapper requires a bit of ext ra work init ially; you have t o writ e t he local procedure or package and m anage t he role grant s.

4 .1 .5 Con clu sion s on Pr ivile ge M a n a ge m e n t I t is a very sim ple m at t er t o offer access t o obj ect s in a rem ot e dat abase: j ust creat e a public dat abase link. The challenge is t o develop an access m odel t hat allows t he local adm inist rat or t he abilit y t o cont rol privilege levels on t he rem ot e obj ect s wit h t he sam e granularit y t hat is possible wit h local obj ect s. But dat abase roles cannot m anage privileges on rem ot e obj ect s: SQL> GRANT SELECT ON [email protected] TO product_viewer; GRANT SELECT ON [email protected] TO product_viewer * ERROR at line 1: ORA-02021: DDL operations are not allowed on a remote database

111

Oracle Distributed Systems The recom m ended solut ion is t o creat e local views for rem ot e t ables and local wrapper funct ions for rem ot e procedures and packages. You can grant privileges on t hese local obj ect s t o local roles. There are, however, occasions when t he local obj ect s m ay not be appropriat e. For exam ple, if you are using t he advanced replicat ion facilit ies, t he access m odel is quit e different ( as we'll see in see Chapt er 10) .

4 .2 Au t h e n t ica t ion M e t h ods One of t he DBA'sobj ect ives in a dist ribut ed environm ent is t o provide easy dat abase access t o valid users, while t hwart ing ( or at least discouraging) unaut horized access t o t he dat abase and net work t raffic t o it ( which m ay cont ain sensit ive inform at ion such as passwords) . There are t hree dist inct m eans of aut hent icat ing users of an Oracle dat abase, corresponding t o t hree different t ypes of account s: Dat abase aut hent icat ion This m et hod corresponds t o account s m ade wit h t he CREATE USER com m and. Users m ust provide a valid usernam e/ password, which t he dat abase validat es wit h inform at ion st ored in t he dat a dict ionary. Operat ing syst em aut hent icat ion These are Oracle account s t hat correspond t o operat ing syst em account s. I f a user can log in t o t he operat ing syst em , she is perm it t ed t o log in t o t he dat abase. We oft en refer t o t hese account s as OPS$ ( pronounced " ops dollar" ) because t he corresponding dat abase usernam es are in t he form OPS$os_usernam e by default . Ext ernal aut hent icat ion These are account s t hat are validat ed by som e ext ernal m eans, such as a fingerprint scanner or a net work aut hent icat ion m echanism such as Kerberos. The sect ions t hat follow exam ine t he considerat ions for each of t hese m et hods in a dist ribut ed environm ent and discuss im plem ent at ion opt ions.

4 .2 .1 D a t a ba se Au t h e n t ica t ion Dat abase aut hent icat ed account s are t he t ype wit h which we are m ost fam iliar. Every Oracle dat abase has at least t wo such account s: SYS and SYSTEM. I n an ideal world, you can also creat e an account for each user, j ust as t he adm inist rat ors of your operat ing syst em ( s) do: one individual, one account in t he dat abase( s) he needs t o use. This seem s reasonably st raight forward, but som e perils do exist , for exam ple, com prom ised passwords. Most m ult iuser operat ing syst em s allow users t o report on all of t he processes running on a m achine; t ypically, t his list ing displays a process I D, usernam e, program nam e, and ot her inform at ion about CPU ut ilizat ion and so on. Som et im es

112

Oracle Distributed Systems t he list ing shows t he argum ent s t hat a user passed t o a program . I f users passed t heir usernam e and password, t hat inform at ion m ay be available t o one and all. The SVR4 variant of t he ps com m and, found on operat ing syst em s such as Solaris, is a classic exam ple. Here is how you can obt ain passwords on a Solaris m achine: cdye@socrates% ps -ef | grep sql cdye 12174 10822 0 16:03:23 pts/8 cdye 12168 10901 0 16:01:00 pts/9 system/twinkletoes@hr_prod

0:00 grep sql 0:00 sqlplus

So, t he syst em password for hr_prod is " twinklet oes." This problem has fueled considerable dialogue in Oracle user groups, and t he consensus is t hat you can choose one of t hree rem edies for it , described t he following sect ions.

4 .2 .1 .1 W r it e a w r a ppe r com m a n d a r ou n d sqlplu s I n t his way, t he argum ent s are not displayed. Oracle Support has writ t en ( but does not support ) a program called hide.c which m asks argum ent s from t he ps com m and. The program is described in Oracle Bullet in 1009091.6, which is included here: Oracle Corporate Support Problem Repository 1. Prob# 1009091.6 2. Soln# 2057042.6

HOW DO YOU HIDE USERNAME/PASSWORD IN PS? USE THE HIDE.C PROGRAM

1. Prob# 1009091.6

HOW DO YOU HIDE USERNAME/PASSWORD IN PS?

Problem ID Affected Platforms Affected Products Affected Components Affected Oracle Vsn

: : : : :

1009091.6 NCR Unix SVR4 SQL*Forms IAD V03.00.XX V07.00.13.XX

Summary: HOW DO YOU HIDE USERNAME/PASSWORD IN PS? +=+ Problem Description: ==================== ps shows username/password.

How can I keep this from happening?

Search words: hide.c hide +==+ Diagnostics and References: * {5038.6,Y,100} 2. Soln# 2057042.6

PS SHOWS USERID AND PASSWORD USE THE HIDE.C PROGRAM

113

Oracle Distributed Systems

Solution ID For Problem Affected Platforms Affected Products Affected Components Affected Oracle Vsn

: : : : : :

2057042.6 1009091.6 NCR Unix SVR4 SQL*Forms IAD V03.00.XX V07.00.13.XX

Summary: USE THE HIDE.C PROGRAM +=+ Solution Description: ==================== Use the program hide.c: /*------------------------------------------------------------------------+ | Can be used as a program prefix: hide program arguments | | or as a symbolic link. If this program is not invoked as hide, it | | will hide its arguments and invoke the program name.hide | | The best way to use this is to rename your critical programs to | | program.hide, and create a symbolic link program to hide. | | mv sqlplus sqlplus.hide; ln -s hide sqlplus | | Thus when sqlplus is invoked, its arguments will be hidden | | | | NOTES | | | | This program works by padding 3000 '/' chars in argv[0]. This fools | | all known ps's. This will reduce the argument capacity of your | | program by 3000 chars. A good enhancement would be to reduce the | | padding if needed so that no arguments are lost - would require a | | method of determining the max argument size on the system. Some | | system's provide the E2BIG error on exec. | | There is some performace penalty for using this program, but it is | | minimal because this program is so small - the biggest cost is the | | extra exec required to get this program started. |

114

Oracle Distributed Systems | HISTORY | | 09/17/92 D Beusee Fixed to compile on any system | +-----------------------------------------------------------------------*/ /* * $Header: /work/oracle/distributed/xml/RCS/ch04.xml,v 1.9 2001/08/07 21:49:45 chodacki Exp $ * * $Log: ch04.xml,v $ * Revision 1.9 2001/08/07 21:49:45 chodacki * notes have role=ORA attribute * * Revision 1.8 2000/11/10 19:27:13 jliggett * final prep for bvd * * Revision 1.7 2000/10/26 20:07:50 jliggett * minor edits * * Revision 1.6 2000/09/05 21:06:55 jliggett * renumbered * * Revision 1.5 2000/07/18 19:18:44 jliggett * added number attribute * * Revision 1.4 2000/06/19 14:56:21 jliggett * final checklist * * Revision 1.3 2000/05/11 17:57:53 jliggett * entered proof edits * * Revision 1.2 2000/05/04 16:35:00 jliggett * validation * * Revision 1.1 2000/04/26 19:14:02 bsalter * Initial revision * * Revision 1.6 1992/09/22 22:37:17 dbeusee * Added exit(1) when cannot execvp the program. * * Revision 1.5 1992/09/22 11:28:44 dbeusee * Some BSD systems have memset(), so add a #define memset MEMSET to fix * compilation errors (like on ultrix). * * Revision 1.4 1992/09/22 06:34:57 dbeusee * BSD systems need memset routine. * * Revision 1.3 1992/09/22 06:05:13 dbeusee * Set JUNK_CHAR to ' ' but force last junk char to '/'. This looks prettier * when doing 'ps'. Also do not show full path of the program. Also do not * show .hide if prog is a symlink to hide. * * Revision 1.2 1992/09/22 05:52:26 dbeusee * If hide could not execvp the program, give an error message.

115

Oracle Distributed Systems * if hide was invoked with a full path (e.g. /usr/local/bin/hide), * do not try to invoke PATH/hide.hide. * * */ #include #ifdef SYS5 #include #else #include #define strrchr rindex #define memset MEMSET /* some BSD systems have a memset() */ char *memset(); #endif #define JUNK_SIZE 3000 #define JUNK_CHAR ' ' char arg0buf[4096]; char progbuf[4096]; char errbuf[4096]; int main(argc, argv) int argc; char *argv[]; { char *name, *base; int firstarg; if (!(name = strrchr(argv[0], '/'))) name = argv[0]; else name ++; /* get past '/' */ firstarg = (!strcmp(name, "hide")) ? 1 : 0; if (firstarg && (argc == 1)) { fprintf(stderr, "Usage: hide program arguments\n"); fprintf(stderr, " ie: hide sqlplus username/password\n"); fprintf(stderr, "if hide is not named hide, \ it will execute name.hide (useful as a symbolic link)\n"); exit(1); } /* Build program name. If symbolic link mode, use argv[0] || .hide */ strcpy(progbuf, argv[firstarg]); if (!(base = strrchr(argv[firstarg], '/'))) base = argv[firstarg]; else base ++; /* get past '/' */ if (!firstarg) strcat(progbuf, ".hide"); /* Build arg0 buffer. First, fill it with junk */ memset((void *)arg0buf, JUNK_CHAR, JUNK_SIZE); arg0buf[JUNK_SIZE-1] = '/'; /* set last char to '/' */ /* Prepend real program name - so ps can see what prog is running */ strncpy(arg0buf, base, strlen(base)); /* Append real program name - so prog can see what prog is running */ strcpy(arg0buf + JUNK_SIZE, argv[firstarg]); /* Assign new arg0 buffer to the argv array */

116

Oracle Distributed Systems argv[firstarg] = arg0buf; /* Start the new program with the shifted arguments */ execvp(progbuf, argv + firstarg); sprintf(errbuf, "Could not execvp '%s'", progbuf); perror(errbuf); exit(1); } #ifndef SYS5 char * memset(s, c, n) register char *s; register c, n; { register char *p = s; while (n-- > 0) *s++ = c; return (p); } #endif /* ifndef SYS5 */ DISCLAIMER: The hide.c code is not supported by Oracle. It is provided as a courtesy, as a workaround for SVR4 machines. BSD already hides the ps arguments.

4 .2 .1 .2 Use ope r a t in g syst e m a u t h e n t ica t e d ( OPS$ ) a ccount s These account s do not require a usernam e or password: cdye@socrates% sqlplus /@hr_prod SQL*Plus: Release 8.0.4.0.0 - Production on Mon Dec 28 21:43:57 1998 (c) Copyright 1997 Oracle Corporation.

All rights reserved.

Connected to: Oracle8 Enterprise Edition Release 8.0.4.1.0 - Production With the Partitioning and Objects options PL/SQL Release 8.0.4.1.0 - Production SQL> show user user is "OPS$CDYE" SQL> Those who at t em pt t o obt ain a password for t hese account s will be disappoint ed, as you can see here: cdye@socrates% ps -ef | grep sqlp cdye 12214 10822 1 18:14:05 pts/8 cdye 12216 10901 0 18:14:22 pts/9

0:00 sqlplus /@hr_prod 0:00 grep sqlp

4 .2 .1 .3 D on 't in vok e pr ogr a m s w it h use r n a m e a n d pa ssw or d on com m a n d lin e

117

Oracle Distributed Systems I nst ruct users not t o ent er t heir usernam es and passwords on t he com m and line. Let t he program prom pt for t he password inst ead: cdye@socrates% sqlplus cdye@hr_prod SQL*Plus: Release 8.0.4.0.0 - Production on Mon Dec 28 21:49:14 1998 (c) Copyright 1997 Oracle Corporation.

All rights reserved.

Connected to: Oracle8 Enterprise Edition Release 8.0.4.1.0 - Production With the Partitioning and Objects options PL/SQL Release 8.0.4.1.0 - Production SQL> show user user is "CDYE" SQL> Personally, I have not been overly successful wit h enforcing t his approach. Even if you use an operat ing syst em t hat does not display program argum ent s when processes are list ed ( such as t he VMS show syst em com m and) , passwords m ay st ill be available in net work t race files.

4 .2 .2 Ope r a t in g Syst e m Au t h e n t ica t ion As m ent ioned earlier, you can use operat ing syst em aut hent icat ed account s t o avoid t he issues of com prom ised dat abase passwords. I n effect , OPS$ account s do not have passwords; t heir encrypt ed version, st ored in t he dat a dict ionary view DBA_USERS, is EXTERNAL: system@dc18 SQL> SELECT username, password 2 FROM dba_users 3 WHERE username like 'OPS$%' 4 / Username --------------OPS$AKALIDIN OPS$AKAPO OPS$BONO OPS$CDYE OPS$CHATSINT OPS$CHERNOVI OPS$CKER OPS$DEASLEY OPS$DWEB OPS$EDD OPS$GKRISHNA OPS$GWANG OPS$IASAAD OPS$IBALKHI OPS$IHAB

Password -----------------EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL EXTERNAL

118

Oracle Distributed Systems

You can set t he password for OPS$ account s t o what ever value you like, and t hey will st ill work.

One argum ent for using OPS$ account s is t hat dat abase passwords are no longer an issue: t hey cannot be st olen or com prom ised. Anot her reason is t hat t hese account s are generally m uch m ore convenient for users—one less password t o rem em ber and, of course, less t yping. OPS$ account s also allow a cent ralized approach t o account adm inist rat ion. Finally, audit ing is sim plified because t race files and audit t rails cont aining Oracle user I Ds are easy t o m ap t o operat ing syst em account s. I f you decide t o use OPS$ account s, you are in effect t elling your dat abase t hat if a user can log in t o t he operat ing syst em successfully, t hen she should be able t o log in t o t he dat abase, t oo, connect ing t o t he Oracle account corresponding t o her operat ing syst em account . The Unix account cdye, for exam ple, connect s t o t he Oracle account OPS$CDYE: SQL> CREATE USER ops$cdye 2 IDENTIFIED EXTERNALLY; User created. SQL> SELECT username, password 2 FROM dba_users 3 WHERE username = 'OPS$CDYE'; Username PASSWORD ------------- -----------------------------OPS$CDYE EXTERNAL I f you keep t he default encrypt ed password EXTERNAL for t hese account s, nobody else will be able t o use t he OPS$ account because it is not possible t o supply a password t hat encrypt s t o t he st ring EXTERNAL. Oracle ident ifies users, but t he operat ing syst em aut hent icat es t hem .

4 .2 .2 .1 Cr e a t ing OPS$ a ccou n t s Besides creat ing t he dat abase and operat ing syst em account s t hem selves, t here are a couple of ot her st eps required t o configure OPS$ account s. Table 4.1 describes t he relevant init ializat ion param et ers.

Table 4.1. Initialization Parameters Associated with OPS$ Logins Parameter Name

Default Value

Description

OS_AUTHENT_PREFI X OPS$

This is t he st ring prepended t o t he nam e of t he operat ing syst em account t o form t he dat abase account .

REMOTE_OS_AUTHENT FALSE

I f TRUE, t hen t he dat abase will accept users who

119

Oracle Distributed Systems

have been validat ed by a m achine ot her t han t he one on which t he dat abase is running. You m ust rest art t he dat abase in order for changes t o t hese values t o t ake effect . There m ay be addit ional requirem ent s depending on your dat abase's plat form , as shown in Table 4.2.

Table 4.2. Operating-System Specific Requirements for Using OPS$ Logins Operating System

Remarks

Unix

No addit ional requirem ent s.

Microsoft NT

Operat ing syst em m ust exist on t he NT server on which dat abase resides; it m ust eit her share a direct ory from NT server t o client s or use nam ed pipes. NT client s m ust run 32- bit versions of Oracle client soft ware ( e.g., Form s) , and t he applicat ions t hem selves m ust have been com piled wit h t he 32- bit versions.

Net Ware

For a secure OPS$ account wit h SQL* Net 2, t he Net Ware user m ust also be associat ed wit h an Oracle user by using t he Oracle Snap- I n for Net Ware Adm inist rat or ut ilit y. This requires Net Ware 4.1 or higher and t he inst allat ion of Oracle's Novel Direct ory Service Aut hent icat ion Adapt er at t he server and client .

Once you have configured your syst em , users can connect t o t he dat abase using a connect st ring of t he form : /@sqlnet_alias Not e t hat t here is no usernam e or password.

Not all client t ools can t ake advant age of OPS$ logins. For exam ple, t he login screen for Designer 2000 does not accept " / " as a usernam e.

4 .2 .2 .2 Th e a ssu m e d r isk s of OPS$ a ccou n t s I f you set t he init ializat ion param et er REMOTE_OS_AUTHENT t o TRUE, you are inst ruct ing your dat abase t o t rust t he aut hent icat ion m et hods of every client on your net work. As a general rule, your client s are not t rust wort hy. Why not ? Because som e operat ing syst em s perm it users t o m asquerade as whom ever t hey wish. Client s running Windows 3.x can set t he CONFI G.ORA file param et er USERNAME t o ident ify t hem selves t o a rem ot e Oracle dat abase, while Windows 95 users can set t he following regist ry subkey:

120

Oracle Distributed Systems My Computer\HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\CurrentUse r Because of t hese securit y weaknesses, you should consider OPS$ account s t o be publicly available if PCs have access t o your net work and you have set REMOTE_OS_AUTHENT t o TRUE. And even if PCs are not on your net work, if people have physical access t o a m achine running m ost ot her operat ing syst em s, t hey can becom e whom ever t hey want on t hat m achine. Rem em ber t hat set t ing REMOTE_OS_AUTHENT t o TRUE m eans t hat you accept t he aut hent icat ion m et hods of all client s.

En cr ypt in g N e t w or k Tr a ffic The Oracle password prot ocol encrypt s all passwords sent over t he net work ( Version 7.1 onward) . Wit h t he advanced net working opt ion, t he password is not t ransm it t ed; rat her, it is used as a key t o encrypt inform at ion. Considering t he wide availabilit y of net work sniffer soft ware, encrypt ion of passwords is essent ial.

4 .2 .3 Ex t e r n a l Au t h e n t ica t ion Oracle's advanced net working opt ion include int erfaces ( known as adapt ers) t o a variet y of t hird- part y securit y services for aut hent icat ing users. You can configure t hese services so t hat users can use a single password t o connect t o any dat abase on your net work. The single sign- on archit ect ure works by st oring usernam e and password inform at ion in a dat abase or file syst em residing on a single server, called t he aut hent icat ion server. Oracle current ly includes adapt ers for t he following aut hent icat ion services: • • • • • • • •

Kerberos I CL Access Manager/ SESAME CyberSAFE Challenger Bull I SM SecurI D DCE Securit y Service ( GSSAPI ) Banyan Biom et ric ( I dent ix)

The aut hent icat ion server act s as an int erm ediary bet ween client com put ers and dat abase servers, as depict ed in Figure 4.1.

Figu r e 4 .1 . Au t h e n t ica t ion se r ve r

121

Oracle Distributed Systems

The sequence of event s is as follows: 1. When a user on t he client m achine init iat es a dat abase connect ion, t he client request s aut hent icat ion credent ials from t he aut hent icat ion server. This inform at ion is t ypically in t he form of an encrypt ed key. 2. The aut hent icat ion server verifies t he client and sends t he required credent ials back. 3. The client m akes a connect ion request t o t he dat abase server, using t he credent ials obt ained from t he aut hent icat ion server. 4. The dat abase server sends t he credent ials t o t he aut hent icat ion server for validat ion. 5. The aut hent icat ion server sends verificat ion back t o t he dat abase server, which t hen accept s t he connect ion request . This archit ect ure offers several advant ages over convent ional dat abase aut hent icat ion or OPS$ account s: • •

•

•

The aut hent icat ion server on which passwords reside is under cent ralized adm inist rat ion, and access can ( and should) be ext rem ely lim it ed. No int eract ive logins should be perm it t ed. Passwords never t ravel over t he net work; inst ead, t hey are used as a key t o encrypt and decrypt inform at ion during t he login process. Users can use t he sam e password for every dat abase t hey access, wit h lit t le risk t hat t his password can be com prom ised. Besides associat ing passwords wit h users, you can associat e usernam es wit h client m achines so t hat a given user can only connect from a given client .

122

Oracle Distributed Systems

Ch a pt e r 5 . D e sign in g a D ist r ibu t e d Syst e m Applicat ion developers and DBAs face num erous challenges and choices as t hey design a dist ribut ed applicat ion. Many, if not m ost , of t hese issues are not specific t o t he part icular RDBMS vendor t hey have select ed but are a funct ion of business requirem ent s and ot her const raint s. This chapt er t akes a st ep back from Oracle specifics and exam ines t opics com m on t o dist ribut ed applicat ions in general, including: • • • • •

The charact erist ics of a successful dist ribut ed syst em Dat a part it ioning Applicat ion part it ioning The client / server approach Com m on solut ions t o com m on problem s

We int roduced som e of t hese t opics in Chapt er 1. Chapt er 6, discusses t hese issues in great er det ail in t he cont ext of t he Oracle RDBMS.

5 .1 Ch a r a ct e r ist ics of a D ist r ibu t e d Syst e m Before designing a dist ribut ed syst em , you should have a clear underst anding of what a dist ribut ed syst em is and what requirem ent s it m ust m eet . I n his book An I nt roduct ion t o Dat abase Syst em s ( Addison- Wesley, 1995) , t he relat ional dat abase deit y C. J. ( Chris) Dat e st at es his " fundam ent al principle of dist ribut ed dat abase," as follows: To t he user, a dist ribut ed syst em should look exact ly like a nondist ribut ed syst em . Dat e goes on t o enum erat e 12 obj ect ives t hat m ust be m et in order t o sat isfy t his principle, as follows: 1. Local aut onom y 2. No reliance on a single sit e 3. Cont inuous operat ion 4. Locat ion t ransparency 5. Fragm ent at ion independence 6. Replicat ion independence 7. Dist ribut ed query processing 8. Dist ribut ed t ransact ion m anagem ent 9. Hardware independence 10. Operat ing syst em independence 11. Net work independence 12. RDBMS independence Som e of t hese requirem ent s are quit e loft y, and Chris Dat e him self acknowledges t hat t hese rules are not 100% achievable. Rat her, t hey are useful prim arily as guidelines t o observe in t he design and developm ent of a dist ribut ed syst em . You can design a successful dist ribut ed dat abase syst em t hat fails t o m eet every one of t hese obj ect ives. Also, several of t hese obj ect ives are t he RDBMS vendor's responsibilit y, not t he im plem ent or's.

123

Oracle Distributed Systems

5 .1 .1 D ist r ibu t e d Syst e m Obj e ct ive s The following sect ions exam ine what t hese obj ect ives m ean, and Chapt er 6 discusses Oracle's st rat egies for addressing t hem .

5 .1 .1 .1 Loca l a u t on om y To sat isfy t helocal aut onom y rule, a dat abase t hat part icipat es in a dist ribut ed syst em m ust be fully funct ional regardless of whet her it is able t o cont act it s com pat riot s. I n addit ion, t he dat a t hat resides wit h each part icipat ing dat abase belongs t o t hat dat abase, in t he sense t hat dat a int egrit y, securit y, and m anagem ent are independent of t he ot her sit es t hat m ay be accessing or supplying t he dat a.

5 .1 .1 .2 N o r e lia n ce on a single sit e This rule is t he com plem ent t o t he local aut onom y rule. Just as each sit e is selfsufficient , so t here is no single m ast er sit e on which ot hers rely in t he ideal dist ribut ed environm ent . I n ot her words, t he failure of any one sit e should not cripple t he ot her sit es ( t hough it m ay hobble t hem ) , nor should t he overall perform ance of t he syst em be dependent on a single sit e.

5 .1 .1 .3 Cont inuous ope r a t ion One of t he m ost com m on reasons for developing a dist ribut ed dat abase syst em is t o provide redundancy and fault t olerance. By t he sam e t oken, a dist ribut ed syst em should not require scheduled out ages t o perform m aint enance such as adding and rem oving a sit e or upgrading soft ware. Of course, in t he ideal world we would have zero downt im e, scheduled or not , but even Chris Dat e is willing t o concede t hat " unplanned out ages are difficult t o avoid ent irely."

5 .1 .1 .4 Loca t ion t r a n spa r e n cy Locat ion t ransparency is t he not ion t hat dat a and dat a operat ions appear t he sam e t o users ( and developers) regardless of where dat a resides. Users should not have t o t ake any special m easures t o access dat a t hat is in m ult iple locat ions, nor should developers need t o writ e addit ional code t o perform a dist ribut ed t ransact ion. Dat a, t ables, and ot her obj ect s can be viewed as logical ent it ies, one st ep rem oved from t heir physical im plem ent at ion. The DBA should be able t o relocat e dat a wit hout requiring new user account s or new code.

5 .1 .1 .5 Fr a gm e nt a t ion in de pe n de n ce The not ion of fragm ent at ion independence t akes locat ion t ransparency one st ep furt her. Whereas locat ion t ransparency refers t o t he abilit y t o locat e ent ire t ables and views t ransparent ly, fragm ent at ion independence is t he abilit y t o part it ion dat a wit hin a t able ( or, m ore accurat ely, wit hin a relat ion) t ransparent ly. ( This division of dat a is also known as dat a part it ioning, especially in Oracle circles.) For exam ple, an organizat ion m ay keep em ployees' t elephone ext ensions in one t able in t he corporat e com m unicat ions dat abase and t heir depart m ent num bers in anot her t able in t he HR

124

Oracle Distributed Systems dat abase. However, a user ( or applicat ion) can j oin t his dat a t oget her and view it as t hough it were in a single t able, as shown in Figure 5.1.

Figu r e 5 .1 . V e r t ica l pa r t it ion in g

Dat a can also be part it ioned horizont ally. For exam ple, individual franchises in a chain of bicycle st ores t rack t heir own cust om ers' addresses and purchases, but analyst s at t he headquart ers sit e are able t o view all regist er sales as t hough t he records were in a single t able, as shown in Figure 5.2.

Figu r e 5 .2 . H or izon t a l pa r t it ion in g

125

Oracle Distributed Systems The sam e rest rict ions apply t o bot h updat eable j oin views and fragm ent at ion independence. The fact t hat fragm ent at ion independence is relat ively sim ple wit h relat ional dat abase t echnology is one of t he reasons why dist ribut ed dat abases are invariably relat ional dat abases.

5 .1 .1 .6 Re plica t ion in de pe n de n ce I n order t o m eet t he replicat ion independence obj ect ive, a dist ribut ed syst em m ust provide a m eans of m aint aining copies of t he sam e dat a ( i.e., t ables) at m ult iple sit es. As we shall see in Part I I , reasons t o replicat e include perform ance gains and failover capabilit y, t o nam e a few. The challenge wit h providing replicat ion independence is t hat when dat a is changed, t he change m ust propagat e t o all replicas, as soon as possible. Users and applicat ions should not be concerned wit h how t heir changes t o a replicat ed t able are propagat ed or whet her t heir version of t he t able is up t o dat e. Technically, replicat ion independence requires t hat changes be propagat ed t o all sit es and com m it t ed as a single t ransact ion using t he t wo- phase com m it prot ocol. However, enforcem ent of t his st ipulat ion can defeat t he purpose of replicat ing in t he first place since t he addit ional com m unicat ion required im pact s perform ance and since processing is halt ed if any sit e is unavailable.

5 .1 .1 .7 D ist r ibu t e d qu e r y pr oce ssin g The perform ance of a query should not depend on where t he dat a resides. The opt im izat ion of dist ribut ed queries is vit al because a poor execut ion plan can t ake orders of m agnit ude longer t han t he " correct " one. For exam ple, if a query includes a large int erm ediat e result set , t hat dat a probably should not be shipped over t he net work t o t he dat abase wit h a sm all t able t hat is t o be j oined wit h t he result set .

5 .1 .1 .8 D ist r ibu t e d t r a n sa ct ion m a n a ge m e n t A dist ribut ed syst em m ust guarant ee t he concurrency of dist ribut ed t ransact ions. I n ot her words, if a t ransact ion is t o updat e t ables at t wo different sit es, t he t ransact ion m ust eit her succeed bot h places or fail bot h places. This, of course, is what t he t wophase com m it prot ocol provides.

5 .1 .1 .9 H a r dw a r e in de pe n de n ce The various part icipant s in a dist ribut ed syst em should be able t o run on what ever hardware plat form suit s t heir needs. I n effect , t his m eans t hat t he RDBMS should run on all conceivable plat form s and include t he sam e funct ionalit y across all plat form s.

5 .1 .1 .1 0 Ope r a t in g syst e m in de pe n de n ce The RDBMS should be able t o run under any operat ing syst em or at least under any of t he popular operat ing syst em s. Do not allow your choice of RDBMS t o t ie you t o a part icular operat ing syst em .

5 .1 .1 .1 1 N e t w or k in de pe n de n ce

126

Oracle Distributed Systems Just as it is desirable for an RDBMS t o work on any hardware and any operat ing syst em , it is also desirable for it t o be able t o com m unicat e wit h client s and ot her dat abases regardless of net work prot ocols and archit ect ures.

5 .1 .1 .1 2 RD BM S in de pe n de n ce I deally, it should be possible t o creat e a het erogeneous dist ribut ed syst em . For exam ple, we should be able t o replicat e dat a bet ween an Oracle dat abase and a Sybase dat abase. I n act ual fact t hough, it can be difficult j ust t o dist ribut e dat a bet ween t wo different versions of t he sam e RDBMS!

5 .1 .2 D ist r ibu t e d Syst e m Cla ssifica t ion s The t erm dist ribut ed dat abase syst em envelops several very different im plem ent at ions and archit ect ures. I t is wort hwhile t o ident ify t hese various classificat ions before discussing design issues. The general cat egories are: • • • •

Hom ogeneous dist ribut ed syst em s Het erogeneous dist ribut ed syst em s Federat ed dat abase syst em s Redundant backup syst em s

These classificat ions are defined in t he sect ions t hat follow.

5 .1 .2 .1 H om oge n e ou s dist r ibu t e d syst e m s The hom ogeneous dist ribut ed syst em is t he classic and probably m ost com m on case. I t is hom ogeneous because all part icipat ing dat abases use t he sam e RDBMS ( t hough not necessarily on t he sam e plat form ) . The second defining charact erist ic of a hom ogeneous dist ribut ed syst em is t hat dat a is st rat egically part it ioned along funct ional and/ or geographic boundaries and m akes use of dist ribut ed queries and t ransact ions. Addit ionally, t hese syst em s share schem a under a global dat a dict ionary. The ent ire dat abase is t ruly t he sum of it s part s, yet each individual dat abase is self- reliant , as described by Dat e's 12 obj ect ives. As an exam ple of a hom ogeneous dist ribut ed syst em , consider t he fict it ious Bigwheel Bicycle com pany. Bigwheel's corporat e headquart ers is in California, and t hey have several ret ail out let s t hroughout t he count ry. Bigwheel also has m anufact uring sit es and warehouses ( see Figure 5.3) . Toget her, t hese dat abases paint a com plet e pict ure of Bigwheel Bicycle's product ion, invent ory, and sales. At t he sam e t im e, each sit e can funct ion independent ly from it s peers ( albeit in a som ewhat dim inished capacit y in som e cases) .

Figu r e 5 .3 . Th e Bigw h e e l Bicycle com pa n y's dist r ibu t e d da t a ba se e m pir e

127

Oracle Distributed Systems

5 .1 .2 .2 H e t e r oge n e ou s dist r ibu t e d syst e m s A het erogeneous dist ribut ed syst em has all t he charact erist ics of a hom ogeneous syst em , including shared schem a, except t hat t he part icipat ing dat abases use t wo or m ore RDBMS engines. Generally speaking, t hese syst em s share dat a but are less likely t o engage in dist ribut ed t ransact ions. This rest rict ion arises because it can be difficult t o use t he full funct ionalit y of an RDBMS when int erfacing wit h an alien. St rict ly speaking, different versions of RDBMS soft ware from t he sam e vendor can be classified as a het erogeneous dist ribut ed syst em and can have lim it at ions. For exam ple, Oracle Version 6 does not support t he t wo- phase com m it .

5 .1 .2 .3 Fe de r a t e d da t a ba se syst e m s Federat ed dat abase syst em s differ from hom ogeneous and het erogeneous syst em s because t hey do not share schem a. Rat her, t hey share subset s of t heir dat a t o facilit at e operat ions at ot her sit es, wit h which t here is usually no funct ional relat ionship. The dat a t hat a sit e is willing t o share is known as export ed schem a, and t he rem ot e dat a t o which a sit e has access is known as im port ed schem a. Part icipant s in a federat ed dat abase syst em are com plet ely independent of one anot her and m ay or m ay not use t he sam e RDBMS. This independence is usually not by design. Organizat ions usually creat e federat ed dat abase syst em s in response t o needs t hat arise aft er t he original syst em s are in product ion. This m odel is t he m ost com m on t ype of dist ribut ed dat abase syst em — perhaps because a federat ed dat abase is easy t o creat e wit h a m inim al am ount of planning.

128

Oracle Distributed Systems An exam ple of a federat ed dat abase syst em is t he fict it ious Bigwheel Bicycle com pany's cust om er and sales lead dat abases. The cust om er dat abase is t he propert y of t he cust om er adm inist rat ion group, which services t he bicycle shops t hat have cont ract ed t o carry Bigwheel's product line. Meanwhile, t he sales lead dat abase belongs t o t he t ravelling sales force whose j ob is t o enlist as m any bicycle shops as possible t o carry Bigwheel's product s. The cust om er adm inist rat ors have grant ed t he sales force access t o t heir dat abase so t hat t hey can t rack how m any of t heir sales leads act ually becom e cust om ers.

5 .1 .2 .4 Re du n da n t ba ck u p syst e m s The redundant backup syst em is a special case of a hom ogeneous syst em and is a popular applicat ion of replicat ion t echnology. This st rat egy ent ails m irroring a prim ary dat abase wit h an exact copy, which m ay be at a separat e locat ion. Using replicat ion t echnology, all com m it t ed t ransact ions in t he prim ary dat abase propagat e t o t he m irror. However, unlike a hom ogeneous syst em , t he m irror sit e is not available t o users as long as t he prim ary sit e is operat ional. I f t he prim ary sit e becom es unavailable, users and applicat ions can be redirect ed t o t he m irror sit e where t hey can cont inue processing.

5 .1 .2 .5 D ist r ibu t e d syst e m cla ssifica t ion s: Su m m a r y To sum m arize, t he fact ors t hat det erm ine a given archit ect ure's classificat ion are: • • •

Sam e or different RDBMSs Presence or absence of shared schem a and global dat a dict ionary Sit e availabilit y

Part icipant s in hom ogeneous and het erogeneous syst em s share a global dat a dict ionary, and alt hough each m em ber should be self- sufficient , each is a key cont ribut or t o t he overall syst em . Federat ed dat abases, on t he ot her hand, do not share a global dat a dict ionary and are not com plem ent ary com ponent s of an overall syst em . Finally, t he redundant backup syst em consist s of a m ast er sit e and it s m irror. These configurat ions are designed t o address high availabilit y requirem ent s. Table 5.1 sum m arizes t he various charact erist ics of dist ribut ed dat abases.

Table 5.1. Distributed Database Classifications Classification

Same RDBMS

Global Data Dictionary

All Sites Available

Hom ogeneous

Yes

Yes

Yes

Het erogeneous

No

Yes

Yes

Federat ed

Maybe

No

Yes

Redundant backup

Yes

Yes

No

5 .2 Th e Globa l D a t a D ict ion a r y I n Table 5.1 we see t hat t he not ion of a global dat a dict ionary is com m on t o all but t he federat ed m odel of dist ribut ed dat abase syst em s. The dat a dict ionary cat alogs all

129

Oracle Distributed Systems obj ect s in t he dist ribut ed schem a, is available at every sit e, and is accessed ident ically no m at t er where it is viewed. I t defines t he dist ribut ed dat abase and shields users, including applicat ion developers, from t he det ails of where dat a resides and how it is accessed. Obviously, t here are a num ber of challenges in concealing t he seam s of t he dist ribut ed dat abase from t he users while respect ing t he obj ect ives of a dist ribut ed syst em . I ssues t hat m ust be addressed include: • • • • •

Placem ent of t he global dat a dict ionary Obj ect nam ing The local dat a dict ionary Managem ent of int erdat abase int egrit y const raint s Managem ent of user account s and privileges

These issues are discussed in t he sect ions t hat follow.

5 .2 .1 Pla ce m e n t of t h e Globa l D a t a D ict ion a r y The challenge here is how t o m ake t he dict ionary available and ident ical t o all sit es and respect t he 12 obj ect ives of a successful dist ribut ed dat abase. A cent ralized cat alog violat es t he " No reliance on a single sit e" obj ect ive. Yet st oring a com plet e copy of t he dict ionary at all sit es violat es t he local aut onom y obj ect ive since local changes m ust be propagat ed t o all part icipat ing sit es. Anot her opt ion is t o m ake each sit e responsible for it s port ion of t he cat alog only; alt hough t his m eet s t he obj ect ives of a dist ribut ed dat abase, it is generally not pract ical since resolving t he locat ion of rem ot e obj ect s would launch a blind and pot ent ially lengt hy hunt ing expedit ion t o t he rem ot e sit es in search of t he referenced obj ect . Clearly t hen, RDBMS vendors m ust st rike som e happy m edium in order t o support a dist ribut ed dat abase devoid of seam s and not prone t o hunt ing expedit ions or ot her ext ravagances when t rying t o resolve obj ect nam es. The solut ion t hat Oracle and ot her vendors have arrived at is t o st ore inform at ion about t he locat ion of rem ot e obj ect s in each local dat a dict ionary. That is, t here is no such t hing as a global dat a dict ionary in t he purest sense. At first glance, t his approach appears t o violat e t he locat ion t ransparency obj ect ive. Rem em ber, t hough, t hat locat ion t ransparency is in t he eye of t he user. As long as t here is a way t o shield users from t he det ails about an obj ect 's locat ion, which Oracle does wit h synonym s, locat ion t ransparency is achieved. I t is t he DBA who has t o worry about t he obj ect s' act ual locat ions and about concealing t he det ails of t he locat ion. We'll explore t he specifics of t he Oracle im plem ent at ion in Chapt er 6.

5 .2 .2 Obj e ct N a m in g The way t hat Oracle and ot her RDBMS vendors incorporat e an obj ect 's locat ion int o t he dat a dict ionary is t o design obj ect nam ing so t hat t he locat ion is a com ponent of an obj ect 's fully qualified nam e. For exam ple, t able PRODUCTS is in t he SPROCKET schem a in t he dat abase nam ed D7CA.BI GWHEEL.COM. I t s fully qualified nam e is [email protected] GWHEEL.COM. I n every dat abase in t he dist ribut ed environm ent , t his nam e equat es t o t he sam e physical t able. Unfort unat ely, t he fully

130

Oracle Distributed Systems qualified nam e violat es t he locat ion t ransparency obj ect ive. The solut ion is t o creat e asynonym for t he obj ect so t hat users can reference it by t he nam e PRODUCTS: CREATE PUBLIC SYNONYM products FOR [email protected]; Not e t hat public synonym s do not span all dat abases in t he dist ribut ed syst em . There is no guarant ee t hat PRODUCTS in t he headquart ers dat abase evaluat es t o t he sam e t hing as PRODUCTS in t he warehouse dat abase. Sim ilarly, since users m ay be able t o creat e privat e synonym s, t here is not even a guarant ee t hat PRODUCTS for user cdye refers t o t he sam e t able as PRODUCTS for user j blow. All t hat can be guarant eed is t hat a fully specified nam e evaluat es t o t he sam e t hing for every user in every dat abase. I t is up t o t he DBA and t he applicat ion developer t o ensure t hat t he proper synonym s are set up and t o updat e t hese synonym s if an obj ect ( or fragm ent t hereof) m oves t o anot her dat abase.

Som e RDBMSs ( m ost not ably I BM's R* ) refer t o an obj ect 's birt h sit e rat her t han it s locat ion. An obj ect 's locat ion can change, but it s birt h sit e cannot . I dent ifying an obj ect by birt h sit e reduces t he dat a dict ionary m aint enance t hat is required when an obj ect relocat es.

From an applicat ion developm ent perspect ive, obj ect nam es m ust be select ed wit h care so t hat t hey do not conflict wit h ot her nam es from ot her schem a. Table nam es like USERS, CUSTOMERS, and ADDRESSES are exam ples of com m on nam es t o avoid because t hey are likely t o conflict wit h nam es from ot her applicat ion schem a.

5 .2 .3 Th e Loca l D a t a D ict ion a r y I n a well- designed dist ribut ed dat abase syst em , t he m aj orit y of dat a accesses will be t o local dat a. Sim ilarly, m any, if not m ost , obj ect s in t he dat abase are not accessible or known t o rem ot e sit es. Therefore, it is reasonable t o opt im ize t he dat a dict ionary for local use, while providing t he ext ensibilit y needed t o cat alog rem ot e obj ect s as well. The am ount of inform at ion available about rem ot e obj ect s varies from one RDBMS t o t he next , but at t he very least , t he physical locat ion of rem ot e obj ect s m ust be recorded. Beyond t hat , it is also desirable t o include st at ist ics about t he volum e and dist ribut ion of t he rem ot e dat a so t hat t he RDBMS can opt im ize queries effect ively.

5 .2 .4 M a n a ge m e n t of I n t e r da t a ba se I n t e gr it y Con st r a in t s The not ion of a dist ribut ed dat abase invit es t he desire t o enforce business rules across m ult iple dat abases. These business rules m ay be sim ple referent ial int egrit y const raint s, such as " t he cust om er I D in t he ORDERS t able m ust correspond t o a cust om er I D in t he HQ_CUSTOMERS t able." Or t he business rule m ay be a form ulat ed one, such as " corporat e shipping cost s cannot exceed $10,000 per

131

Oracle Distributed Systems m ont h." I n a single dat abase, t hese rules are sim ple t o enforce wit h foreign keys and program m ed logic, bot h of which m ay reside in t he local dat a dict ionary. A dist ribut ed dat abase, on t he ot her hand, poses form idable challenges. To support referent ial int egrit y const raint s t o a parent t able in a rem ot e dat abase, we could rely on connect ivit y t o t he rem ot e dat abase when updat ing t he local child t able so t hat we could confirm t he validit y of t he updat e. Unfort unat ely, we would have t o writ e our own logic t o perform t his validat ion because t oday's RDBMS dat a dict ionaries do not support foreign keys defined against rem ot e m ast er t ables, nor are t hey likely t o in t he fut ure. Alt ernat ively, we could m aint ain a copy of t he m ast er t able in t he local dat abase and define foreign keys against it . The only problem is t hat we would have t o keep t hat t able updat ed as t he " real" t able changes. Alt hough neit her of t hese solut ions is flawless, t hey are, at least , logically sound. Enforcing form ulat ed business rules is a m uch t rickier t ask. Take t he case of t he $10,000 m ont hly shipping lim it . I f t he corporat ion's cum ulat ive shipping cost s for t he current m ont h are current ly $9,000, and t he warehouse sit e needs t o ship an it em for $2,000, what are we t o do? To rej ect t he warehouse sit e's shipping order violat es t he dat abase's aut onom y, yet allowing t he order violat es t he global business rule. Perhaps we should perm it t he shipm ent but send som e sort of except ion not ificat ion t o t he headquart ers sit e. Regret t ably, t here is no definit ive solut ion t o t his conundrum . The final solut ion depends on t he nat ure of t he organizat ion—t hat is, t he solut ion is specific t o t he applicat ion. The dat a dict ionary cannot enforce form ulat ed rules in a dist ribut ed syst em . I n short , t he issues of dat a int egrit y and adherence t o business rules t hat can be aut om at ed t o a large degree in a single dat abase are m uch m ore difficult t o im plem ent in a dist ribut ed dat abase. You will not find a sim ple solut ion, and t he solut ions you choose m ay vary widely from one applicat ion t o t he next .

5 .2 .5 M a n a ge m e n t of Use r Accou n t s a n d Pr ivile ge s Just as dat a int egrit y is m uch m ore com plex in a dist ribut ed syst em , so is t he m anagem ent ofaccount s and privileges.We cannot rely on t he dat a dict ionary t o enforce access levels t o local obj ect s once we share dat a wit h rem ot e sit es. Yet t he obj ect ive of local aut onom y dict at es t hat t he local sit e t ake responsibilit y for t he securit y of it s dat a. Anot her conundrum ? Maybe. One solut ion is t he concept of global users. Under t his m odel, every user has an account in every dat abase t o which he requires access, even if t he user doesn't even realize it . For exam ple, if a user in t he headquart ers dat abase requires access t o t he warehouse and m anufact uring dat abases in order t o view invent ory, t he DBAs creat e t he requisit e account s wit h t he requisit e privileges. Since access t o t he dat a is via a synonym t hat m asks t he locat ion of t he dat a, t he user does not even know t hat t he ot her account s exist . This sit uat ion is shown in Figure 5.4.

Figu r e 5 .4 . Tr a n spa r e n t a cce ss t o r e m ot e da t a u sin g a pr iva t e da t a ba se lin k

132

Oracle Distributed Systems

The at t ract ion of t his approach is t hat t he DBA can cont rol dat a access wit h a high degree of granularit y and can adm inist er privileges t hrough convent ional m et hods such as dat abase roles. I n addit ion, each sit e is solely responsible for t he securit y of it s dat a. The disadvant age is t hat t he DBA could end up doing not hing but m aint aining user account s! One alt ernat ive, as discussed in Chapt er 4, is t o creat e one or m ore account s t hat are used as global doorways int o t he local dat abase. These account s have all t he privileges necessary for t he operat ions t hat m ight be perform ed on t he local dat a. Presum ably, a m em ber of a dist ribut ed dat abase can t rust t he rem ot e adm inist rat ors of t he rem ot e dat abases t o rest rict access t o appropriat e levels. We have seen t hat a dist ribut ed dat abase syst em requires a global dat a dict ionary t hat can cat alog obj ect s, const raint s, and privileges j ust as a local dat a dict ionary does. However, it is not reasonable t o im pose obj ect ives such as locat ion t ransparency on t he global dat a dict ionary it self, nor is it feasible t o rely on a global dat a dict ionary t o enforce int egrit y const raint s and user privileges on rem ot e obj ect s. These requirem ent s becom e t he responsibilit y of t he DBAs and applicat ion developers.

5 .3 Re plica t ion- Spe cific I ssu e s Building a syst em for replicat ion m eans addressing a variet y of design and configurat ion issues t hat are irrelevant in a st andalone environm ent . As a general rule, it is not possible t o " t urn on" replicat ion for an exist ing, st andalone syst em , t hough som e have t ried. I t em s requiring at t ent ion include replicat ion archit ect ure, dat a consist ency, dat a ext ract ion, schem a differences, prim ary key const raint s, and conflict ion avoidance—t o nam e a few. The sect ions t hat follow highlight t hese concerns.

133

Oracle Distributed Systems

5 .3 .1 Re plica t ion Ar ch it e ct u r e There are t wo broad cat egories of replicat ion archit ect ure: log- based replicat ion and t ransact ional replicat ion. Log- based replicat ion works by exam ining t he dat abase's t ransact ion logs ( redo logs in t he case of Oracle) and forwards com m it t ed changes t o ot her part icipat ing dat abases as needed. ( Quest Soft ware's Shareplex product is an exam ple.) Transact ional replicat ion, on t he ot her hand, works by eit her querying t he rem ot e dat abase ( in t he case of read- only snapshot s) and adding t riggers t o replicat ed t ables t hat effect t he forwarding of changes t o rem ot e sit es. Oracle's advanced replicat ion facilit ies are an exam ple of t his t echnology. One of your first choices is which of t hese t wo m echanism s t o use.

5 .3 .1 .1 Log- ba se d r e plica t ion Log- based replicat ion has various advant ages and disadvant ages.

5 .3 .1 .1 .1 Adva nt a ge s The prim ary benefit s of log- based replicat ion are speed and ease of configurat ion. Since t his t echnology sim ply forwards changes from t he dat abase t ransact ion log t o rem ot e dest inat ions, t here is no need for a t wo- phase com m it prot ocol or even int erdat abase com m unicat ion. That m eans t hat you can use an FTP prot ocol t o m ove dat a, which is generally fast er and sim pler t han, say, SQL* Net . Log- based replicat ion can be a viable solut ion when you want t o forward changes over t he I nt ernet . Log- based replicat ion is also relat ively sim ple t o configure; you do not need t o generat e t riggers on replicat ed t ables or design conflict resolut ion t echniques or set up int erdat abase com m unicat ion.

5 .3 .1 .1 .2 D isa dva nt a ge s Alas, t here is no free lunch. Log- based replicat ion includes som e rest rict ions. For exam ple, dist ribut ed t ransact ions becom e m uch m ore com plex or im possible. That lim it s your dat a part it ioning opt ions. I n addit ion, dat abase recovery can be difficult in an environm ent wit h a high t ransact ion rat e. You m ust apply not only t he dat abase's t ransact ion logs, but also t he logs applied from t he rem ot e dat abases. Recovering m ult iple dat abases t o t he sam e point in t im e can be com plex. Finally, adding or rem oving t ables from t he replicat ion set can be difficult , depending on t he vendor's im plem ent at ion. Finally, synchronous replicat ion is not possible.

5 .3 .1 .2 Tr a nsa ct iona l r e plica t ion Transact ional replicat ion also has various advant ages and disadvant ages.

5 .3 .1 .2 .1 Adva nt a ge s Transact ional replicat ion t echnology, such as Oracle's advanced replicat ion facilit ies, offers t he flexibilit y t o dist ribut e dat a in a variet y of ways, such as read- only snapshot s, updat eable snapshot s, m ult i- m ast er replicat ion, and synchronous or

134

Oracle Distributed Systems asynchronous operat ion. You can m ix and m at ch your replicat ion m et hod t o suit your needs. Because t he funct ionalit y is built wit h t he dat abase's nat ive program m ing const ruct s, it is readily configured and guarant eed t o be support ed by t he RDBMS vendor. You can also part it ion dat a so t hat each sit e m aint ains only t he dat a relevant t o it . You also have a variet y of opt ions for resolving conflict s, as discussed in Chapt er 15.

5 .3 .1 .2 .2 D isa dva nt a ge s The biggest drawback t o t ransact ional replicat ion is t hat large applicat ions require a significant am ount of design effort t o replicat e successfully. Conflict avoidance and resolut ion m ust be planned from t he st art ; t ables m ay need addit ional colum ns t o record t im est am ps and sit e nam es; and dat abase connect ivit y m ust be est ablished wit h proper privileges. Anot her drawback is t hat t he am ount of dat a t hat m ust t ravel am ong sit es is increased; for exam ple, Oracle's advanced replicat ion facilit ies send t he new and old values of each changed colum n when an updat e occurs. Transact ional replicat ion can also be t im e consum ing t o adm inist er. Finally, not all dat at ypes and obj ect s can be replicat ed; Oracle does not replicat e sequences or LONG or LONG RAW dat a ( alt hough CLOBs and BLOBs do replicat e in Oracle8) .

5 .3 .2 Soft w a r e Com pa t ibilit y Soft ware versions are m ore significant in a replicat ed environm ent because vendors oft en int roduce new funct ionalit y and fix bugs. I t is best t o keep all part icipat ing dat abases on t he exact sam e version of t he RDBMS, despit e vendor claim s of int erversion com pat ibilit y. This m eans t hat dat abase upgrades m ust be m anaged m ore carefully; unless t he vendor support s rolling upgrades, you m ust upgrade all dat abases at t he sam e t im e, t hus incurring downt im e.

5 .3 .3 D a t a Con sist e n cy Depending on t he vendor's im plem ent at ion, you m ay have t o schedule dat a refreshes in a cert ain order if t he source t ables have referent ial int egrit y const raint s defined. For exam ple, if a snapshot sit e has replicas of t he CUSTOMERS t able and t he ORDERS t able, which has a foreign key t o t he CUSTOMERS t able, you will have t o refresh t he CUSTOMERS t able before you refresh t he ORDERS t able. This requirem ent arises because t he dat a refresh m ay com m it changes aft er each t able is refreshed; if you refresh t he ORDERS t able first , you could insert a record t hat has no parent in t he CUSTOMERS t able.

Oracle addresses t his event ualit y by allowing you t o creat e a snapshot group, in which you include t ables t hat m ust be refreshed as a single t ransact ion in order t o respect referent ial int egrit y const raint s.

135

Oracle Distributed Systems

5 .3 .4 D a t a Ex t r a ct ion Som et im es it is desirable for a sit e t o st ore dat a in a schem a t hat is different from t he dat a source. For exam ple, a dat a warehouse sit e m ay wish t o denorm alize t he replicat ed ORDERS t able so t hat it has a CUSTOMER_NAME field, whereas t he order ent ry sit e has only CUSTOMER_I D in t he t able. Whenever dat a ext ract ions occur against replicat ed t ables, t he designers m ust verify t hat t he work required can be accom plished wit hout int erfering wit h t he replicat ion it self. Must t he source t ables be locked while t he dat a is ext ract ed? Can t he refreshes occur while t ransact ions are being perform ed, or m ust t hey be done during off- hours?

5 .3 .5 Pr im a r y Ke ys Every replicat ed t able m ust have eit her a prim ary key or, equivalent ly, a unique index. The replicat ion m echanism uses t he prim ary key ( or unique index) t o ident ify which rows need t o be m odified when changes are propagat ed from one sit e t o anot her. Alt hough prim ary keys are a sound design pract ice in and of t hem selves, you m ust ensure t heir presence on all replicat ed t ables.

5 .3 .6 Con flict Avoida n ce Any asynchronously replicat ed environm ent has t he pot ent ial for updat e conflict s. Such a conflict arises when t wo sit es perform DML on t he sam e record at t he sam e t im e ( or at least before t he changes propagat e) . To a large ext ent , you can design an applicat ion in such a way t hat such conflict s are rare ( conflict avoidance) . Beyond design considerat ions, m ost RDBMS vendors include various built - in m easures for resolving conflict s when t hey do arise. Conflict avoidance, det ect ion, and resolut ion are discussed in det ail in Chapt er 15.

5 .4 D a t a Pa r t it ion in g M e t h odologie s Part it ioned dat a is t he fundam ent al charact erist ic of a dist ribut ed dat abase syst em . How t hat part it ioning is done can m ake t he difference bet ween a syst em t hat can t hrive and adapt and one t hat requires const ant t riage. I n t his sect ion we describe a process you can use t o ensure t hat your dist ribut ed dat abase falls int o t he form er cat egory.

Many t echnical writ ings use t he t erm dat a fragm ent at ion inst ead of dat a part it ioning. These t erm s are int erchangeable. Oracle's docum ent at ion and lit erat ure prefer t he lat t er t erm , possibly because dat a " fragm ent at ion" in Oracle parlance has com e t o m ean a segm ent t hat is st ored in m any noncont iguous ext ent s.

The obvious approach t o dat a part it ioning is t o locat e dat a where it is used m ost . While t his is cert ainly a reasonable obj ect ive, it is not always sim ple t o realize. For

136

Oracle Distributed Systems exam ple, t here m ay be m ult iple sit es t hat em erge as good candidat es, owners of exist ing dat a m ay not be willing t o relocat e it , or ot her applicat ions m ay have conflict ing requirem ent s—t o nam e a few issues. One way t o uncover t hese issues is t o follow a st ep- by- st ep m et hodology t hat addresses pot ent ial problem s and t hat result s in a shared knowledge base of who uses dat a and how changes im pact t he dist ribut ed dat abase. The m et hodology we recom m end is derived from one t hat Marie Buret t a proposes in her book Dat a Replicat ion ( John Wiley & Sons, 1997) . The process consist s of t he following st eps: 1. 2. 3. 4. 5. 6. 7. 8. 9.

I dent ify users, locat ions, and act ivit ies Assess exist ing infrast ruct ure I dent ify coordinat ed recovery requirem ent s Map processes t o dat a Assess global requirem ent s Propose dat a locat ions Validat e dat a placem ent against exist ing const raint s and capacit ies Validat e placem ent wit h service- level agreem ent s I m plem ent

Som e of t hese st eps are act ually part of t he design process for every applicat ion but , in t he int erest of t horoughness, are rest at ed as part of t he part it ioning process. What follows is an explanat ion of t he act ivit ies associat ed wit h each of t hese st eps.

5 .4 .1 I de n t ify Use r s, Loca t ion s, a n d Act ivit ie s The purpose of t his first st ep is t o ident ify who does what where. The people t o include in t his st ep are t he DBAs of all part icipat ing sit es, a represent at ive from t he applicat ion developm ent t eam , and a represent at ive from each affect ed user com m unit y. I n m any cases, t he dist ribut ed dat abase being im plem ent ed m ust m eld int o an exist ing fam ily of dat abases. And even if t he im plem ent at ion is com plet ely new, it is valuable t o docum ent t his inform at ion t o confirm t hat all int erest ed part ies are in agreem ent and as a basis for planning t he syst em . One cannot locat e dat a wit h t he sit es t hat use it m ost wit hout going t hrough t his exercise. Table 5.2 is a sam ple of t he inform at ion t hat should be collect ed in t his st ep.

Table 5.2. Distributed Database Usage Matrix Site Category

Geographic Location

Type/Number of Users Sales m anagers/ 12 Sales analyst s/ 5

Headquart ers Los Alt os, CA Product developers/ 20

Business Processes and Transactions/Queries per Day Sales forecast ing/ 10 Sales report ing/ 20 R & D/ 200 Technical support / 150

137

Oracle Distributed Systems

Support st aff/ 4

Account s payable/ 12

AP st aff/ 4

Account s receivable/ 75

AR st aff/ 5 Plant m anagers/ 3 Manufact uring Gilroy, CA

Procurem ent m anager/ 1 Plant m anagers/ 2

King of Prussia, PA Warehouses

Procurem ent m anager/ 1

Resource planning/ 20 Procurem ent / 5 Resource planning/ 5 Procurem ent / 1

Oakland, CA

Shipping adm ins/ 10 Order fulfillm ent / 150

Tulsa, OK

Shipping adm ins/ 5

Order fulfillm ent / 10

Chicago, I L

Shipping adm ins/ 3

Order fulfillm ent / 30

Anacost ia, MD Shipping adm ins/ 5

Order fulfillm ent / 50

Sales m anagers/ 2 Cust om er reps/ 4 San Francisco, Regional sales CA Order ent ry clerks/ 15 Webm ast er/ 1 Sales m anager/ 1 New York, NY

Cust om er reps/ 2

Sales dat a collect ion/ 200 Cust om er service/ 10 Order ent ry/ 150 Web m arket ing/ 2000 Sales dat a collect ion/ 300 Cust om er service/ 100

Cat alog sales clerks/ 10

Order ent ry/ 250

Tokyo, Japan

Sales st aff/ 5

Sales dat a collect ion/ 100

Paris, France

Sales st aff/ 3

Sales dat a collect ion/ 50

This m at rix provides a sound st art ing point for t he rem aining t asks at hand. I t provides an overview of t he locat ions, locat ion t ypes, and user t ypes, as well as an approxim at ion of t he workload at each sit e. Not e t hat we can expect sim ilar act ivit ies and dat a at locat ions of t he sam e t ype ( e.g., all warehouse sit es in t he above exam ple perform order fulfillm ent ) .

5 .4 .2 Asse ss Ex ist in g N e t w or k a n d H a r dw a r e I n fr a st r u ct u r e Now t hat we know what processes occur where and have an rough est im at e of workload, we can verify t hat t he organizat ion's physical infrast ruct ure is sufficient and appropriat ely deployed. To t hat end, we should com pile an invent ory of t he following:

138

Oracle Distributed Systems • • • • •

Net work t opologies Com put er equipm ent ( servers) Operat ing syst em and dat abase revision levels Securit y requirem ent s Syst em availabilit y and support

Collect ing t his inform at ion will bring t o light any inconsist encies, conflict s, or m isallocat ions t hat m ay exist in t he current environm ent . I n addit ion, t he invent ory can help t o j ust ify addit ional equipm ent purchases. The com piled dat a can be present ed in a m at rix sim ilar t o t he one shown in Table 5.3.

Table 5.3. Infrastructure Summary Location and Type

OS Version Connectivity

Servers

Security

Availability and Support

RDBMS T1—Gilroy T1—San Francisco FR[ 1] —New York FR[ 1] —Tokyo

Los Alt os Headquart ers

FR[ 1] —Paris 256KB—K of P 256KB— Oakland

Sun e6000

Solaris 2.6

7x24 High

Sun e3000

Oracle 7.3.4

Full support

128KB—Tulsa I SDN— Chicago I SDN— Anacost ia T1—Oakland Gilroy Manufact uring

King of Prussia

I SDN—Tulsa

Sun e3000

256KB— Chicago T1—Anacost ia

Sun Ult ra2

Solaris 2.6

7x24 Medium

Oracle 7.3.4 Solaris

Medium

On- sit e support during business hours 7x24

139

Oracle Distributed Systems

Manufact uring

2.6

On- sit e support during business hours

Oracle 7.3.4 Oakland Warehouse

Tulsa

T1—Gilroy 128KB—Los Alt os I SDN—Gilroy

Warehouse

128KB—Los Alt os

Chicago

I SDN—Los Alt os

Warehouse

Anacost ia Warehouse

Sun Ult ra2

Sun Ult ra1

Sun e3000

Solaris 2.6 Low Oracle 7.3.4 Solaris 2.6 Low

Solaris 2.6

T1—K of P

Solaris 2.6

I SDN—Los Alt os

Sun Ult ra2

San Francisco

Oracle 7.3.4 Solaris 2.6

New York Sales

Tokyo Sales

Paris Sales

[ 1]

FR[ 1] —Los Alt os

FR[ 1] —Los Alt os

[ 1]

FR —Los Alt os

Rem ot e adm in from New York 7x24

Medium Sun Ult ra1

Sales

Cont ract ed support services 5x8

Low

T1—Los Alt os

Rem ot e adm in from Los Alt os 5x8

Low

256KB—Gilroy

On- sit e support during business hours 5x8

Oracle 7.3.4

Oracle 7.3.4

Sun Ult ra1

5x8

Sun e3000

Sun Ult ra2

Sun Ult ra1

Oracle 7.3.4

Full support

Solaris 2.6

7x24 Medium Full support

Oracle 7.3.4 Solaris 2.6

5x8 High

Oracle 7.3.4 Solaris 2.6

Rem ot e adm in from San Francisco 7x24

Medium Oracle 7.3.4

Full support

Fram e relay

140

Oracle Distributed Systems

5 .4 .3 I de n t ify Coor din a t e d Re cove r y Re qu ir e m e n t s I t is oft en t he case t hat som e sit es in a dist ribut ed syst em are coupled m ore t ight ly t han ot hers. For exam ple, an order ent ry syst em m ust have close int egrat ion wit h an invent ory syst em , alt hough it need not be closely linked wit h t he procurem ent syst em . Tight ly coupled syst em s m ust observe int egrit y const raint s at all t im es and m ust support a coordinat ed recovery st rat egy, which m eans t hat all syst em s involved m ust be recoverable t o a consist ent st at e. Analyzing t he st rengt h of int ersit e relat ionships ensures t he survivabilit y of t he dist ribut ed dat abase and lends insight int o how dat a should be part it ioned. The first st ep in t his process is t o cat alog all t ables, relat ionships, and at t ribut es t hat exist in t he dist ribut ed dat abase. ( This cat alog provides benefit s in and of it self, beyond it s use in dat a recovery.) The cat alog reveals where obj ect s are used, how crit ical t hey are, and t he responsible business unit s. Table 5.4 out lines t he inform at ion t o be capt ured.

Table 5.4. Information for the Catalog of Tables, Relationships, and Attributes Component Table

Property

Comments

Nam e

Table nam e

Descript ion

Descript ion of t able's cont ent s

Prim ary key

Nam e of prim ary key colum n( s)

Foreign keys

Colum ns t hat reference ot her t ables

Triggers

Descript ion of t able's t riggers

Business guardian

Organizat ional ent it y responsible for specifying requirem ent s and business rules on t he t able

Est im at ed size

Num ber of rows and byt es per row

Est im at ed growt h Rat e of growt h ( insert s) and volat ilit y ( updat es) Confident ialit y level

I ndicat ion of dat a sensit ivit y

Crit icalit y level

I ndicat ion of dat a im port ance

Users

List of who accesses t he t able and t he t ype of act ivit y t hey perform

Ret ent ion requirem ent s

How long dat a m ust rem ain online

Purge condit ions

When and how dat a is delet ed

Relat ionship Nam e Table 1 nam e

Relat ionship nam e Nam e of first t able in t he relat ionship

Table 1 cardinalit y For exam ple, one- t o- m any Table 1 opt ionalit y

Whet her each row m ust have a correspondence in Table 2

Table 2 nam e

Nam e of second t able in t he relat ionship

Table 2 cardinalit y For exam ple, one- t o- m any Table 2 opt ionalit y

Whet her each row m ust have a correspondence in Table 1

141

Oracle Distributed Systems

At t ribut e

Nam e

Nam e of t he at t ribut e

Descript ion

Descript ion of what t he at t ribut e depict s

Business nam e

Business ent it y t o which t he at t ribut e corresponds

Dat a t ype

Dat at ype of t he at t ribut e

Confident ialit y level

I ndicat ion of dat a sensit ivit y

Where used

List of processes t hat access t he at t ribut e

Where present

List of t ables cont aining t he at t ribut e

The next st ep is t o dist inguish prim ary dat a sources ( i.e., t hose wit h online t ransact ions) from sit es where dat a is copied or replicat ed. St art wit h an ent it y relat ionship diagram ( ERD) so t hat it is easy t o det erm ine logical groupings of obj ect s and relat ionships. The goal is t o place every ent it y wit h a logical group. These groupings generally correspond t o business act ivit ies such as order ent ry or procurem ent . These act ivit ies, in t urn, generally correspond t o sit es. You should m inim ize int ersit e referent ial int egrit y const raint s since t hey can be t roublesom e t o enforce ( as we discussed in t he previous sect ion) . Maint aining int ersit e referent ial int egrit y const raint s during recovery is even m ore challenging and generally requires t hat t he sit es involved have a coordinat ed backup st rat egy. You will probably not ice t hat four different t ypes of relat ionships em erge am ong t he ent it ies in your dist ribut ed dat abase: Obj ect s wit h st rong referent ial links wit hin a single dat a grouping These are obj ect s t hat reside in t he sam e dat abase and t hat m ust be recovered t o a st at e of t ransact ional consist ency. Exam ples include t ables wit h a m ast er- child relat ionship such as invoices and line it em s. Obj ect s wit h m edium referent ial links and high volat ilit y wit hin a single dat a grouping These are obj ect s t hat probably reside in t he sam e dat abase and t hat should be recovered t o a st at e of t ransact ional consist ency. Exam ples include t ables wit h sem ant ic referent ial int egrit y const raint s such as orders and product s. The high volat ilit y refers t o a high volum e of updat es. Obj ect s wit h m edium referent ial links and low or m edium volat ilit y Obj ect s m eet ing t hese crit eria are not oft en updat ed and need not be st ored or recovered t oget her. An exam ple of t his t ype of relat ionship m ight be a purchase order m ast er t able and a cust om er t able. Relat ionships of t his kind are candidat es for denorm alizat ion or replicat ion. I t m ay also be possible t o part it ion t hese obj ect s horizont ally; for exam ple, t he West Coast order ent ry sit e m ight also m aint ain cust om ers locat ed in t hat region.

Denorm alizat ion of a dist ribut ed schem a m ust be done wit h care because t he t ask of prevent ing anom alies is significant ly m ore difficult . Do not denorm alize wit hout

142

Oracle Distributed Systems

providing processes t hat avoid updat e and delet e anom alies. Obj ect s wit h weak referent ial links Transact ion t ables whose colum ns are validat ed against lookup t ables are an exam ple of a weak referent ial link. For exam ple, an address t able m ay validat e t he post al code against a t able of post al codes, but t he post al code t able it self seldom changes and can be replicat ed t o t he sit es t hat use it for validat ion. The t erm s st rong, weak, high, m edium , and low in t he preceding discussion are all relat ive and m ust be assessed wit hin t he cont ext of your environm ent . The process of ident ifying coordinat ed recovery requirem ent s should not be considered an ext rem ely rigorous exercise; rat her, it should provide an underst anding of how dat a is used. Of course, t he exercise should reveal t he relat ionships t hat m ust be consist ent at all t im es, but t here are addit ional benefit s as well. I n part icular, if you follow t hese recom m endat ions you will have: • •

•

I dent ified your coordinat ed recovery requirem ent s Copied invent ory of all lookup t ables, which are candidat es for snapshot replicat ion I dent ified candidat es for part it ioning

5 .4 .4 M a p Pr oce sse s t o D a t a The next phase of t he process is t o det erm ine t he applicat ion processes in which each dat a group part icipat es and t o ident ify t he m ost significant processes. Significant m eans t he processes t hat execut e frequent ly, t hat are vit al t o t he business, t hat require rapid response t im es, or t hat m anipulat e large am ount s of dat a. The obj ect ive is t o creat e a m at rix depict ing how processes access dat a. The m at rix should capt ure t he t ype of access each process has t o t he t ables ( i.e., SELECT, I NSERT, UPDATE, and DELETE access) , sim ilar t o t he exam ple in Table 5.5.

Table 5.5. Process-to-Data Mapping Process

Customer Table Orders Table Product Table Invoice Table Sales Table SELECT

Sales dat a collect ion SELECT

SELECT

SELECT

No access

I NSERT

( high dat a volum e) UPDATE Cust om er service

SELECT

SELECT

SELECT

SELECT

SELECT

143

Oracle Distributed Systems

I NSERT UPDATE SELECT Order ent ry SELECT

I NSERT

SELECT

No access

No access

( business crit ical) UPDATE Order fulfillm ent

SELECT SELECT

( high t ransact ion rat e)

SELECT SELECT

UPDATE

No access I NSERT SELECT

Billing SELECT

SELECT

SELECT

I NSERT

No access

( business crit ical) UPDATE SELECT Product No access

No access

I NSERT

No access

No access

developm ent UPDATE

5 .4 .5 Asse ss Globa l Re qu ir e m e n t s Dist ribut ed dat abase syst em s, by t heir very nat ure, service a variet y of processes and applicat ions and have a diverse user com m unit y. The preceding st eps have been " applicat ion- cent ric" ; we have not yet account ed for t he requirem ent s of ot her business processes and users. Even if t his is a brand new syst em , confirm ing t hat t he requirem ent s of each business unit are underst ood and m et m eans avoiding unexpect ed consequences lat er. For dat a t hat is input for your applicat ion, you should ident ify t he prim ary dat a source, t he pot ent ial secondary sources, and t he volat ilit y of t he dat a. This inform at ion yields insight int o how you m ight access t he dat a. For exam ple, a night ly snapshot m ight work for dat a t hat is relat ively st at ic, whereas real- t im e access over a dat abase link m ight be required for dat a t hat changes rapidly. You also should est ablish a service- level agreem ent for t he dat a t hat is input t o your applicat ion. This ent ails defining t he requirem ent s for a variet y of m et rics, such as response t im e, availabilit y, dat a freshness, and securit y. I f t he input dat a should fall out side t he agreed- upon bounds, t he dat a owners m ust not ify you or your applicat ion, eit her t hrough an aut om at ed alert or possibly t hrough a m ore hum an form of com m unicat ion. By set t ing t hese expect at ions prior t o im plem ent at ion, you can be sure t hat your applicat ion is able t o obt ain t he input it needs in a t im ely m anner, and t he suppliers of t he dat a will be prepared for t he im pact your applicat ion has on t heir infrast ruct ure. The process for validat ing your applicat ion's out put dat a wit h ot her m em bers of t he organizat ion is sim ilar; you est ablish a service- level agreem ent wit h t he dat a

144

Oracle Distributed Systems recipient s in which you provide m et rics about t he dat a and arrange for aut om at ic or m anual not ificat ion of t he int erest ed part ies if t hese m et rics cannot be m et . The service- level agreem ent s t hat result from t his process are not t he only valuable out com e. By com ing t o consensus, you will also verify who t he organizat ion's dat a caret akers are. These are t he people responsible for: • • •

Defining and enforcing t he business rules for t he dat a Defining adm inist rat ive procedures and adm inist rat ive support Defining and im plem ent ing securit y requirem ent s

Depending on t he size and com plexit y of t he organizat ion, t hese people m ay all be in t he sam e depart m ent or m ay be in offices in several geographic locat ions.

5 .4 .6 Pr opose a n d Va lida t e D a t a Loca t ion s At t his point , you havesufficient inform at ion t o m ake an educat ed recom m endat ion of how dat a should be dist ribut ed. This inform at ion includes: • • • • •

Dat abase usage m at rix I nfrast ruct ure sum m ary Dat a cat alog Process- t o- dat a m apping Service level agreem ent s

Clearly, you are in a m uch bet t er posit ion t o " put dat a where it is used m ost " t han you were before going t hrough t hese exercises. Nevert heless, it is desirable t o put t he dat a where it is used m ost . Dat a used in act ive t ransact ion processing st ands t o benefit t he m ost from proper placem ent and t o suffer t he m ost from poor placem ent . Reference dat a ( i.e., lookup t ables) also needs t o be deployed wit h care. Therefore, begin by focusing on processes wit h t he m ost int ensive act ivit y ( from t he dat abase usage m at rix) and on t he exist ing infrast ruct ure t o select pot ent ial dat a locat ions. I f som e of t he dat abases already exist , confirm t hat t hey are deployed on hardware com m ensurat e wit h t heir t hroughput requirem ent s. I dent ify all viable sit es, regardless of t heir current use. You also should give considerat ion t o which dat a dist ribut ion t echniques suit your applicat ion. The opt ions include: Real- t im e access t o rem ot e dat a ( i.e., over a dat abase link) This m odel is appropriat e when t he applicat ion m ust see t he current version of t he prim ary dat a source, wit h no lat ency what soever. For exam ple, an order fulfillm ent applicat ion m ust have a real- t im e view of t he organizat ion's invent ory. Locally st ored, read- only replica ( i.e., a sim ple snapshot )

145

Oracle Distributed Systems Read- only snapshot s are appropriat e when a cert ain am ount of lat ency is accept able, and, of course, when t here is no requirem ent t o insert or updat e dat a. For exam ple, an order ent ry applicat ion can use a snapshot of t he com pany's product s t hat is updat ed every m orning. Locally st ored, updat eable replica ( i.e., an updat eable snapshot ) Updat eable snapshot s are an effect ive way t o part it ion dat a horizont ally. For exam ple, t he headquart ers sit e m ay capt ure all sales dat a from all sales sit es. All sales sit es have a replica of t he SALES t able int o which t hey insert records, but t hey neit her keep nor need t he sales t ransact ions from ot her sales sit es. Asynchronous m ult i- m ast er replicat ion Asynchronous m ult i- m ast er replicat ion is appropriat e when a t able m ust be shared am ong m ult iple sit es, each requiring access t o all records in t he t able, wit h t he abilit y t o m anipulat e records. For exam ple, an ORDERS t able m ust be accessible from t he order ent ry sit e ( which ent ers records) , t he shipping sit e ( which fulfills t he orders) , and t he billing sit e ( which t urns t he orders int o invoices) . Generally, a cert ain am ount of lat ency am ong peer sit es is accept able. And if it is not accept able, m any RDBMS vendors, including Oracle, support synchronous m ult i- m ast er replicat ion. Synchronous m ult i- m ast er replicat ion Synchronous replicat ion ensures t hat t ransact ions are com m it t ed sim ult aneously at all part icipat ing sit es. This archit ect ure can be used t o provide a hot failover sit e. Since synchronous replicat ion depends on t he availabilit y of all sit es, it is not an advisable solut ion unless t he part icipat ing host s have very sim ple net work connect ions—t hat is, on t he sam e subnet wit h no dependency on rout ers. I deally, t he m achines are direct ly connect ed. Once you have det erm ined placem ent s and dist ribut ion m et hods for t he applicat ion's dat a, you perform a " sanit y check" on t he em erging t opology. You can est im at e your net work requirem ent s by m easuring t he dat a flows generat ed by t ransact ion processing and dat a flows generat ed by replicat ion act ivit y. Transact ional dat a flow can be approxim at ed as: ( byt es/ t rnsact ion) × ( peak t ransact ion count / second) The bandwidt h required for replicat ion act ivit y is a funct ion of t he replicat ion m et hod, but you can m ake a rough est im at e of t he change rat e for t he replicat ed dat a. Finally, it never hurt s t o m ult iply your est im at es by a fudge fact or of 2 or t hree; operat ional behavior and load charact erist ics will inevit ably change when t he new syst em becom es available. At t he end of t his exercise, you will be able t o sket ch all sit es in t he dist ribut ed environm ent and t he dat a flow required am ong t hem . You are now in a posit ion t o validat e t he proposed archit ect ure against your infrast ruct ure's capacit y as well as against ot her const raint s such as your securit y requirem ent s, service- level agreem ent s, and availabilit y requirem ent s. Specific it em s t o confirm include:

146

Oracle Distributed Systems •

• •

• • •

Sufficient hardware resources for ant icipat ed user volum e and t ransact ion rat e. Sufficient net work bandwidt h. Support for t wo- phase com m it prot ocol where required. ( This is an issue prim arily in het erogeneous dist ribut ed RDBMS environm ent s.) Sufficient funct ionalit y and capacit y of dat a replicat ion t echnology. Adherence t o service- level agreem ent s reached earlier. Adherence t o t he ident ified securit y requirem ent s.

Of course, you m ay need t o m ake som e adj ust m ent s t o t he proposed locat ion schem e, but equipped wit h t he inform at ion gat hered during t his process, you will know t he consequences. I n addit ion, t he docum ent at ion t his process creat es is valuable not only for posit ioning your dat a but also for underst anding t he applicat ion as a whole.

5 .5 Applica t ion Pa r t it ion in g St r a t e gie s Applicat ion part it ioning refers t o deploying different com ponent s of an applicat ion at various locat ions. For exam ple, an order ent ry applicat ion m ay consist of: • • • •

Dat a ent ry screens on order ent ry clerks' PCs Bar code scanners collect ing shipping inform at ion at t he fulfillm ent cent er A web server host ing m anagem ent report ing Business rule enforcem ent via st ored procedures in t he dat abase

The order ent ry applicat ion is t he sum of all of t hese part s. The com ponent s of a part it ioned, or t iered, applicat ion always fall int o one of t hree broad cat egories: user int erface, business logic, or dat a access logic. As you design a dist ribut ed dat abase, you m ust m ake decisions about where t o locat e different t ypes of processing. Som e of t he choices are obvious: bar code dat a collect ion has t o occur where t he bar codes are. But in ot her cases, t he decision is not so obvious. Where should we enforce t he requirem ent t hat cust om ers cannot place new orders if t heir account s are m ore t han 90 days in arrears? What fact ors should you consider when you m ake t hese choices? Act ually, applicat ion part it ioning ent ails bot h a hardware level and a soft ware ( or logical) level. At t he hardware level, we decide what equipm ent is best suit ed for various port ions of t he applicat ion. And at t he logical level, we decide where business rules will be enforced, how t he user int erface will work, and what dat a access m et hods we will provide. The logical applicat ion part it ioning always precedes t he hardware part it ioning. Table 5.6 present s t hese t wo levels in t he cont ext of t he order ent ry applicat ion described before.

Table 5.6. Hardware and Logical Application Partitioning Considerations Hardware Partitioning Choices PC client s will host soft ware for dat a ent ry.

Logical Partitioning Choices The applicat ion's present at ion layer will be writ t en wit h Oracle's Developer 2000 t ool set , and all t ext ual dat a will be convert ed t o uppercase before sending it

147

Oracle Distributed Systems

t o t he dat abase. All business rules will be enforced in t he dat abase wit h t riggers and st ored procedures. Scanners from I nt erm ec and All shipping t ransact ions will be t racked wit h bar code Sym bol will be used for bar scanners at t he fulfillm ent cent er. code dat a collect ion. The web server for m anagem ent report ing will run on a Sun Ult ra2.

Managem ent report ing will be provided over t he int ranet using a Net scape web server and CGI script s.

The dat abase at t he order ent ry sit e will run on a Sun Ent erprise 6000.

All order ent ry t ransact ions will be perform ed in a dat abase at t he order ent ry sit e.

The dat abase at t he fulfillm ent sit e will run on a Sun Ent erprise 3000.

All shipping t ransact ions will be perform ed in a dat abase at t he fulfillm ent cent er.

Business rule enforcem ent is a pivot al issue in every applicat ion part it ioning schem e. You can do it wit hin t he dat abase, in t he client port ion of t he applicat ion or in som e int erm ediat e t ier. What are t he pros and cons of t hese approaches?

5 .5 .1 En for cin g Bu sin e ss Ru le s in t h e D a t a ba se Tie r One could m ake t he argum ent t hat t he dat abase is t he only sensible place t o enforce business rules. By placing t hese requirem ent s in t he dat abase, we can be cert ain t hat any applicat ion, current or planned, will always obey t he rules t hat we have defined, because t here is no fooling t he dat abase. For exam ple, suppose we have a requirem ent t hat we m anufact ure 1000 m ore racing bicycles when t he invent ory falls below 50. We could enforce t his rule by placing a t rigger on t he I NVENTORY t able which creat es a record in t he MANUFACTURE_QUEUE t able when we hit t he reorder point . I f we codify t his rule in t he dat abase, we can be sure t hat every applicat ion will respect it , even if t he developers are unaware of t he rule. We can also be sure t hat t he rule will be enforced in exact ly t he sam e way by every applicat ion; t here is no room for int erpret at ion or m isint erpret at ion. And applicat ion code is subst ant ially sim plified. One could even m ake t he case t hat perform ance is bet t er because we do not need t o ship t he t ransact ions relat ed t o t he rule enforcem ent over t he net work. These are t he com pelling reasons t hat lead m ost RDBMS vendors t o int roduce t riggers and st ored procedures. Wit h such a convincing case for business rule enforcem ent in t he dat abase, why would one ever decide t o do ot herwise? The problem is t hat som e applicat ions sim ply are not suit ed t o t his archit ect ure. Those t hat rely on m essage passing bet ween applicat ion t iers or asynchronous processing cannot readily benefit from dat abase business rule enforcem ent . Moreover, t he fact t hat all rules are absolut e m ay not be appropriat e for all applicat ions.

148

Oracle Distributed Systems

5 .5 .2 En for cin g Bu sin e ss Ru le s in t h e Pr e se n t a t ion Tie r The dawning ofpowerful client developm ent t ools, coupled wit h t he advent of powerful deskt op hardware, brought about t he t rend t o perform as m uch work as possible on t he client . When business rules as well as a present at ion layer are deployed on t he client , we have a fat client . Originally, t he appeal of t he fat client was t hat it could relieve t he server of som e of it s dut ies, t hereby im proving overall perform ance. Alt hough t his load balancing m ay st ill be a case for t he fat client , t hat doesn't m ean we should rely on deskt op m achines t o t ake up t he slack for an inadequat e server. But t here are sit uat ions in which server- based business rule enforcem ent sim ply cannot out perform client based logic. We have found, for exam ple, t hat int ensive t ransact ion processing ( i.e., hundreds of t ransact ions per second) does bet t er when t he SQL st at em ent s com e from t he client as opposed t o st ored procedures. The obvious disadvant age of client - based business rule enforcem ent is t hat t he sam e logic m ust be coded in every int erface. I f you allow dat a ent ry via applicat ions writ t en in HTML, Power Builder, and Developer 2000, you will have t o writ e and m aint ain t he logic in t hree places. You will also have t o ensure t hat t he logic is consist ent and t hat t here is no ot her access pat h t o t he dat abase t hat would allow t he logic t o be inadvert ent ly bypassed.

5 .5 .3 Cr e a t in g a Th ir d Tie r The em erging t rend is t o place a m iddle t ier—called t he applicat ion layer —bet ween t he client and t he server. This layer m ay be im plem ent ed wit h a CORBA, DCOM, or sim ilar obj ect - based archit ect ure. The advent of t he Web has been a driving force behind t he t hree- t ier archit ect ure because organizat ions find t hat t hey can inexpensively deploy applicat ions t hat are accessible from any client t hat can run a browser. The client is responsible only for m essaging t he applicat ion t ier.

Alt hough t he applicat ion layer can include logic t o enforce business rules, it is not a requirem ent of t he t hree- t ier approach; Oracle's Net work Com put ing Archit ect ure ( NCA) advocat es t he dat abase t ier as t he hom e for business rule logic.

Regardless of where t he business rules are enforced, t here are several advant ages t o m oving applicat ion logic off bot h t he client and t he dat abase server: Use of " t hin" client s

149

Oracle Distributed Systems As we have already st at ed, any m achine t hat can run a browser can use a t hree- t ier applicat ion. Thus, t he cost of put t ing t he applicat ion in t he user's hands can be as low as t he cost of a set - t op box or ot her inexpensive device. I m plem ent at ion in a het erogeneous environm ent By st oring dat abase API s in t he applicat ion t ier, client s and applicat ion m odules access all dat abases using a single set of API calls. The dat abase int erface is t he sam e regardless of t he RDBMS. Of course, t his t ransparency assum es t hat developers have designed and coded t he API calls. Scalabilit y and load balancing The t hree- t ier archit ect ure lends it self t o scalabilit y because applicat ion com ponent s are easy t o isolat e and can run on equipm ent t hat is specifically sized and t uned t o suit t he applicat ion. Load balancing can oft en be realized by deploying TP m onit ors. Code reuse Once a library of dat abase API s is developed, it can be used for fut ure applicat ions. I f API s are well docum ent ed, fut ure developm ent effort s should be able t o pick and choose com ponent s t hey need and writ e only t hose pieces t hat are specific t o t he new applicat ion. Flexibilit y I f applicat ion- layer API s are designed properly, t hey m ask t he specifics of t he dat abase int erface from bot h t he client s and ot her com ponent s. This t ransparency sim plifies endeavors such as RDBMS soft ware upgrades or even a m igrat ion t o a new RDBMS engine. St andards- based API s The applicat ion- t ier com ponent s should be built wit h languages and t ools t hat are not specific t o any part icular RDBMS vendor. Most not ably, using C, C+ + , Java, and HTML ensures t hat no dependencies on a propriet ary language or int erface sneak int o t he code. Of course, t here is a price exact ed for all of t hese benefit s. The principal drawback is t hat a m ult it iered environm ent is m ore com plex t o m anage in bot h t he developm ent and product ion environm ent s. I n order t o realize code reuse, for exam ple all API s m ust be t horoughly docum ent ed and m ust work exact ly as advert ised. Ot herwise, duplicat e funct ionalit y will creep int o t he API library, leading t o confusion about how t he API s should be used. Version- cont rol logist ics also becom e m ore com plex. New API versions m ust be t est ed and cert ified as being com pat ible wit h ot her library com ponent s. Finally, t he addit ional t ier m eans addit ional decisions about how t he applicat ion can and should be part it ioned. I n short , t he t hree- t ier approach offers fant ast ic flexibilit y, but t he addit ional com plexit y m ay out weigh t he benefit s for all but t he largest syst em s.

150

Oracle Distributed Systems

5 .5 .4 H ow M a n y Tie r s Ar e Righ t for You ? Now t hat I 've explained t he fundam ent al differences bet ween t wo- t ier ( client / server) and t hree- t ier archit ect ures, how can you one decide which approach is appropriat e for t he applicat ion at hand? Obviously, t here are no hard and fast rules, but Table 5.7 offers som e guidelines.

Table 5.7. Guidelines for an Application Architecture Situations Calling for a Two-Tier Architecture

Situations Calling for a Three-Tier Architecture

The applicat ion consist s of fewer t han 50 logical com ponent s. ( I n a t ypical client / server applicat ion, a logical com ponent roughly equat es t o a dat a ent ry form .)

The applicat ion consist s of 50 or m ore logical com ponent s.

The dat abase t iers use t he sam e RDBMS.

There is a het erogeneous dat abase t ier.

The applicat ion perform s fewer t han 10 t ransact ions per second.

The applicat ion has a sust ained t ransact ion rat e in excess of 10 t ransact ions per second.

The applicat ion support s 500 or fewer concurrent users.

The applicat ion support s m ore t han 500 concurrent users.

The applicat ion is likely t o be replaced or rewrit t en The applicat ion's life expect ancy wit hin five years. is m ore t han five years. Regardless of how m any t iers will house t he applicat ion, you will have t o perform som e part it ioning. I n Dat a Replicat ion, Marie Buret t a proposes a st ep- by- st ep approach t o decom posing an applicat ion for part it ioning, sum m arized here: 1. Dist inguish user int erface com ponent s from " t he rest ." User int erface com ponent s generally consist of dat a ent ry screens, predefined report s, and dat a collect ion equipm ent such as bar code scanners and cash regist ers. 2. That which is not a user int erface com ponent is eit her business logic or dat a access logic. I dent ify and separat e t he t wo. 3. Associat e t he business logic from St ep 2 wit h specific business t ransact ions, such as order ent ry, cust om er account creat ion, and so on. 4. Map t he business t ransact ions from St ep 3 wit h specific dat abase t ransact ions. For exam ple, t aking a new order for a product would equat e t o som et hing like t his: 5. INSERT INTO ORDERS (order_id, customer_id, order_date) 6. ... 7. 8. INSERT INTO ORDER_ITEMS( order_id, product_id, units, uom, unit_cost ) ... Not e t hat t he preceding exam ple includes t wo t ransact ions t hat m ust be com plet ed as a unit t o creat e an order. The m apping of business t ransact ions t o dat abase t ransact ions m ust include an account of such int erdependencies.

151

Oracle Distributed Systems 9. I dent ify decision point s and const raint s t hat occur in t he business t ransact ions. An exam ple of a decision point is t he requirem ent t o replenish st ock of an it em when t he reorder point is reached. An exam ple of a const raint is t he refusal t o accept orders from cust om ers whose account s are m ore t han 90 days in arrears. 10. I dent ify dependencies am ong business t ransact ions. For exam ple, an order m ust be shipped before it can be billed. I n a com plex applicat ion, it m ay be desirable t o perform operat ions in parallel. By ident ifying t ransact ional dependencies, you will know which t ransact ions can and cannot occur sim ult aneously and which t ransact ions can be deferred. Having det erm ined t hese det ails about t he applicat ion's t ransact ions, you can m ake inform ed decisions about where t o place it s com ponent s. I f you are using a client / server m odel, t he client should host not hing m ore t han t he user int erface logic; business logic belongs in t he dat abase. I n t he case of a t hree- t ier archit ect ure, business logic m ay be deployed in t he applicat ion t ier. I f so, it is im port ant t hat t he m achines t hat host t his business logic or require a high volum e of dat a access reside in close proxim it y t o t he RDBMS servers. I n part icular, t hese m achines should not m ake a WAN connect ion t o t he dat abase if it can be avoided.

5 .6 Pr oce du r a l Re plica t ion Procedural replicat ion refers t o m anipulat ing rem ot e dat a indirect ly by m aking procedure calls. For exam ple, if you want t o m ake a 5% price hike for all product s in t he rem ot e PRODUCT_PRI CES t able, you m ight m ake a call like t his: BEGIN PriceMaint.PercentageIncrease( pct_in => 5); END; This procedure goes t o t he rem ot e dat abase and execut es t he st at em ent : UPDATE PRODUCT_PRICES SET price = price * 1.05; Since t he st ored procedure it self resides in t he t arget dat abase( s) , no dat a t ravels over t he net work, j ust t he nam e of t he st ored procedure and t he passed param et ers. Nor does t he calling dat abase need t o m aint ain a connect ion t o t he rem ot e dat abase while t he procedure is execut ed. Once t he calling dat abase delivers t he call t o t he t arget locat ions, it s work is finished. Procedural replicat ion is appropriat e for operat ions t hat m anipulat e a significant am ount of dat a on a replicat ed t able. For exam ple, t he price increase j ust described changes every row in t he PRODUCT_PRI CES t able. I f you were t o perform t he updat e locally and let t he row- level replicat ion m echanism propagat e all of t he updat ed rows, t he net work t raffic could be crippling. I n general, you should not at t em pt t o use rowlevel replicat ion for any t ransact ion t hat affect s m ore t han 20% of a t able's records. When using procedural replicat ion, you m ust t ake care t hat procedure calls t hat have t ransact ional dependencies are m ade in t he correct order at t he rem ot e sit es. For exam ple, a call t o HR_APP.HireEm ployee would have t o precede a call t o

152

Oracle Distributed Systems HR_APP.PayEm ployee. The replicat ion t echnology t hat you use should ensure t hat t he order of procedure calls is preserved. Procedural replicat ion is described in great er det ail in Chapt er 14.

153

Oracle Distributed Systems

Ch a pt e r 6 . Or a cle 's D ist r ibu t e d Syst e m I m ple m e n t a t ion Oracle has gone t o som e lengt hs t o ensure t hat t heir RDBMS product m eet s Chris Dat e's obj ect ives for a dist ribut ed dat abase syst em , which we described in Chapt er 5. This chapt er exam ines how Oracle net working and RDBMS product s have addressed each of t hese obj ect ives and discusses t echniques you can ut ilize t o achieve t hese goals in your own environm ent . I 'll also look at t he inherent lim it at ions and even cont radict ions in realizing t hese goals.

6 .1 M e e t ing t he 1 2 Obj e ct ive s w it h Or a cle To review, t he 12 obj ect ives for a successful dist ribut ed dat abase syst em , which we discussed in Chapt er 5, are: 1. Local aut onom y 2. No reliance on a single sit e 3. Cont inuous operat ion 4. Locat ion t ransparency 5. Fragm ent at ion independence 6. Replicat ion independence 7. Dist ribut ed query processing 8. Dist ribut ed t ransact ion m anagem ent 9. Hardware independence 10. Operat ing syst em independence 11. Net work independence 12. RDBMS independence As I said in Chapt er 5, t hese are goals, not requirem ent s. We cannot , for exam ple, reasonably expect a dist ribut ed dat abase syst em t o provide cont inuous operat ion in perpet uit y. Nevert heless, t he archit ect s of t he Oracle RDBMS have answered each of t hese goals, as described in t he following sect ions.

6 .1 .1 Loca l Au t on om y Local aut onom y requires t hat an individual dat abase be fully funct ional even if it cannot cont act ot her syst em s in t he dist ribut ed environm ent and t hat each sit e be responsible for it s own dat a int egrit y, securit y, and m anagem ent . Unfort unat ely, it is not possible t o at t ain bot h local aut onom y and locat ion t ransparency, because t he lat t er goal requires 100% availabilit y of dat a at a rem ot e locat ion. Locat ion t ransparency im plies reliance on a net work connect ion and t he availabilit y of a rem ot e dat abase. Oracle int roduced snapshot s in Oracle7 as a way t o m ake rem ot e dat a accessible in t he local dat abase. A snapshot is essent ially a local copy of a rem ot e t able, which ( in t heory) can be refreshed as oft en as once per second. ( This frequency is only in t heory because, for one t hing, it m ay t ake m ore t han one second t o refresh t he snapshot .) As an exam ple, t he dat abase adm inist rat or at t he sales sit e of t he

154

Oracle Distributed Systems fict it ious Bigwheel Bicycle com pany could m ake a snapshot of t he PRODUCTS t able from t he headquart ers sit e as follows: CREATE SNAPSHOT products REFRESH FAST START WITH SYSDATE NEXT TRUNC(sysdate+1) AS SELECT product_id, product_name FROM [email protected]; This snapshot st ores t he cont ent s of t he headquart ers PRODUCTS t able in t he local sales dat abase and refreshes t he cont ent s of t he t able every day at m idnight . The det ails of snapshot creat ion and m anagem ent are described in Chapt er 11. Snapshot s are a way t o view ( and updat e wit h som e rest rict ions) rem ot e dat a wit hout act ually connect ing t o t he rem ot e sit e. The obvious advant age of t his t echnique is t hat dat a is always accessible t o t he local sit e—hence local aut onom y. The price for t his convenience is dat a lat ency, because t he dat a in a snapshot is only as current as t he last refresh. The second aspect of local aut onom y is m anagem ent independence. Oracle achieves t his independence in a variet y of ways. First , t here is no such t hing as a " child" dat abase. Every Oracle dat abase has it s own dat a dict ionary, it s own user account s, and it s own cont rol processes. Alt hough a dat abase m ay be logically subservient t o anot her, Oracle does not require or include any funct ional dependencies. Second, Oracle guarant ees int eroperabilit y am ong all of it s support ed versions on all plat form s. Thus, any sit e in a dist ribut ed syst em should be able t o follow it s own upgrade pat h. Of course t here are som e lim it at ions t o t his int eroperabilit y. I n part icular, if you are using t he advanced replicat ion facilit ies, Oracle generally recom m ends t hat all part icipat ing dat abases be on t he sam e version of t he RDBMS.

6 .1 .2 N o Re lia n ce on a Sin gle Sit e The funct ionalit y and perform ance of a dist ribut ed syst em should not depend on any single sit e. This is cert ainly a noble am bit ion, but t here is not hing wit hin t he Oracle RDBMS t hat guarant ees it s realizat ion. However, Oracle does provide t he funct ionalit y required t o design a syst em t hat m eet s, or nearly m eet s, t his requirem ent . The t wo predom inant st rat egies for ensuring high availabilit y are advanced replicat ion and Oracle parallel server. These are t wo very different approaches, each wit h it s inherent advant ages and disadvant ages. The advanced replicat ion approach ent ails creat ing t wo or m ore separat e dat abases t hat m irror specified dat a, as shown in Figure 6.1.

Figu r e 6 .1 . Or a cle pa r a lle l se r ve r ve r su s a dva n ce d r e plica t ion

155

Oracle Distributed Systems

The replicat ion can t ake place synchronously or asynchronously, and t here is no hard lim it on t he num ber of sit es t hat can part icipat e. I f any part icular dat abase fails or becom es unavailable, processing can be direct ed t o a different one. Oracle parallel server is a high- availabilit y m odel in which t wo or m ore com put ers run Oracle inst ances t hat access t he sam e physical dat abase. This m odel prot ect s against t he loss of a com put er, but t he physical st orage is st ill a single point of failure. Oracle parallel server generally requires clust ering soft ware from t he operat ing syst em vendor. To ensure t hat a dist ribut ed syst em 's perform ance is not dict at ed by any single sit e, developers and dat abase adm inist rat ors have t o exam ine carefully t he applicat ion's dist ribut ed queries and t ransact ions. Alt hough Oracle can execut e dist ribut ed operat ions wit hout any special coding, it is oft en well wort h t he effort t o t une SQL st at em ent s. I n addit ion, t he DBA should t ake care t o configure t he I NI T.ORA param et ers relevant t o dist ribut ed t ransact ions, such as COMMI T_POI NT_STRENGTH. I n short , Oracle provides t he t ools t o design a dist ribut ed syst em t hat is free from reliance on a single sit e, but it is your responsibilit y t o design it .

6 .1 .3 Con t in u ou s Ope r a t ion Cont inuous operat ion of a dist ribut ed syst em m eans t hat no m aint enance t asks should require an out age of t he ent ire syst em . Maint enance t asks m ay include upgrades t o t he operat ing syst em or RDBMS or t he addit ion and delet ion of part icipat ing sit es.

156

Oracle Distributed Systems I f t he Oracle dist ribut ed syst em is built on dat abase links and sim ple replicat ion ( i.e., read- only snapshot s) , t hen t here are no m aint enance act ivit ies t hat would require an out age of t he ent ire dist ribut ed environm ent . Sit es can be added or rem oved at any t im e, and upgrades can be execut ed wit hout im pact ing part icipat ing sit es. However, if you are using t he advanced replicat ion facilit ies, Oracle im poses cert ain lim it at ions. Most significant ly, if you wish t o add a new m ast er or snapshot sit e t o a replicat ed environm ent , you m ust coordinat e t he addit ion so t hat t he dat a at t he new sit e includes dat a changes t hat m ay have occurred while t he new sit e is being inst ant iat ed. Refer t o t he descript ions of t he built - in packages DBMS_OFFLI NE_SNAPSHOT and DBMS_OFFLI NE_OG in Appendix A.

6 .1 .4 Loca t ion Tr a n spa r e n cy Locat ion t ransparency, or locat ion independence, m eans t hat neit her applicat ions nor users need t o know t he act ual locat ion of t he t ables, views, or st ored procedures t hey are accessing. Oracle provides support for locat ion t ransparency via dat abase links and synonym s. Suppose t hat t he fict it ious Bigwheel Bicycle com pany want s t o m ake it s PRODUCTS t able visible t o it s sales sit e, while t he act ual t able resides at t he headquart ers sit e. We can configure t he sales sit es so t hat a reference t o PRODUCTS m aps t o t he t able in t he headquart ers sit e by creat ing a dat abase link from PSLS.BI GWHEEL.COM t o PHQS.BI GWHEEL.COM and creat ing a synonym for t he rem ot e obj ect : CREATE DATABASE LINK PHQS.BIGWHEEL.COM USING 'prodhq'; CREATE SYNONYM products FOR [email protected];

The public dat abase link in t he previous exam ple is a privat e link, which m eans t hat t he Oracle account t hat creat ed t he link is t he only account t hat can ut ilize it . See Chapt er 4, for det ails about different st rat egies for accessing rem ot e obj ect s and m anaging privileges on rem ot e obj ect s specifically.

Of course, t his solut ion is not wit hout it s lim it at ions. For exam ple, if t he net work connect ion bet ween PSLS.BI GWHEEL.COM and PHQS.BI GWHEEL.COM fails, users at t he sales sit e will becom e painfully aware of t he fact t hat t he PRODUCTS t able resides in a rem ot e dat abase: SQL> SELECT product_id, product_name 2 FROM products; ERROR at line 2: ORA-12203: TNS:unable to connect to destination

157

Oracle Distributed Systems Dependency on a net work connect ion, as well as t he availabilit y of t he rem ot e dat abase, are unavoidable side effect s of providing locat ion t ransparency.

6 .1 .5 Fr a gm e n t a t ion I n de pe n de n ce Fragm ent at ion refers t o t he part it ioning of dat a across m ult iple sit es. The dat a m ay be part it ioned horizont ally ( i.e., by record) or vert ically ( i.e., by field) . Oracle uses snapshot s and/ or views t o support bot h part it ioning m et hods. You m ight want t o perform horizont al part it ioning if your dat a has a regional com ponent . For exam ple, if your com pany's sales force accesses t he CUSTOMERS t able, it m ight m ake sense t o st ore only dat a associat ed wit h a part icular region in t he corresponding dat abase. You could im plem ent t his part it ioning schem e in at least t hree different ways: • • • • • • • • •

• • • • • • • •

Creat e a read- only snapshot of t he headquart ers- sit e CUSTOMERS t able in each regional dat abase. For exam ple, in California's sales dat abase we would creat e t he following snapshot : CREATE SNAPSHOT customers REFRESH FAST START WITH SYSDATE NEXT TRUNC(sysdate+1) AS SELECT customer_id, address, state, telephone, sales_rep_id FROM [email protected] WHERE state = 'CA'; I f t he California sit e requires UPDATE and I NSERT privileges on t he CUSTOMERS t able, we could creat e an updat eable snapshot : CREATE SNAPSHOT customers REFRESH FAST START WITH SYSDATE NEXT TRUNC(sysdate+1) FOR UPDATE AS SELECT customer_id, address, state, telephone, sales_rep_id FROM [email protected] WHERE state = 'CA'; The creat ion of t he updat eable snapshot assum es t hat t he appropriat e replicat ion configurat ion st eps have been com plet ed. Refer t o Chapt er 11 for det ails on how t o creat e updat eable snapshot s.

•

• •

We could sim ply creat e a view at t he California sit e t hat references t he appropriat e cust om ers in t he headquart ers dat abase: CREATE VIEW customers AS SELECT customer_id, address, state, telephone, sales_rep_id FROM [email protected];

158

Oracle Distributed Systems Of course, t his view depends on t he headquart ers sit e's availabilit y. Vert ical part it ioning m akes sense when you want t o view dat a from t wo or m ore t ables at t wo or m ore sit es as a single relat ionship or when you want t o exclude colum ns in a t able from a part icular sit e or group of users. For exam ple, you m ight want t o j oin t he CUSTOMERS t able from t he headquart ers sit e ( where all cust om er records are st ored) wit h t he ORDERS t able at t he cat alog order sit e t o link sales volum e wit h regions. We can use a view t o creat e t his relat ionship: CREATE VIEW regional_sales_volume AS SELECT c.customer_id, c.address, c.state, c.telephone, c.sales_rep_id, o.total_amount FROM [email protected] c, [email protected] o WHERE c.customer_id = o.customer_id; Not e t hat t his relat ionship requires t he availabilit y of t he headquart ers sit e ( PHQS.BI GWHEEL.COM) and t he cat alog order ent ry sit e ( PCOE.BI GWHEEL.COM) .

6 .1 .6 Re plica t ion I n de pe n de n ce Oracle int roduced t he sym m et ric replicat ion feat ure in Version 7.1. Subsequent releases up t o and including Version 8.1 have included subst ant ial im provem ent s t o it s funct ionalit y and perform ance. Oracle has also changed it s nam e t o t he less pict uresque advanced replicat ion facilit ies. But by any nam e, Oraclereplicat ion offers a diverse and robust product set , including: • • • • •

Read- only and updat eable snapshot s Mult i- m ast er replicat ion Built - in conflict resolut ion m et hods Support for BLOB and CLOB dat at ypes Synchronous or asynchronous propagat ion

Part I I of t his book is devot ed t o Oracle's replicat ion product s; refer t o t he chapt ers in t hat part for det ails.

6 .1 .7 D ist r ibu t e d Qu e r y Pr oce ssin g Support for dist ribut ed query processing is a corollary of locat ion t ransparency. And Oracle does allow you t o issue queries against rem ot e dat a, even queries t hat j oin dat a in m ult iple dat abases. Users and applicat ion developers need not include any special com m ands or incant at ions j ust because t he t ables being queried are in diverse locat ions.

159

Oracle Distributed Systems However, it is wort h point ing out t hat t he opt im izat ion of t hese queries is som et hing of a concern, at least for applicat ion developers and dat abase adm inist rat ors. The perform ance of a query against t he sam e t ables can vary wildly, depending on where t he t ables are locat ed. Judicious use of t he EXPLAI N PLAN ut ilit y and/ or AUTOTRACE will help t o det erm ine whet her a query is suffering because of it s dist ribut ed nat ure. I n part icular, queries t hat j oin wit h all records in a rem ot e t able t end t o perform poorly.

6 .1 .8 D ist r ibu t e d Tr a n sa ct ion M a n a ge m e n t Just as locat ion t ransparency im plies support for dist ribut ed query processing, it also im plies support for dist ribut ed t ransact ions. A dist ribut ed t ransact ion is one t hat applies DML at m ult iple locat ions. The classic exam ple is t he credit / debit t ransact ion: when a bank wires funds from one branch t o anot her, it m ust guarant ee t hat t he account receiving t he funds is credit ed if and only if t he account sending t he funds is debit ed. The m echanism t hat guarant ees t his int egrit y is t he t wo- phase com m it prot ocol. Oracle int roduced support of t he t wo- phase com m it wit h Version 7.0. As wit h dist ribut ed query processing, dist ribut ed t ransact ions will work wit hout requiring any special coding or com m ands, but applicat ion developers and dat abase adm inist rat ors are well advised t o m ake accom m odat ions for t he dist ribut ed work. Specifically, t he applicat ion should include logic t o t rap errors relat ing t o dist ribut ed t ransact ions; t hese are errors in t he range ORA- 02040 t o ORA- 02099. Sim ilarly, dat abase adm inist rat ors should ensure t hat t he I NI T.ORA configurat ion param et ers are set appropriat ely for all part icipat ing dat abases. These param et ers include: COMMI T_POI NT_STRENGTH COMPATI BI LI TY DI STRI BUTED_LOCK_TI MEOUT DI STRI BUTED_TRANSACTI ONS GLOBAL_NAMES OPEN_LI NKS The DBA should also be prepared t o m onit or t he dat a dict ionary views DBA_2PC_NEI GHBORS and DBA_2PC_PENDI NG.

6 .1 .9 H a r dw a r e I n de pe n de n ce A dist ribut ed syst em should be able t o run on any hardware plat form . Since it s earliest days, Oracle has prided it self as being t he only dat abase t hat runs on anyt hing, even your palm t op. Alt hough you cannot current ly run an Oracle dat abase on your pager or cell phone, it is shipping on dozens of plat form s.

6 .1 .1 0 Ope r a t in g Syst e m I n de pe n de n ce Oracle is cert ified on at least as m any operat ing syst em s as hardware plat form s. However, be warned t hat t he m ore popular operat ing syst em s m onopolize t he at t ent ion of m ost of Oracle's developm ent and support st aff. So, if you are running on HP- UX, Sun Solaris, or Windows NT, you will not have any problem s acquiring t he

160

Oracle Distributed Systems lat est versions of Oracle's RDBMS. However, t hose of you on operat ing syst em s t hat are less popular and/ or nearing ext inct ion, such as VM or VMS, will have t o wait .

6 .1 .1 1 N e t w or k I n de pe n de n ce Oracle's SQL* Net and Net 8 product s ship wit h t he m ost popular prot ocol adapt ers. Current ly, t hese include: TCP/ I P DECnet SPX/ I PX LU6.2

6 .1 .1 2 RD BM S I n de pe n de n ce . Speaking ofRDBMS independence m ay seem ironic when describing how Oracle adheres t o C. J. Dat e's 12 requirem ent s for an ideal dist ribut ed syst em . Yet Oracle can int eract wit h ot her RDBMS vendors. Oracle's " Gat eway" product s include t he following: Transparent Gat eways Transparent Gat eways provide SQL access t o non- Oracle RDBMSs including DB2, SQL/ 400, Teradat a, Rdb, RMS, Non- St op SQL, and Bull GCOS6. These Gat eway product s t ypically run on t he m achine wit h t he non- Oracle RDBMS as opposed t o where t he Oracle dat abase server resides. Procedural Gat eway for APPC This product provides rem ot e procedure call ( RPC) support via PL/ SQL t o execut e CI CS, I MS/ TM, and I DMS/ DC t ransact ions accessing m ainfram e dat a sources such as Adabas, CA- I DMS, I MS, VSAM, DB2, and Dat acom DB. This t echnology is best for accessing dat a sources t hat support OLTP applicat ions. I t 's current ly available on t he I BM RS/ 6000 wit h port ing underway t o bot h HP- UX and Sun Solaris. Procedural Gat eway for APPC does not require any Oracle soft ware on t he m ainfram e syst em . Transparent Gat eway for DRDA Transparent Gat eway for DRDA provides SQL access t o DRDA- enabled dat abases including DB2, SQL/ DS, and SQL/ 400. This t echnology is best used by sit es ( t ypically very large I BM m ainfram e shops) requiring I BM prot ocol com pliance or for an applicat ion t hat connect s t o m ult iple DRDA- enabled dat abases. This product is current ly available on t he I BM RS/ 6000. Transparent Gat eway for DRDA does not require Oracle soft ware on t he t arget syst em . Open Gat eway Toolkit s

161

Oracle Distributed Systems Open Gat eway Toolkit s allow you t o build cust om ized gat eways t o dat a sources t hat are not support ed by t he ot her Oracle gat eway product s. For exam ple, you could use t he Transparent Gat eway Toolkit t o build SQL access t o a Sybase dat abase.

6 .1 .1 3 Con clu sion s To t he ext ent t hat Chris Dat e's 12 obj ect ives are at t ainable, Oracle has at t ained t hem . There are cert ain im plied cont radict ions, such as t he requirem ent t hat a dist ribut ed syst em supply locat ion t ransparency and be im m une from sit e out ages. But even t hese challenges can be addressed wit h such Oracle product s as t he advanced replicat ion facilit ies.

6 .2 Or a cle 's Globa l D a t a D ict ion a r y Chapt er 5 int roduced t he concept of a global dat a dict ionary, which is a reposit ory t hat uniquely ident ifies all obj ect s in a dist ribut ed dat abase syst em . The challenge is t o im plem ent a global dat a dict ionary wit hout creat ing a single m ast er sit e in t he process and wit hout sacrificing t he not ion of locat ion t ransparency.

6 .2 .1 Globa l N a m in g Oracle's solut ion t o t his challenge hinges on t he concept of global nam ing. I n Oracle7, Oracle int roduced an I NI T.ORA param et er GLOBAL_NAMES, which, when set t o TRUE, ensures t hat every dat abase part icipat ing in a dist ribut ed environm ent has a unique nam e.

You should m ake a habit of set t ing t he GLOBAL_NAMES param et er t o TRUE even if you are not in a dist ribut ed environm ent . I f you ever have t o swit ch t he param et er t o TRUE aft er it has been FALSE, you m ay encount er conflict s wit h ot her dat abase nam es in your environm ent . I n addit ion, Oracle has st at ed t hat t hey m ay require t he GLOBAL_NAMES param et er t o be TRUE in fut ure versions.

You can det erm ine t he nam e of any given dat abase by querying t he GLOBAL_NAME dat a dict ionary view: SQL> SELECT global_name FROM global_name; GLOBAL_NAME -------------------------------------------------PHQS.BIGWHEEL.COM

162

Oracle Distributed Systems The dat abase's global nam e default s t o t he concat enat ion of t he I NI T.ORA param et ers DB_NAME and DB_DOMAI N. However, you can also change t he global nam e t o any value wit h an ALTER DATABASE st at em ent : ALTER DATABASE RENAME GLOBAL_NAME TO NEWNAME.BIGWHEEL.COM; Why do you care about a dat abase's global nam e? Because if t he GLOBAL_NAMES param et er is set t o TRUE, t hen any dat abase link creat ed in t his dat abase m ust have t he sam e nam e as t he global nam e of t he dat abase t o which it connect s: The following is valid: CREATE DATABASE LINK PSLS.BIGWHEEL.COM USING 'production_sales'; The following is invalid: CREATE DATABASE LINK prodsales USING 'production_sales'; Wit h GLOBAL_NAMES enabled, every dat abase link wit h t he sam e nam e connect s t o t he sam e dat abase, and every link int o a given dat abase has t he sam e nam e. Thus, every obj ect in t he dist ribut ed environm ent is guarant eed t o be uniquely ident ified if it is specified wit h a schem a nam e and a link nam e; for exam ple, [email protected] GWHEEL.COM refers t o t he sam e obj ect for every dat abase in t he Bigwheel Bicycle environm ent .

6 .2 .2 D a t a D ict ion a r y Vie w s a n d Loca t ion Tr a n spa r e n cy The connect ion bet ween global nam ing and t he global dat a dict ionary is in t he Oracle dat a dict ionary view DBA_SYNONYMS, sum m arized in Table 6.1.

Table 6.1. DBA_SYNONYMS Data Dictionary View Field Name owner

Description The owner of t he view

synonym _nam e The synonym t able_owner

The owner of t he obj ect ( m ay be a t able, view, procedure, or package)

t able_nam e

The obj ect nam e

db_link

For rem ot e obj ect s, t he nam e of t he dat abase link t o t he dat abase in which t he obj ect resides

Obviously, if GLOBAL_NAMES is enabled, t hen t he db_link field in t his dat a dict ionary view is not only t he nam e of t he link t o t he rem ot e dat abase but also t he nam e of t he rem ot e dat abase. So t he sam e values for synonym _nam e, t able_owner, t able_nam e, and db_link will refer t o t he sam e obj ect for all part icipant s in t he dist ribut ed syst em .

163

Oracle Distributed Systems Oracle's synonym s are t he key t o providing locat ion t ransparency because, as we have seen, a synonym can shield local users from having t o know about t he locat ion of a given obj ect . At t he sam e t im e, t he DBA_SYNONYMS dat a dict ionary view cont ains t he det ails about rem ot e obj ect s for t hose who need t o know. Thus, synonym s solve t he problem of creat ing a global dat a dict ionary t hat uniquely ident ifies all obj ect s in t he dist ribut ed environm ent while ensuring locat ion t ransparency.

164

Oracle Distributed Systems

Ch a pt e r 7 . Sa m ple Con figu r a t ion s There are probably as m any dist ribut ed dat abase configurat ions as t here are dist ribut ed dat abases. This chapt er provides an overview of t he m ost com m on problem s t hat dist ribut ed dat abase syst em s can solve and discusses t he choices and t rade- offs associat ed wit h each. I hope t hat one or m ore of t hese sam ple archit ect ures corresponds t o yours.

7 .1 Th e H igh - Ava ila bilit y Syst e m The generally accept ed definit ion of a high- availabilit y syst em is one t hat is operat ional 99.9% of t he t im e, which t ranslat es t o no m ore t han 8 hours and 45 m inut es of downt im e per year. Most hardware vendors have product s t hat are designed t o ensure t he high availabilit y of servers, disk drives, and ot her com ponent s. I n t he case of servers, t he recom m ended solut ion is usually a clust ering t echnology. I n som e cases, high- availabilit y syst em s deliver t he added benefit of scalabilit y because t hey require redundant com put ers t hat can share t he workload. Designing high availabilit y int o a dat abase syst em , however, t akes m ore t han j ust buying high- availabilit y hardware. Oracle gives you t hree choices for creat ing a highavailabilit y syst em : • • •

A hot st andby dat abase Oracle parallel server ( OPS) Advanced replicat ion

Of t hese t hree, t he only one t hat is really a dist ribut ed dat abase is t he advanced replicat ion solut ion.

7 .1 .1 Th e H ot St a n dby D a t a ba se Oracle's hot st andby dat abase solut ion can best be described as a dat abase t hat is in a st at e of perpet ual m edia recovery. The st rat egy is t o creat e a backup of your dat abase on a second m achine and t o ship your archived redo logs t o t he backup m achine, where t hey are applied t o t he backup dat abase. I n t he event t hat your prim ary dat abase fails, you can conclude t he recovery process on t he st andby dat abase, open it , and direct your users t o it . The st eps t o creat e a hot st andby dat abase are as follows: 1. Perform a backup ( hot or cold) of your prim ary dat abase. Not e t hat your prim ary dat abase m ust be in ARCHI VELOG m ode. 2. Creat e a cont rol file for t he st andby dat abase by issuing t he ALTER DATABASE CREATE STANDBY CONTROLFI LE com m and from your prim ary dat abase: 3. Oracle Server Manager Release 3.0.4.0.0 - Production 4. 5. (c) Copyright 1997, Oracle Corporation. All Rights Reserved. 6. 7. Oracle8 Enterprise Edition Release 8.0.4.1.0 - Production

165

Oracle Distributed Systems 8. With the Partitioning and Objects options 9. PL/SQL Release 8.0.4.1.0 - Production 10. 11. SVRMGR> connect internal 12. Connected. 13. SVRMGR> ALTER DATABASE CREATE STANDBY CONTROLFILE 14. 2> AS '/u/oracle/admin/PHQS/bdump/standbyPHQS.ctl' 15. 3> / Statement processed. 16. Archive t he current redo logs of t he prim ary dat abase: 17. SVRMGR> ALTER DATABASE ARCHIVELOG CURRENT 18. 2> / Statement processed. 19. Transfer t he files from t he backup perform ed in St ep 1, t he st andby cont rol file creat ed in St ep 2, and t he archived redo log from St ep 3 t o t he backup m achine.

Your life will be m uch easier if you use an ident ical direct ory st ruct ure for your dat a, configurat ion, and archived redo log files on t he backup m achine. Oracle assum es t hat t he st ruct ure is ident ical, but if you m ust use a different direct ory st ruct ure, you m ust set t he I NI T.ORA param et ers DB_FI LE_NAME_CONVERT and LOG_FI LE_NAME_CONVERT in t he st andby dat abase. For exam ple: FILE_NAME_CONVERT = '"/vol01/oradata/PHQS" "/vol01/ oradata/STANDBY/PHQS"' 20. 21. St art t he st andby dat abase on t he backup m achine: 22. SVRMGR> CONNECT INTERNAL 23. Connected. 24. SVRMGR> STARTUP NOMOUNT 25. 2> / 26. Statement processed. 27. SVRMGR> ALTER DATABASE MOUNT STANDBY DATABASE 28. 2> / 29. Statement processed. 30. SVRMGR> ALTER DATABASE 31. 2> RECOVER FROM '/u/oracle/admin/PHQS/arch' 32. 3> STANDBY DATABASE 4> / The st andby dat abase is now m ount ed and has begun m edia recovery, applying archived redo logs from t he direct ory specified in t he I NI T.ORA param et er LOG_ARCHI VE_DEST. I n order t o keep t he st andby dat abase up t o dat e, you m ust

166

Oracle Distributed Systems copy archived redo logs from t he prim ary m achine t o t he backup m achine and apply t hem wit h t he ALTER DATABASE RECOVER FROM com m and.

7 .1 .1 .1 Adva n t a ge s a n d disa dva n t a ge s of t h e h ot st a n dby da t a ba se The chief advant age of t he st andby dat abase ( and in m y opinion, it s only redeem ing virt ue) is t hat it is very easy t o set up and operat e. Script ing t he j ob t o copy archived redo logs t o t he backup m achine is t rivial, and swit ching t o t he st andby in t he event of failure can be done in a m at t er of m inut es. However, t he st andby dat abase does have som e undesirable propert ies. First , t he st andby m achine it self essent ially goes t o wast e; it m ust be held in reserve for t he event of failure, doing not hing but applying archived redo logs. Alt hough you could use it s processing power for m iscellaneous j obs, t hey m ust accept t he fact t hat t hey m ay be halt ed at any t im e. This rest rict ion is especially frust rat ing because t he backup m achine should be of t he sam e capacit y as t he m achine it is m irroring— generally an expensive one! Anot her downside of t he st andby dat abase solut ion is t hat once t he st andby is act ivat ed, it com plet ely replaces t he prim ary dat abase; t here is no going back. Thus, once t he problem on t he prim ary m achine is correct ed, t he only way t o put it back int o service is t o creat e a hot st andby dat abase on it and act ivat e it . This swit ch back t o t he prim ary m achine t akes at least as long as a full dat abase backup.

I n Oracle8i, t he hot st andby dat abase can be opened in read- only m ode and can t hen go back t o being a st andby wit hout requiring a com plet e rebuild.

7 .1 .2 Or a cle Pa r a lle l Se r ve r Oracle parallel server is a t echnology t hat allows one physical dat abase t o be accessed by dat abase inst ances running on t wo or m ore com put ers. This archit ect ure affords high availabilit y because if one of t he m achines fails, processing can cont inue on t he rem aining node( s) . Oracle8 has advanced t he t echnology so t hat , in som e cases, users' connect ions are rem apped t o a different node t ransparent ly. And, unlike t he st andby dat abase archit ect ure, each of t he nodes in an OPS configurat ion can be used for processing. I n t his sense, OPS is a high- availabilit y archit ect ure t hat also provides scalabilit y.

7 .1 .2 .1 Adva n t a ge s a n d disa dva n t a ge s of Or a cle pa r a lle l se r ve r The t heory of OPS is fant ast ic: it offers high availabilit y by virt ue of m ult iple nodes, and it can scale since nodes can be added t o t he configurat ion. Alas, t he t heory of OPS differs som ewhat from t he realit y. The m ost significant issue t hat prevent s OPS

167

Oracle Distributed Systems from being a perfect solut ion is t hat of pinging. A ping occurs when a user on one node of a parallel server request s dat a t hat has been m odified by a user on anot her node. When t his happens, t he dat a m ust be writ t en from t he m odifying node back t o t he dat abase, from which t he request ing node reads it ( see Figure 7.1) .

Figu r e 7 .1 . Or a cle pa r a lle l se r ve r pin gin g

As you would im agine, pinging is ext rem ely expensive, and an excessive am ount of it can m ake OPS perform ance worse t han t he perform ance of a single m achine! You can assum e t hat any applicat ion t hat is not designed wit h OPS in m ind will experience perform ance degradat ion wit h OPS. You can design an applicat ion t hat m inim izes pinging. The t rick is t o ensure t hat any given set of dat a is m odified on only one node and t hat users on ot her nodes do not access dat a t hat anot her node m odifies. For exam ple, if t he dat abase serves m ult iple applicat ions, you can designat e individual nodes for specific applicat ions. Anot her solut ion, for dat abases t hat house only one applicat ion, is t o use part it ion t ables, available wit h Oracle8. For exam ple, a CUSTOMER t able m ight be part it ioned on CUSTOMER_I D, and Server A would handle act ivit y for cust om ers 0t hrough 10,000, Server B would handle cust om ers 10,001 t horugh 20,000, and so on. Figure 7.2 shows t his sit uat ion.

Figu r e 7 .2 . Usin g t a ble pa r t it ion in g t o m in im ize pin gs w it h Or a cle pa r a lle l se r ve r

168

Oracle Distributed Systems

I n order t o direct act ivit y t o t he appropriat e node, you would have t o include a t ransact ion m onit or, or your applicat ion it self would have t o have t he int elligence t o send t ransact ions t o t he appropriat e node. Of course, dat a part it ioning is generally not t his sim ple, and it oft en requires schem a denorm alizat ion t o be effect ive. Ot her issues wit h OPS include t he fact t hat m ost popular hardware vendors are st ill perfect ing t heir clust ering t echnologies. Sun, for exam ple, has only recent ly shipped clust er support for m ore t han t wo nodes. I n addit ion, because of t he overhead of t he operat ing syst em 's clust ering soft ware and t he dist ribut ed lock m anager, each addit ional node added t o a clust er does not add one m achine's wort h of processing power, as shown in Figure 7.3.

Figu r e 7 .3 . Pr oce ssin g pow e r ve r su s n u m be r of pr oce ssor s

169

Oracle Distributed Systems I n short , OPS can be an ideal solut ion for bot h high availabilit y and scalabilit y, but t he benefit s are not aut om at ic.

7 .1 .3 Adva n ce d Re plica t ion One of t he int ended uses of advanced replicat ion is t o provide a high- availabilit y solut ion. As described in Chapt er 12, dat a changes can be propagat ed synchronously am ong t he nodes part icipat ing in a replicat ed environm ent . I n effect , you can have a syst em in which dat a is guarant eed t o be ident ical at m ult iple locat ions. Such an archit ect ure delivers not only high availabilit y but also horizont al scalabilit y, because applicat ion users can be direct ed t o any node, as shown in Figure 7.4.

Figu r e 7 .4 . Usin g a dva n ce d r e plica t ion t o a ch ie ve h or izon t a l sca la bilit y

7 .1 .3 .1 Adva n t a ge s a n d disa dva n t a ge s of a dva n ce d r e plica t ion Unlike t he hot st andby dat abase, t he advanced replicat ion archit ect ure allows you t o ut ilize all m achines in your environm ent . Unlike OPS, wit h advanced replicat ion t here is no issue wit h pinging. I n addit ion, advanced replicat ion provides a built - in redundancy since dat a is replicat ed at all sit es. Also, t here is no pot ent ial for conflict s wit h synchronous propagat ion. Unfort unat ely, t here is no free lunch; advanced replicat ion in general has it s cost s, andsynchronous propagat ion in part icular exact s it s t oll. Synchronous propagat ion ut ilizes t he t wo- phase com m it prot ocol t o ensure t hat every t ransact ion is applied at every sit e. The t wo- phase com m it incurs t he overhead of having t o coordinat e every t ransact ion: each sit e m ust go t hrough t he prepare phase and not ify t he global coordinat or, which t hen inst ruct s all sit es t o com m it or roll back t heir work. The m ore sit es involved, t he m ore com m unicat ion necessary for each t ransact ion. And, if any

170

Oracle Distributed Systems of t he sit es is unable t o com m it for any reason, such as a net work problem or a dat abase crash, all insert , updat e, and delet e act ivit y will cease, and t he applicat ion will hang. Therefore, it is crit ical t o provide as m uch redundancy as possible in t erm s of disk m irroring and net work connect ivit y. Alt ernat ively, you can use asynchronous propagat ion and accept t he corresponding lat ency and pot ent ial for conflict s. Figure 7.5 shows a sam ple configurat ion.

Figu r e 7 .5 . Usin g m ir r or e d disk s a n d r e du n da n t n e t w or k con n e ct ion s in a n a dva n ce d r e plica t ion e n vir on m e n t

Anot her issue wit h advanced replicat ion is it s overhead. By Oracle's account , advanced replicat ion requires six t im es as m uch shared pool usage, and asynchronous propagat ion generat es four t im es as m uch undo act ivit y. As wit h OPS, regardless of t he propagat ion m et hod, t he addit ion of a m achine does not yield a corresponding increase in capacit y. Furt herm ore, as wit h OPS, it is a good idea t o part it ion your applicat ion in such a way t hat t he act ivit y on any part icular node accesses unique dat a. This is especially beneficial if you are using asynchronous propagat ion because part it ioning will m inim ize t he chance of conflict s. I f you are using asynchronous replicat ion wit h a high propagat ion frequency, you should include conflict resolut ion t echniques such as Sit e Priorit y and Lat est Tim est am p on your replicat ed t ables. Finally, an advanced replicat ion solut ion t hat is int ended t o deliver high availabilit y locally as well as geographic dat a dist ribut ion can be difficult t o deliver, at least in t he case of syst em s wit h high volum es of act ivit y ( i.e., t ens of DML act ions per second) . The problem is t hat it is not possible t o have separat e propagat ion frequencies for replicat ion groups propagat ing t o t he sam e rem ot e sit e, nor is it possible t o creat e a m ult i- m ast er environm ent in which not all m ast ers com m unicat e wit h t he rem ot e sit e. I f you are using asynchronous propagat ion, t he frequency of updat es is t he sam e for all replicat ion groups t o a part icular sit e, and every sit e in a m ult i- m ast er environm ent m ust com m unicat e wit h every ot her sit e. I t would be desirable t o design a syst em ( see Figure 7.6) in which local propagat ion occurs at a high frequency, while propagat ion t o a rem ot e sit e is only from a single sit e.

171

Oracle Distributed Systems

Figu r e 7 .6 . A sin gle t r a n scon t in e n t a l lin k

Though t his exam ple m ay be ext rem e, t he concept is not ent irely unreasonable. The advanced replicat ion t echnology, as it exist s now, would require a t opology like t he one shown in Figure 7.7.

Figu r e 7 .7 . Cu r r e n t a dva n ce d r e plica t ion com m u n ica t ion r e qu ir e m e n t s

You can achieve different updat e frequencies only by using synchronous propagat ion am ong t he local sit es and asynchronous propagat ion t o t he rem ot e sit e. Advanced replicat ion can provide high availabilit y and scalabilit y, but it also includes overhead and m ay not deliver t he desired flexibilit y in cases in which local high availabilit y is t o be coupled wit hgeographic dat a dist ribut ion.

172

Oracle Distributed Systems

7 .2 Ge ogr a ph ic D a t a D ist r ibu t ion As hint ed in t he previous sect ion, m any organizat ions have a requirem ent for global dat a dist ribut ion. I n ot her words, it m ay be necessary t o m aint ain t he sam e dat a in separat e dat a cent ers on m achines t hat are probably not even on t he sam e net work. For exam ple, a web sit e t hat t racks user dat a about news preferences m ay deploy dat abases in California, Chicago, and New York so t hat it can direct user t raffic t o a sit e t hat is nearby. Or a large corporat ion m ay replicat e dat a about it s product s and prices t o num erous regional headquart ers. Oracle's advanced replicat ion is t he clear choice for m eet ing t hese requirem ent s. I t can provide read/ writ e access t o dat a in m ult iple locat ions. I n addit ion, if asynchronous propagat ion is being used, dat a is always fully accessible locally regardless of t he availabilit y of t he rem ot e sit es. Sit es also can be added or delet ed as requirem ent s change. The m ost significant issues wit h using advanced replicat ion for geographic dat a dist ribut ion are dat a lat ency and conflict s. Since synchronous propagat ion is not a viable opt ion for m achines t hat are in different locat ions, every sit e will be out of sync wit h it s peers by at least one second ( t he short est propagat ion frequency possible) . I f your applicat ion is one t hat allows t he sam e t ables t o be updat ed frequent ly from m ult iple locat ions, t his lat ency m ay be det rim ent al. Consider, for exam ple, a user of a web sit e who changes her news preferences while she is connect ed t o t he dat abase in Chicago. I f she t hen leaves t he sit e and com es back a couple of seconds lat er, connect ing t o t he California dat abase, she m ight not see t he changes she has m ade. She will probably change t he news preferences again, which will result in a conflict when t he dat a from t he Chicago and California sit es finally do propagat e. This scenario brings us t o t he second caveat : conflict s. I f dat a is propagat ing asynchronously, it is possible and even likely t hat conflict s will arise. Any replicat ed applicat ion m ust plan for and provide aut om at ic resolut ion of conflict s. Please refer t o Chapt er 15, for advice.

7 .3 W or k flow Pa r t it ion in g Workflow part it ioning refers t o applicat ions t hat are dist ribut ed across m ult iple dat abases, each of which is associat ed wit h a part icular business funct ion. The t radit ional exam ple is t he dist ribut ed syst em t hat has different sit es allocat ed t o order ent ry, shipping, and billing. These dat abases m ay or m ay not be at t he sam e geographic locat ion and m ay or m ay not be on t he sam e net work. As a general rule, t he propagat ion m ode for t hese applicat ions is asynchronous. Figure 7.8 shows part it ioning am ong t hree sit es.

Figu r e 7 .8 . W or k flow pa r t it ion in g a m on g t h r e e sit e s

173

Oracle Distributed Systems

An applicat ion t hat lends it self t o workflow part it ioning is an ideal candidat e for m ult i- m ast er t able replicat ion. Since t he dat a updat es t hat occur at each sit e are dist inct , it is highly unlikely t hat conflict s will arise. And t he probabilit y of conflict s can be reduced significant ly by incorporat ing business rules int o t he applicat ion. For exam ple, in t he previous exam ple, an order cannot be billed unt il it has shipped. Also, Oracle provides built - in conflict resolut ion m et hods t hat are specifically designed for workflow part it ioning, such as priorit y groups. Refer t o Chapt er 15 for det ails about im plem ent ing priorit y groups and ot her conflict resolut ion t echniques. As wit h ot her advanced replicat ion archit ect ures, workflow part it ioning m ust cope wit h t he lat ency inherent in asynchronous propagat ion.

7 .4 D a t a Colle ct ion a n d Con solida t ion Manyorganizat ions gat her dat a from several locat ions and consolidat e it int o a single dat abase. The single dat abase is oft en a cent ralized, com pany- wide reposit ory. Exam ples include ret ail chains t hat upload sales dat a from t heir sales out let s every night ( see Figure 7.9) or a sales force arm ed wit h lapt ops int o which t hey ent er dat a about cust om er leads ( see Figure 7.10) . The dist inguishing feat ure of t hese scenarios is t hat t he dat abases are not expect ed t o be in const ant cont act wit h one anot her; dat a lat ency can be quit e high, while bandwidt h can be quit e low.

174

Oracle Distributed Systems

Figu r e 7 .9 . Re t a il st or e s com m u n ica t e w it h h e a dqu a r t e r s n igh t ly

Figu r e 7 .1 0 . Sa le s pe r son n e l syn ch r on ize la pt ops w it h h e a dqua r t e r s

Bot h of t hese scenarios are perfect candidat es for Oracle's updat eable snapshot s, a feat ure of advanced replicat ion. Updat eable snapshot s work well in t hese environm ent s because dat a can be horizont ally part it ioned and because updat es t o t he dat a can be pushed t o t he m ast er sit e on dem and. The ret ail out let s can upload daily sales t ransact ions aft er t he st ore closes, and t he t raveling salespeople can send

175

Oracle Distributed Systems updat es t o headquart ers when t hey check int o t heir hot els and pot ent ially receive updat es t hat t heir colleagues have m ade. As wit h m ult i- m ast er replicat ion, updat eable snapshot s m ay result in conflict s, and unfort unat ely t he resolut ion m et hods are not as com prehensive as t hey are for m ult i- m ast er replicat ion. I n effect , you m ust m ake t he choice of accept ing one updat e or t he ot her. I f possible, t he applicat ion should not allow m ult iple snapshot sit es t o updat e t he sam e dat a. Sales personnel, for exam ple, should be allowed t o updat e dat a pert aining only t o cust om ers for whom t hey are responsible. Furt herm ore, t he enforcem ent of dat a int egrit y becom es m ore t roublesom e in an environm ent in which part icipant s connect int erm it t ent ly. I t m ay not be pract ical t o deploy all dat a required t o validat e t ransact ions at t he snapshot sit es, so applicat ions m ay have t o include logic t o perform dat a validat ion when t he snapshot sit e connect s. For exam ple, a salesperson m ight book an order, only t o find t hat t he client is over his credit lim it when t he order is sent t o headquart ers. Ot her issues t o consider in an updat eable snapshot configurat ion are securit y and t he fact t hat t he local personnel responsible for t he adm inist rat ion of each snapshot sit e m ay lack t he skills t ypically available at t he dat a cent er t hat houses t he m ast er dat abase.

7 .5 Loose ly Cou ple d Fe de r a t ion I f not hing else, you probably have a dist ribut ed syst em configurat ion t hat can best be described as aloosely coupled federat ion. Are you sending sales t ransact ions from an Oracle dat abase t o a m ainfram e for billing? Are you ext ract ing audit t rails from your web server int o a dat a warehouse? Are you reconciling t he phone com pany's elect ronic invoices wit h your voice m ail syst em ? Each of t hese scenarios could be classified as a dat abase federat ion. The dat a m ay be in disparat e form s, and t here are no real- t im e t ransact ions t aking place. I f one or m ore of t he dat abases in your federat ion is Oracle based, you can use a variet y of t echniques t o m ove dat a from one dat abase t o anot her, including: Dat abase links I f bot h sit es are Oracle based, dat a can be select ed, insert ed, or updat ed over a dat abase link. SQL* Loader This t ool loads non- Oracle dat a from a form at t ed t ext file int o an Oracle t able. Pro* C/ C+ + , Pro* COBOL, Pro* FORTAN, Pro* Ada Oracle precom pilers allow you t o em bed SQL st at em ent s int o program s, allowing you t o m igrat e dat a from a file or ot her ext ernal source int o Oracle. Oracle Gat eway product s

176

Oracle Distributed Systems These product s provide SQL access from an Oracle dat abase t o a foreign dat a source. The key t o success wit h a federat ed dat abase syst em is a writ t en specificat ion and robust ness. Because t hese syst em s are oft en cobbled t oget her over t im e and oft en viewed as inform al st opgaps, t heir qualit y oft en suffers. I t is not uncom m on for such a syst em t o com e com plet ely unraveled im m ediat ely aft er it s chief caret aker leaves t he organizat ion.

177

Oracle Distributed Systems

178

Oracle Distributed Systems

Ch a pt e r 8 . En gin e e r in g Con side r a t ion s Any applicat ion t hat runs in a dist ribut ed environm ent m ust t ake it s dist ribut ed nat ure int o account if it is t o be successful. Considerat ions such as dat a consist ency, t ransact ional int egrit y, conflict avoidance, and error handling are only a few of t he issues t o cont end wit h. This chapt er visit s som e of t hese issues and suggest s best pract ices for addressing t hem .

8 .1 Sch e m a D e sign a n d I n t e gr a t ion As wit h m ost syst em s, you are fort unat e if you are able t o design a dist ribut ed dat abase syst em from t he ground up. I n t hese cases, you have t he flexibilit y t o locat e dat a opt im ally and t o avoid anom alies in nam ing and const raint enforcem ent . But whet her your syst em is prenat al or legacy, you face t he challenges of dat a placem ent and schem a int egrat ion for syst em s. Since I 'm assum ing in t his book t hat all part icipat ing dat abases in t he syst em are Oracle based, I won't address t he addit ional com plicat ions associat ed wit h a het erogeneous dist ribut ed syst em . The process for designing a dist ribut ed dat abase schem a is not m uch different from t hat for designing a local schem a in t he init ial st ages; ent it ies are ident ified, relat ionships are defined, processes are m apped, and so on. The st ep t hat is unique t o dist ribut ed syst em s is dat a placem ent , ot herwise known asdat a part it ioning or dat a fragm ent ing. Chapt er 5, discussed m et hodologies for det erm ining how t o part it ion dat a; t his chapt er discusses addit ional considerat ions t he applicat ion developer m ust t ake int o account .

8 .1 .1 I n t e r da t a ba se Re fe r e n t ia l I n t e gr it y When you part it ion dat a am ong m ult iple dat abases, you m ay end up separat ing ent it ies t hat have a parent - child relat ionship. However, Oracle does not provide declarat ive referent ial int egrit y const raint s bet ween dat abases. So, if you place your ORDERS t able in one dat abase and your ORDER_I TEMS t able in anot her, you cannot rely on Oracle t o ensure t hat every line it em in t he ORDER_I TEMS t able corresponds t o an order in t he ORDERS t able: SQL> 2 3 4 5

ALTER TABLE order_items ADD ( CONSTRAINT fk_order_item_order_num FOREIGN KEY (order_number) REFERENCES [email protected] (order_number) );

REFERENCES [email protected] (userid) * ERROR at line 4: ORA-02021: DDL operations are not allowed on a remote database So, how do we est ablish int erdat abase referent ial int egrit y? The short answer is t hat you shouldn't be in a posit ion t o require it ! I t m akes no sense, for exam ple, t o separat e t ables wit h parent - child relat ionships int o t wo separat e dat abases.

179

Oracle Distributed Systems Yet som et im es such separat ions are inevit able. Consider an organizat ion t hat has it s prim ary CUSTOMERS t able in t he headquart ers dat abase, but t he ORDERS t able for t he order ent ry syst em is locat ed in a different dat abase at t he regional sales sit e. One way t o handle t his sit uat ion is t o writ e a BEFORE ROW t rigger on t he ORDERS t able t hat checks for t he exist ence of a corresponding CUSTOMER_I D record in t he rem ot e CUSTOMERS t able whenever a record is insert ed: CREATE OR REPLACE TRIGGER t_i_orders BEFORE INSERT ON orders FOR EACH ROW v_count NUMBER; BEGIN SELECT count(*) INTO v_count FROM [email protected] c WHERE c.customer_id = :new.customer_id; IF v_count = 1 THEN :new.username := USER; :new.rectime := SYSDATE; :new.site := DBMS_REPUTIL.GLOBAL_NAME; END IF; END; The downside t o t his solut ion is t hat it int roduces a dependency on t he rem ot e dat abase; if t he rem ot e dat abase is unavailable, no new orders can be creat ed. This dependency can be alleviat ed som ewhat by including an ORDER_STATUS colum n in t he ORDERS t able which can flag orders as UNVALI DATED. Records could t hen be insert ed int o t he ORDERS t able even when t he rem ot e dat abase is unavailable, and t heir CUSTOMER_I Ds can be verified lat er when t he rem ot e dat abase is available. A sim pler alt ernat ive t o enforcing int erdat abase referent ial int egrit y, and one which does not rely on t he accessibilit y of t he rem ot e dat abase, is t o creat e a local snapshot of t he m ast er t able using t he WI TH PRI MARY KEY clause available in Oracle8: CREATE SNAPSHOT customers TABLESPACE oe_data STORAGE (INITIAL 10M NEXT 10M PCTINCREASE 0) REFRESH FAST START WITH sysdate NEXT trunc(sysdate) + 1 WITH PRIMARY KEY AS SELECT customer_id, customer_name FROM [email protected]; ALTER TABLE orders ADD ( CONSTRAINT fk_orders_customer_id FOREIGN KEY (customer_id) REFERENCES snap$_customers(customer_id) );

180

Oracle Distributed Systems The WI TH PRI MARY KEY clause act ually creat es a prim ary key on t he SNAP$_CUSTOMERS t able, which is t he t able underlying t he CUSTOMERS snapshot . This approach, in effect , allows a declarat ive referent ial int egrit y const raint on a rem ot e obj ect . However, snapshot s by design have a cert ain am ount of lat ency. The snapshot t able is only as current as t he m ost recent refresh.

8 .1 .2 N a m in g Con ve n t ion s Alt hough t here areno rest rict ions per se on obj ect nam es in a dist ribut ed environm ent , som e nam es are bet t er t han ot hers. First , t o t he ext ent possible, you should t ry t o keep nam es unique across all schem a in t he dist ribut ed environm ent . This is not a requirem ent , but it m akes adm inist rat ion less confusing. An exam ple of a poor choice for a t able nam e is COUNTRY or COUNTRI ES. Why? Because t his nam e is likely t o be com m on t o m ore t han one applicat ion and t herefore several schem a. When t ables are replicat ed, eit her as m ast er t ables or snapshot s, it m ay not be possible t o creat e ident ical public synonym s in all dat abases. You can avoid nam e space collisions by prefixing t able nam es wit h t wo or t hree charact ers t hat associat e t hem wit h a given applicat ion. For exam ple, t he COUNTRI ES t able t hat t he order ent ry syst em uses would becom e OE_COUNTRI ES. Anot her pot ent ial issue in a dist ribut ed dat abase is t he lengt h of t able nam es. Various replicat ion- relat ed obj ect s have generat ed nam es t hat are based on a t able nam e such as t he SNAP$_CUSTOMERS of t he previous exam ple. I f t he generat ed nam e ends up being m ore t han 30 charact ers ( t he m axim um lengt h of a t able nam e in Oracle) , t hen t he nam e is t runcat ed, which m ay result in nam ing conflict s. Since t he longest prefix in use is seven charact ers ( t he updat eable snapshot log USLOG$_) , keep your t able nam es short —never m ore t han 23 charact ers.

8 .1 .3 D ist r ibu t e d Qu e r ie s a n d Tr a n sa ct ion s Oracle perform s dist ribut ed queries and t ransact ions t ransparent ly and aut om at ically. St rict ly speaking, t he applicat ion need not have any knowledge of where dat a is act ually locat ed. However, from a pract ical point of view, it is in your best int erest t o t ake t he locat ion of your dat a int o account . Dist ribut ed queries fall int o t wo broad cat egories: queries whose t arget t ables are all locat ed at a single rem ot e sit e ( also known as " rem ot e queries" ) and queries whose t arget t ables are locat ed at m ult iple sit es. When an applicat ion init iat es a rem ot e query, t he opt im izer recognizes t hat t he t ables involved are in a single dat abase, and it passes t he ent ire query t o t he rem ot e dat abase, which execut es it wit h t he sam e efficiency as a local query. The rem ot e dat abase t hen sends t hat dat a back. There are really no opt im izat ions t hat you can m ake on a rem ot e query, alt hough if you find t hat your applicat ion is perform ing a high num ber of rem ot e queries, you m ight consider relocat ing t he dat a t o t he local dat abase eit her in it s ent iret y or as snapshot s, t hereby reducing t he net work t raffic. Queries t hat gat her dat a from m ult iple sources can benefit from som e opt im izat ions as we shall see. For purposes of illust rat ion, consider t he following query:

181

Oracle Distributed Systems SELECT

customer_name, TO_CHAR(order_date, 'Month') month, SUM(order_total) monthly_sales FROM [email protected] c, [email protected] o WHERE c.customer_id = o.customer_id GROUP BY customer_name, TO_CHAR(order_date, 'Month'), TO_CHAR(order_date, 'MM') ORDER BY customer_name, to_char(order_date, 'MM'); CUSTOMER_NAME -------------Chain Reaction Missing Link Missing Link Spoken Word Spoken Word

MONTH -----June April May May June

MONTHLY_SALES ------------505 345 398 475 305

To decom pose t his query, Oracle m ust first det erm ine which colum ns are in which t ables by querying t he dat a dict ionaries at PHQS.BI GWHEEL.COM and PSLS.BI GWHEEL.COM. Then it ret rieves t he dat a from t hese t wo rem ot e dat abases. These queries ret urn all records from t he rem ot e t ables. I n PHQS.BI GWHEEL.COM: Statement -----------------------------------------------------------------SELECT "CUSTOMER_ID","CUSTOMER_NAME" FROM "CUSTOMERS" "C" I n PSLS.BI GWHEEL.COM: Statement -----------------------------------------------------------------SELECT "CUSTOMER_ID","ORDER_TOTAL","ORDER_DATE" FROM "ORDERS" "O" Oracle perform s j oins and aggregat ions of t his dat a at t he sit e at which t he query originat ed, also known as t he driving sit e. Here we see several opport unit ies for opt im izat ion, described in t he following sect ions.

8 .1 .3 .1 Con t r ol t h e dr ivin g sit e Be m indful of how m uch dat a is being shipped t o t he driving sit e. Whenever possible, originat edist ribut ed queries from t he dat abase t hat holds t he m ost t arget dat a, or use t he DRI VI NG_SI TE hint t o force a specific sit e t o be t he driving sit e. I n our sam ple query, we could force t he driving sit e t o be PSLS.BI GWHEEL.COM since t he ORDERS t able is bigger t han t he CUSTOMERS t able: SELECT

/*+DRIVING_SITE(orders)*/ customer_name, TO_CHAR(order_date, 'Month') month, SUM(order_total) monthly_sales

182

Oracle Distributed Systems FROM

[email protected] c, [email protected] o . . .

This hint forces t he sit e wit h t he ORDERS t able t o perform t he j oins and aggregat ion operat ions t he query requires. Not e t hat t he query result s are st ill sent over t he net work t o t he sit e t hat originat ed t he query. Anot her way t o force a specific sit e t o be t he driving sit e is t o creat e views of rem ot e dat a at t he desired sit e. The view t ricks t he opt im izer int o t hinking t hat t he t able is at t he sit e. Again, referring t o our exam ple, we could force PSLS.BI GWHEEL.COM t o be t he driving sit e by creat ing a view on t he CUSTOMERS t able t here, and rewrit ing t he query t o select from t hat view. At PSLS.BI GWHEEL.COM: CREATE VIEW customer_view AS SELECT customer_id, customer_name FROM [email protected]; At t he sit e originat ing t he query: SELECT

FROM

customer_name, TO_CHAR(order_date, 'Month') month, SUM(order_total) monthly_sales [email protected] c, [email protected] o

This query accesses t he dat a on PHQS.BI GWHEEL.COM only indirect ly. To Oracle's opt im izer, it appears t o be a sim ple rem ot e query. Just as im port ant as cont rolling t he driving sit e in dist ribut ed queries is cont rolling t he use of indexes. This brings us t o t he next t ip.

8 .1 .3 .2 Con t r ol in de x u sa ge Regret t ably, t he only way t hat Oracle will even consider t he use of indexes in dist ribut ed queries is if t he dat abase uses t he cost - based opt im izer. I f your dat abases are configured t o use t he rule- based opt im izer, your dist ribut ed queries are perform ing full t able scans.

8 .1 .4 M a in t e n a n ce of D a t a ba se Lin k Con n e ct ion s Whenever a user issues a rem ot e procedure call or execut es a SQL st at em ent t hat references rem ot e dat a and t he user does not already have a connect ion t o t he rem ot e dat abase, Oracle aut om at ically connect s using t he dat abase link available t o t he user. Oracle m aint ains t his connect ion eit her unt il t he user logs off or unt il t he connect ion is explicit ly closed. I n ot her words, connect ions persist even aft er t hey m ay no longer be necessary. This can cause undue st rain on resources such as net work bandwidt h, m achine m em ory, and dat abase t hroughput . I t can even cause unneeded expense if t he connect ivit y is over a t hird- part y vendor's net work.

183

Oracle Distributed Systems Your applicat ion can avoid all of t hese problem s by explicit ly closing dat abase links when t hey are no longer necessary. To do so, all t ransact ions t hat ut ilize t he link m ust be com plet ed ( eit her com m it t ed or rolled back) , and any cursors t hat were opened at t he rem ot e sit e m ust be closed. When t hese requirem ent s are m et , your applicat ion can issue t his com m and: ALTER SESSION CLOSE DATABASE LINK linkname; Not e t hat t he ALTER SESSI ON syst em privilege m ust be grant ed t o all users of t he applicat ion. ALTER SESSI ON is included in t he CONNECT role, but t his role is not necessarily grant ed t o all users.

8 .1 .5 Er r or H a n dlin g There are a num ber of Oracle errors t hat are specific t o dist ribut ed dat abases. An applicat ion t hat perform s any rem ot e or dist ribut ed operat ions m ust t rap t hese except ions in addit ion t o t he norm al error handling of a single- dat abase applicat ion. The following list s t hese Oracle errors: ORA- 00160: global t ransact ion lengt h num is great er t han m axim um num Cause: An ext ernal global t ransact ion I D wit h a field lengt h t oo large was passed in. Act ion: Report t he problem t o your ext ernal t ransact ion coordinat or vendor. ORA- 00161: t ransact ion branch lengt h num is illegal ( m axim um allowed num ) Cause: An ext ernal t ransact ion branch I D wit h eit her a lengt h t oo large or was passed in. Act ion: Report t he problem t o your ext ernal t ransact ion coordinat or vendor. ORA- 00162: ext ernal dbid lengt h num is great er t han m axim um ( num ) Cause: An ext ernal dat abase nam e wit h a field lengt h t oo large was passed in. Act ion: Report t he problem t o your ext ernal t ransact ion coordinat or vendor. ORA- 00163: int ernal dat abase nam e lengt h num is great er t han m axim um ( num ) Cause: An int ernal dat abase nam e wit h a field lengt h t oo large was passed in. Act ion: Report t he problem t o your ext ernal t ransact ion coordinat or vendor. The following list s m essages generat ed during dist ribut ed t ransact ions: ORA- 02040: rem ot e dat abase nam e does not support t wo- phase com m it

184

Oracle Distributed Systems Cause: A dist ribut ed updat e of m ore t han one dat abase was at t em pt ed, but t he nam ed dat abase does not support t he prepare phase of t he t wo- phase com m it , as det erm ined by it s logon t ransact ion t rait s. The t ransact ion was rolled back. Act ion: Do not at t em pt t o updat e t he nam ed dat abase, unless it is t he only dat abase updat ed in t he t ransact ion. Dist ribut ed updat es of m ore t han one dat abase in a single t ransact ion can be perform ed only if all dat abases support t he t wo- phase com m it m echanism . ORA- 02041: client dat abase did not begin a t ransact ion Cause: An updat e occurred at a coordinat ed dat abase wit hout t he coordinat or beginning a dist ribut ed t ransact ion. This m ay happen if a st ored procedure com m it s and t hen perform s updat es and t he st ored procedure is invoked rem ot ely. I t also could happen if an ext ernal t ransact ion m onit or violat es t he XA prot ocol. Act ion: I f t he cause is t he form er, check t hat no com m it is followed by an updat e. ORA- 02042: t oo m any dist ribut ed t ransact ions Cause: The dist ribut ed t ransact ion t able is full because t oo m any dist ribut ed t ransact ions are act ive. Act ion: I ncrease t he DI STRI BUTED_TRANSACTI ONS param et er in t he init ializat ion param et er file, shut down and rest art Oracle, or run fewer t ransact ions. I f it is cert ain t here are not t oo m any concurrent dist ribut ed t ransact ions, t his m ay be an int ernal error. I n t his case, cont act cust om er support . Shut t ing down and rest art ing t he inst ance could be a workaround. ORA- 02043: m ust end current t ransact ion before execut ing com m and Cause: A t ransact ion is in progress and one of t he following com m ands is issued: COMMI T FORCE, ROLLBACK FORCE, or ALTER SYSTEM ENABLE DI STRI BUTED RECOVERY in single process m ode. Act ion: Com m it or roll back t he current t ransact ion and ret ry t he com m and. ORA- 02044: t ransact ion m anager login denied: t ransact ion in progress Cause: A rem ot e t ransact ion m anager t ried t o log in while a dist ribut ed t ransact ion is in progress. A prot ocol error occurred in t he rem ot e t ransact ion m anager. Act ion: End t he current t ransact ion. ORA- 02045: t oo m any local sessions part icipat ing in global t ransact ions

185

Oracle Distributed Systems Cause: There are t oo m any sessions at t his sit e t o accom m odat e t his t ransact ion. Act ion: Use an exist ing dat abase link so t hat anot her session need not be creat ed at t he rem ot e sit e. ORA- 02046: dist ribut ed t ransact ion already begun Cause: I nt ernal error or error in ext ernal t ransact ion m anager. A server session received a begin_t ran RPC before finishing wit h a previous dist ribut ed t ransact ion. Act ion: Report t he problem t o your ext ernal t ransact ion coordinat or vendor.

8 .2 Applica t ion Tie r in g Applicat ion t iering refers t o separat ing various com ponent s of an applicat ion int o layers t hat can be m anaged independent ly. A classic exam ple is an I nt ernet applicat ion t hat m ust scale t o support t housands or m illions of users. For exam ple, consider t he case of a web sit e t hat allows users t o t rade st ocks online via t heir browsers. Such an applicat ion would run on web servers, applicat ion servers, and dat abase servers. Web servers are t he " front end" of t he applicat ion, responsible for accept ing request s from users and direct ing t hem t o applicat ion servers. The applicat ion servers house t he applicat ion's logic and int eract wit h t he dat abase. Scaling t he web server and applicat ion server layers of a t iered applicat ion is relat ively easy; j ust add m ore m achines! However, it is not so easy t o add dat abases since t he dat a m ust be consist ent across all dat abases in t he environm ent . For exam ple, a user who buys 100 shares of XYZ should see t he t rade recorded no m at t er what dat abase she connect s t o when visit ing t he sit e. Lat er chapt ers will exam ine dat a replicat ion, which is a m eans of achieving horizont al scalabilit y of dat abase servers.

8 .3 D e sign in g a Re plica t e d Syst e m There are a variet y of issues t hat are unique t o sit es ut ilizing Oracle's advanced replicat ion facilit ies. Areplicat ed syst em succeeds only if t he designers are aware of t hese idiosyncrasies and m ake t he right im plem ent at ion decisions. Again, t he sooner in t he process t hese design choices are m ade, t he bet t er t he chances for success.

8 .3 .1 Tr a n sa ct ion a l Con sist e n cy Oracle's m ult i- m ast er replicat ion preserves t he order of t ransact ions when it replicat es t hem t o part icipat ing sit es, and it also guarant ees t he consist ency of dat a at all sit es. So, if you have a replicat ed order ent ry syst em t hat creat es an ent ry in t he ORDERS t able in one t ransact ion and ent ries in t he ORDER_I TEMS t able as a second t ransact ion, Oracle will apply t he t ransact ions in t he sam e order at all rem ot e sit es.

186

Oracle Distributed Systems This is a crucial propert y of replicat ion; wit hout it , t ransact ions could fail because of violat ed int egrit y const raint s, and dat a would not be consist ent . Since Oracle respect s t he order of t ransact ions, row- level t ransact ions do not require any special handling in a replicat ed environm ent .

Oracle8 includes a feat ure called parallel propagat ion, which is a m eans t o replicat e m ult iple t ransact ions sim ult aneously. Thus, it is possible, and even likely, t hat t ransact ions will not be delivered t o part icipat ing m ast er sit es in t he sam e sequence in which t hey occurred at t he originat ing sit es. However, Oracle guarant ees t hat parallel st ream s of t ransact ions are ort hogonal—t hat is, t hey are independent of one anot her.

Bat ch act ivit y, on t he ot her hand, is not quit e as sim ple. Suppose, for exam ple, t hat t he ORDERS and ORDER_I TEMS t ables were im plem ent ed as snapshot s at a rem ot e sit e t hat refreshes t he snapshot s once per day. We want t his sit e t o have a consist ent represent at ion of t he dat a at all t im es; t hat m eans t hat we cannot sim ply refresh t he ORDERS t able and t hen t he ORDER_I TEMS t able, because during t he t im e t he ORDER_I TEMS t able refreshes, t he ORDERS t able will have num erous it em less orders. And, of course, t he ORDER_I TEMS t able cannot be refreshed first because we would t hen have orphaned it em s. Oracle's solut ion t o t his dilem m a is t he snapshot group. A snapshot group is a collect ion of t wo or m ore t ables t hat m ust be refreshed as a single t ransact ion. All t ables are refreshed wit h a represent at ion of t he m ast er dat a at a single point in t im e. Refer t o Chapt er 11, for specifics about creat ing and using snapshot groups.

8 .3 .2 Sch e m a D iffe r e n ce s a n d Pa r t it ion in g I n a nonreplicat ed dist ribut ed dat abase, dat a m ay be fragm ent ed vert ically, and t ables m ay be defined slight ly different ly at different sit es. I n a replicat ed environm ent , you sacrifice a cert ain am ount of flexibilit y. A t able t hat part icipat es in peer- t o- peer replicat ion m ust have t he sam e shape ( i.e., colum ns) at all locat ions. Whenever you add or drop a colum n, you m ust quiesce t he replicat ion group and use t he Oracle built - in package procedure DBMS_REPCAT.ALTER_MASTER_REPOBJECT t o change t he t able at all m ast er sit es.

The DBMS_REPCAT.ALTER_MASTER_REPOBJECT procedure can perform only st andard DDL such as widening or adding fields. I f you want t o drop a colum n, you m ust creat e a new t able wit hout t he colum n you are dropping, populat e t he new t able, and add it t o t he replicat ion group.

187

Oracle Distributed Systems Unlike vert ical part it ioning, horizont al part it ioning is fairly st raight forward in a replicat ed environm ent . I f you wish t o divide a t able so t hat a WHERE clause dict at es whet her records appear at specific sit es, you can use updat eable snapshot s t o bring about t his part it ioning. For exam ple, a ret ailer m ay use updat eable snapshot s t o t rack sales t ransact ions at it s various locat ions. Horizont al part it ioning can also be of t rem endous use in an applicat ion t hat is designed t o balance workload for t he purpose of scalabilit y. Consider an I nt ernet " port al" sit e t hat allows users t o personalize t heir view of t he web page by specifying st ocks in t heir port folio, sport s t eam s t hey t rack, weat her report s t hey want , and so on. I f t he schem a is designed so t hat t he t ables cont aining t his personalized dat a can be part it ioned by usernam e, for exam ple, t hen t he applicat ion can direct users t o specific dat abases in t he replicat ed environm ent based on t heir user I D. I n order t o t ake advant age of scalabilit y t hrough horizont al part it ioning, t he applicat ion should be able t o direct users, or t raffic, t o a part icular dat abase based on an ident ifying key. Horizont al part it ioning is highly desirable because it helps t o avoid conflict s. I t also gives you t he opt ion t o use updat eable snapshot s or m ult im ast er replicat ion; updat eable snapshot s can t ake advant age of part it ioning, but m ast er t ables m ust be replicat ed in t heir ent iret y. Obviously, all t ables t hat are t o be horizont ally part it ioned m ust cont ain t he part it ion key. The lat t er requirem ent generally im plies denorm alizat ion of t he schem a. Since every t able in t he replicat ed schem a m ust cont ain t he part it ion key, norm alizat ions t hat would be highly desirable under norm al circum st ances are not reasonable. For exam ple, consider what would be involved in part it ioning an order ent ry applicat ion. I f we part it ion t ables based on CUSTOMER_I D, t hen t his field would have t o be in not only t he CUSTOMERS and ORDERS t ables but also t he ORDER_I TEMS t able, which is highly unnat ural. I f you find yourself having t o denorm alize your schem a in absurd ways, you are probably bet t er off eit her choosing a different part it ion key or sim ply using m ult im ast er replicat ion ( and placing all dat a at all sit es) inst ead. I f you elect t o use m ult im ast er replicat ion, you should st ill direct your applicat ion t o use different dat abases for different subset s of dat a.

8 .3 .3 Row - Le ve l Re plica t ion or Pr oce du r a l Re plica t ion ? Oracle's advanced replicat ion facilit y support srow- level replicat ion and procedural replicat ion. Row- level replicat ion is t ransact ion based; DML t hat is applied against a t able is forwarded t o ot her sit es and applied. Every t ransact ion creat es a deferred call. Procedural replicat ion, on t he ot her hand, replicat es calls t o PL/ SQL packaged procedures and funct ions. For OLTP workloads, row- level replicat ion m akes t he m ost sense; t here is no real need or benefit t o writ ing PL/ SQL packages t o perform all of an applicat ion's DML. Furt herm ore, row- level replicat ion offers conflict resolut ion, whereas procedural replicat ion does not .

188

Oracle Distributed Systems So why would one ever want t o use procedural replicat ion? Operat ions t hat updat e large num bers of records do not replicat e well wit h t ransact ion- based replicat ion, for a variet y of reasons: • • •

Field values m ust be sent t o all part icipat ing m ast er sit es. I n Oracle7, bot h old and new colum n values m ust be sent for every colum n in t he t able, not j ust t he changed colum ns. This can lead t o quit e a st rain on t he net work. Large replicat ed t ransact ions require t rem endously large rollback segm ent s. Rollback segm ent s are required not only for t he t able being m odified but also for t he dat a dict ionary t ables t hat cont rol replicat ion. Conflict resolut ion is ext rem ely expensive for large t ransact ions. I f a conflict arises, and you have resolut ion m et hods defined t o handle it , t he t im e required t o process t he conflict can easily exceed t he t im e required t o sim ply re- creat e t he t able.

None of t hese considerat ions is an issue wit h procedural replicat ion. The only dat a t hat propagat es t o t he part icipat ing sit es is t he PL/ SQL call it self. Oracle execut es t he call at each dat abase, requiring lit t le m ore overhead t han a nonreplicat ed procedure call uses. Since procedural replicat ion does not ut ilize conflict resolut ion m et hods, no addit ional t im e or resources are required t o process conflict s. Of course, t he applicat ion developers have t he responsibilit y of ensuring t hat t he replicat ed procedures do not int roduce conflict s and t hat t hey can handle dat a anom alies. Anot her advant age t hat procedural replicat ion has over row- level replicat ion is t hat procedures can be localized. That is, t hey can be slight ly different at different locat ions. This flexibilit y can be useful if business rules differ at various sit es. For exam ple, a price increase m ay t rigger different cust om er discount s in different regions. ( Again, developers and designers m ust ensure t hat any regional differences do not result in inconsist ent dat a.) Procedural replicat ion is described in great er det ail in Chapt er 14.

8 .3 .4 Pr im a r y Ke ys a n d Un iqu e I n de x e s Every replicat ed t able m ust have eit her a prim ary key or a unique index. A prim ary key is preferable. The reason for t his requirem ent should be clear; every record m ust be uniquely ident ifiable so t hat changes t o t he record can be propagat ed t o t he corresponding record in t he rem ot e dat abases. ROWI Ds are not an opt ion for uniquely ident ifying records because t hey cont ain inform at ion about t he physical locat ion of a record and are not ident ical across m ult iple dat abases. As I 've said, prim ary keys are preferable t o unique indexes; in addit ion, a single- field key is preferable t o a m ult ivalued key. The problem wit h unique indexes is t hat t he replicat ion facilit y does not aut om at ically recognize t hem . I f you have a t able wit h a unique index but not a prim ary key, you have t o use t he DBMS_REPCAT.SET_COLUMNS procedure t o coerce Oracle int o using t he index t o ident ify records. Also, if you wish t o use prim ary key snapshot s ( available in Oracle8) , t he m ast er t able m ust have a prim ary key. The replicat ion soft ware assum es t hat m ast er t ables have prim ary keys. Prim ary keys should consist of a single colum n, preferably a num eric colum n. Whenever Oracle has t o locat e a row, which occurs quit e frequent ly wit h row- level

189

Oracle Distributed Systems replicat ion, t he t ask should be as fast as possible; using a single- field prim ary key helps t he overall perform ance of t he replicat ion funct ions. The prim ary advant age t o using num eric fields over VARCHARs for prim ary keys is t hat indexes on num eric colum ns are generally m uch sm aller t han t hose on VARCHARs.

8 .3 .5 For e ign Ke ys a n d Re fe r e n t ia l I n t e gr it y As st at ed elsewhere, Oracle's advanced replicat ion facilit y preserves t he order of t ransact ions, so if a t ransact ion creat es records t hat respect a m ast er- child relat ionship at t he originat ing sit e, t he relat ionship will be preserved at t he sit es t o which t he t ransact ion propagat es. For exam ple, if an order ent ry applicat ion creat es a record in t he ORDERS t able and m ult iple line it em s in t he ORDER_I TEMS t able eit her in a single t ransact ion or in a series of t ransact ions, Oracle will propagat e t he insert s in t he sam e order. Therefore, foreign key const raint s are support able and even advisable in a replicat ed environm ent . Also, unlike Oracle7, which did not allow prim ary keys or unique indexes on snapshot base t ables, Oracle8 does support t hese const raint s. I n fact , Oracle8 can even creat e a prim ary key on snapshot base t ables aut om at ically, as described earlier in Sect ion 8.1.1.

Alt hough foreign key const raint s are safe t o use in a replicat ed environm ent , it is not pract ical t o use t he ON DELETE CASCADE form . Foreign keys defined wit h cascading delet es aut om at ically delet e child records whenever a record is delet ed from t he parent t able. I f bot h t he parent and child t ables are replicat ed and if t he const raint is defined as a cascading delet e at all m ast er sit es, t hen delet es will be at t em pt ed t wice against child t ables: once because of t he int egrit y const raint and once because of t he replicat ed delet e from t he originat ing sit e.

8 .3 .6 Tr igge r s on Re plica t e d Ta ble s I f your applicat ion uses t riggers, m ake sure t hat t he t riggers do not int erfere wit h replicat ion funct ionalit y. For exam ple, if you use audit ing t riggers t hat populat e usernam e and t im est am p fields when a record is creat ed or delet ed, t he t rigger should fire at t he sit e where t he DML originat ed but not at t he sit es t o which t he DML is propagat ed. Oracle provides a built - in funct ion called DBMS_REPUTI L.FROM_REMOTE, which you can use in your t rigger body t o det erm ine whet her t o do anyt hing. CREATE OR REPLACE TRIGGER t_iu_orders BEFORE INSERT OR UPDATE ON orders FOR EACH ROW

190

Oracle Distributed Systems

BEGIN IF (dbms_reputil.from_remote != TRUE) THEN :new.username := USER; :new.rectime := SYSDATE; :new.site := DBMS_REPUTIL.GLOBAL_NAME; END IF; END; / Not e t hat t his is a before- row t rigger. All of Oracle's replicat ion t riggers are aft er- row t riggers. Since it is not possible t o cont rol t he firing order of t riggers of t he sam e t ype, it is best t o guarant ee t hat your own t riggers fire before t he replicat ion t riggers by m aking t hem before- row t riggers. This way, your t riggers will not int erfere wit h replicat ion funct ionalit y. Make sure t hat t riggers t hat m odify dat a fire only for t he original t ransact ion, not for propagat ed t ransact ions.

8 .3 .7 D a t a t ype s Oracle doesnot replicat e LONG or LONG RAW dat at ypes. You can st ill replicat e a t able t hat has LONG or LONG RAW colum ns, but changes t o t he values in such colum ns are not propagat ed. Oracle8 addresses t his lim it at ion by support ing replicat ion of CLOB ( charact er large obj ect ) and BLOB ( binary large obj ect ) dat at ypes. Nevert heless, applicat ions should perform m inim al updat es t o t hese dat at ypes in a replicat ed environm ent because of t he im pact t his can have on t he net work. I n fact , Oracle8 also includes a feat ure called m inim um com m unicat ion, which allows you t o specify t he colum ns whose values are t o be sent t o rem ot e sit es when updat es are propagat ed. I f you know t hat t he applicat ion never updat es CLOB or BLOB colum ns, you do not need t o send t heir values when updat es propagat e. See Chapt er 12, for det ails on how t o t ake advant age of m inim um com m unicat ion. I f your applicat ion does allow for updat es t o CLOB and BLOB dat a, you should t ry t o part it ion dat a vert ically so t hat t hese fields are in t ables t hat cont ain only t he CLOB or BLOB dat a and a prim ary key: SQL> desc catalog_photos Name ------------------------catalog_photo_id photo

Null? -------NOT NULL NOT NULL

Type ---NUMBER(12) BLOB

Oracle8 also int roduced user- defined dat at ypes. Regret t ably, user- defined dat at ypes do not replicat e. The current recom m endat ion is t o creat e t ables wit h t he obj ect s' underlying dat at ypes.

8 .3 .8 Tim e Am ong t he m ost com m on and easy t o use m et hods of conflict resolut ion are Lat est Tim est am p and Earliest Tim est am p. To ut ilize t hese fields, replicat ed t ables should have a t im est am p field and a before- row t rigger t o populat e it on every insert and updat e. For t his field t o be effect ive, t he syst em clocks on t he m achines host ing t he replicat ed dat abases m ust be synchronized. Synchronizat ion is part icularly im port ant

191

Oracle Distributed Systems for applicat ions t hat perform a high rat e of t ransact ions, especially if t hese t ransact ions are not part it ioned t o avoid conflict s. The t im e zone of each dat abase server m achine m ay also be an issue. For exam ple, if you have m achines in New York and California and have defined Lat est Tim est am p conflict resolut ion, t hen t he t ransact ions originat ing at t he New York sit e will prevail in m ost conflict s since New York is t hree hours ahead of California. To avoid t im e zone biases, you can eit her st andardize your m achines t o a single t im e zone, such as Greenwich Mean Tim e ( GMT) , or adj ust t he value of t he t im est am p when you populat e t he field. The form er st rat egy is m uch sim pler but m ay cause confusion and com plicat ions if t he applicat ion present s t im e- sensit ive dat a t o t he user, such as a t im e and at t endance syst em or a st ock quot e server. Fut ure versions of Oracle are expect ed t o include a t im est am p com ponent in t he DATE dat at ype, which will sim plify t im e zone anom alies significant ly. Current ly, Oracle references t he com put er's syst em clock t o det erm ine t he t im e but does not consider t he t im e zone.

8 .3 .9 Se qu e n ce s Oracle's advanced replicat ion facilit y does not replicat e sequences, which are oft en used t o generat e prim ary key values and ot her num eric keys. Because of t his lim it at ion, applicat ions t hat use sequences can reference a single sequence which is locat ed at a m ast er sit e, can use t heir own local sequence, or can use a m ult icolum n prim ary key. Each of t hese st rat egies has it s advant ages and disadvant ages.

8 .3 .9 .1 Usin g a sin gle se qu e nce a t a m a st e r sit e I f you elect t o allow all dat abases t o reference a single sequence in a rem ot e sit e, you are ensured t hat t he ordering of t he num eric key in t he dat abases represent s t he order in which t ransact ions occurred. As an exam ple, a single m ast er sequence could be creat ed for an order ent ry applicat ion t hat is replicat ed across m ult iple sit es: CREATE PUBLIC SYNONYM seq_order_num FOR [email protected] The ORDERS t able would t hen have a before- row t rigger t o populat e t he ORDER_NUMBER field ( as well as t he ot her fields used for audit ing and conflict avoidance) . CREATE OR REPLACE TRIGGER t_iu_orders BEFORE INSERT OR UPDATE ON orders FOR EACH ROW BEGIN IF (dbms_reputil.from_remote != TRUE) THEN :new.order_numbers := seq_order_num.next_val; :new.username := USER; :new.rectime := SYSDATE; :new.site := DBMS_REPUTIL.GLOBAL_NAME; END IF; END;

192

Oracle Distributed Systems Thus, t he ordering of ORDER_NUMBERs will be sequent ial for all orders ent ered at all sit es. The glaring disadvant age of t his approach is t he dependency on a single sit e. Not only m ust t he rem ot e dat abase be available in order for new orders t o be generat ed, but it m ust also have t he capacit y t o support t he connect ions and sequence request s from all users of t he applicat ion. These risks are t oo high for m ost product ion applicat ions.

8 .3 .9 .2 Alloca t in g se qu e n ce r a n ge s t o sit e s An alt ernat ive is t o use a local sequence in all dat abases in which t he applicat ion runs. Wit h a local sequence, t he applicat ion can funct ion independent ly from all ot her m ast er sit es. However, t he sequences m ust be creat ed so t hat t hey never collide— t hat is, dist inct ranges of sequence num bers m ust be allocat ed t o each sit e. You can accom plish t his sequence part it ioning sim ply by creat ing t he sequences wit h different st art ing num bers, as follows: Headquart ers: CREATE SEQUENCE seq_order_num START WITH 1; New York sit e: CREATE SEQUENCE seq_order_num START WITH 100000000000; California sit e: CREATE SEQUENCE seq_order_num START WITH 200000000000; I t is a good idea t o leave room for plent y of ent ries at each sit e; t he preceding exam ple allocat es one hundred billion sequence num bers per sit e, which can support m ore t han 300 new orders per second for 10 years. Running out of num bers is t o be avoided at all cost s; calculat e your peak rat e of record insert ion and allocat e enough sequence num bers t o support 100 t im es t hat rat e cont inuously for 30 years. ( By t hen you probably won't care if it runs out of sequence num bers! ) The only disadvant ages t o allocat ed sequence ranges t o sit es is t he loss of cont inuit y in key values across t he part icipat ing dat abases. Aggregat e report s t hat sort by t he key value will not be sort ed by t he order in which records were creat ed. Of course, som e people would find it advant ageous t o be able t o ident ify where records were creat ed j ust by referencing t he prim ary key.

8 .3 .9 .3 Using a m ult icolu m n pr im a r y k e y Finally, if neit her of t he previously described st rat egies is accept able, t he applicat ion m ay use t wo fields as t he prim ary key for replicat ed t ables. Typically, one of t hese fields would be t he sequence num ber, as in t he previous exam ples, and t he second

193

Oracle Distributed Systems field would be a sit e ident ifier. For exam ple, t he ORDERS t able would have it s prim ary key defined as follows: ALTER TABLE orders ADD ( CONSTRAINT pk_orders PRIMARY KET (order_num, site_num) ); The applicat ion would st ill use local sequences, but t he sequence num bers could all st art wit h t he sam e value. The advant age of t his m et hod is t hat it s prim ary key values are not art ificially associat ed wit h sit es, and t here is no danger of running out of sequence num bers at any sit e. I n addit ion, new sit es are sim ple t o add. The disadvant age is t hat m ult icolum ned prim ary keys incur addit ional overhead in t he replicat ion int ernals, and perform ance will be affect ed.

8 .3 .1 0 M u lt iple Ch a r a ct e r Se t s I f your applicat ion support s m ult iple charact er set s, you m ust ensure t hat each dat abase part icipat ing in t he replicat ed environm ent is creat ed wit h a com pat ible charact er set . I f m ult iple charact er set s are involved, Oracle recom m ends t he use of t he UNI CODE charact er set : AL24UTFFSS for Oracle7 dat abases and AL24UTFFSS or UTF8 for Oracle8 dat abases, because t hese support all m appings. SQL* Net and Net 8 perform charact er set conversions; t here is not hing specific t o replicat ion t hat m ust be done.

194

Oracle Distributed Systems

Pa r t I I : Re plica t ion Part I I describes t he det ails of Oracle's various dist ribut ed syst em product s; it cont ains t he following chapt ers: • •

•

• •

•

•

Chapt er 9, t akes a deeper look at Oracle's replicat ion archit ect ure; it exam ines t he various t ypes of replicat ion available t hrough Oracle, specific archit ect ural com ponent s, inst allat ion t ips, and enhancem ent s for Oracle8 and Oracle8i. Chapt er 10, describes how t o set up an advanced replicat ion environm ent , including t he set t ing of init ializat ion param et ers, t he select ion of redo logs and rollback segm ent s, t he size and placem ent of dat a dict ionary obj ect s, and t he use of adm inist rat ive account s, privileges, and dat abase links. Chapt er 11, is a det ailed analysis of Oracle's basic replicat ion ( snapshot ) facilit y. Chapt er 12, is a det ailed analysis of Oracle's m ult i- m ast er replicat ion facilit y. Chapt er 13, is a det ailed analysis of Oracle's updat eable snapshot facilit y. Chapt er 14, is a det ailed analysis of Oracle's procedural replicat ion facilit y. Chapt er 15, describes a variet y of t echniques for avoiding conflict s am ong t he various dist ribut ed sit es where dat a is replicat ed.

195

Oracle Distributed Systems

196

Oracle Distributed Systems

Ch a pt e r 9 . Or a cle Re plica t ion Ar ch it e ct u r e I f you're going t o realize t he full pot ent ial of Oracle's advanced replicat ion facilit ies and sim ult aneously avoid t he pit falls, you need t o underst and t he archit ect ure on which t hey are based. I f you are new t o replicat ion or a bit unclear about how t he com ponent s work t oget her, t his chapt er is for you. The following chapt ers assum e an underst anding of t he concept s discussed here.

9 .1 W h a t I s Or a cle Re plica t ion? Let 's begin wit h a few sim ple concept s. Oracle's replicat ion facilit y is a collect ion of t ables, PL/ SQL packages, and background processes t hat can aut om at ically replicat e dat a or procedure calls from one dat abase t o one or m ore ot her dat abases. Oracle's replicat ion is built in t o t he dat abase it self; it is not a separat e applicat ion or ut ilit y like export and im port . Depending on t he configurat ion, dat a can be m odified at all sit es, or one sit e can be t he sole writ er while ot her sit es receive read- only copies of t he dat a. The funct ionalit y can accom m odat e a wide variet y of business requirem ent s. These include: • • • •

High availabilit y Scalabilit y Rem ot e dat a deploym ent Dat a ext ract ion and consolidat ion

We'll exam ine t he det ails of im plem ent ing t hese solut ions in lat er chapt ers. Not e t hat replicat ing dat a is fundam ent ally different from dist ribut ing dat a. When dat a is dist ribut ed, it m ay be accessed t ransparent ly from m ult iple locat ions, but a given t able exist s in only one locat ion, and t hat locat ion is responsible for it s securit y and int egrit y. Replicat ed dat a, on t he ot her hand, resides at m ult iple locat ions, each of which shares in it s m aint enance. Dat a replicat ion im plies an increased level of com plexit y because it int roduces issues such as dat a synchronizat ion and lat ency. This com plexit y is t he price t o pay for cont inuous operat ions when a rem ot e dat a source is unavailable.

9 .2 Type s of Re plica t ion No single replicat ion m et hodology can m eet all of t he various business requirem ent s list ed earlier. Oracle's four basic t ypes of replicat ion are described in Table 9.1.

Table 9.1. Types of Replication Replication Type Read- only snapshot s

Description A m ast er t able is copied t o one or m ore dat abases. Changes in t he m ast er t able are reflect ed in t he snapshot t ables whenever t he snapshot refreshes. The snapshot

Example A com pany m ay m aint ain it s m ast er product price list in a t able at headquart ers; regional sales offices or ret ail sit es each have a snapshot of t he price list in t heir local

197

Oracle Distributed Systems

sit e det erm ines t he frequency of t he refreshes; dat a is pulled. Sim ilar t o read- only snapshot s, except t hat t he snapshot sit es are able t o m odify t he dat a and send Updat eable t heir changes back t o t he m ast er. snapshot s The snapshot sit e det erm ines t he frequency of t he refreshes and t he frequency wit h which updat es are sent back t o t he m ast er.

dat abases. A t able of cust om er leads resides at headquart ers. Sales st aff wit h lapt op com put ers visit prospect ive client s and ent er not es about t heir m eet ings. When t he sales st aff dials in t o t he headquart ers dat abase every evening, t heir not es are uploaded, and t hey receive any updat es t hat m ay have occurred since t heir last dat a refresh.

Mult im ast er replicat ion

A t able is copied t o one or m ore dat abases, and each dat abase has t he abilit y t o insert , updat e, or delet e records from it . Modificat ions are pushed t o t he ot her dat abase at an int erval t hat t he DBA set s for each replicat ion group. The highest t heoret ical frequency is once per second.

Procedural replicat ion

A procedure call applies a discount of A call t o a packaged procedure or 10% t o all orders over US$500 by funct ion is replicat ed t o one or updat ing t he ORDERS t able in a m ore dat abases. replicat ed order ent ry syst em .

A com pany achieves scalabilit y and high availabilit y by running it s order ent ry syst em on t wo dat abase inst ances; orders and invent ory are m odified on bot h m achines.

As you can see, t hese m odes of replicat ion are quit e different , and each is suit ed for specific kinds of uses. A single environm ent can ut ilize all of t hese m et hods; t hey are not m ut ually exclusive.

9 .3 Ar ch it e ct u r e Com pon e n t s Oracle has built t he replicat ion facilit y on a variet y of t riggers, packages, background processes, j obs, and t ables, all working in concert t o deliver dat a t o m ult iple sit es as if by m agic. I f you are t he DBA for a replicat ed environm ent , you m ust underst and t he secret s behind t his m agic. Read on.

9 .3 .1 Th e Qu e u e s Queues are t he foundat ion of t he replicat ion archit ect ure. DML and DDL changes are ent ered int o t hese queues, from which t hey are propagat ed t o rem ot e sit es. Table 9.2 sum m arizes t he queues.

Table 9.2. Replication Queues Queue Name Deferred t ransact ion

Relevant Data Dictionary Views Prim ary:

Description Local t ransact ions t hat are t o be replicat ed t o rem ot e sit es are enqueued in t o deft rans. A

198

Oracle Distributed Systems

( a.k.a. deft rans)

DEFTRAN Ot her:

t rigger on t he replicat ed t able t able_nam e $RT insert s t hese ent ries. Not e t hat in Oracle8 t his t rigger is int ernalized and is t herefore not visible in t he dat a dict ionary.

DEFTRANDEST DEFERRCOUNT DEFERROR Prim ary: Replicat ion call ( a.k.a. defcall)

DEFCALL Ot her:

Rem ot e procedure calls are enqueued int o t he DEFCALL view. I n t he case of a replicat ed t able, t here is one ent ry for each row t hat is changed.

DEFCALLDEST Replicat ion cat alog ( a.k.a. repcat log)

DBA_REPCAT

DDL m odificat ions t o replicat ed obj ect s as well as adm inist rat ive t asks such as changing t o t he propagat ion m ode are t racked in DBA_REPCAT. This view also cont ains inform at ion about errors t hat m ay have occurred when perform ing t hese t asks.

The j ob queue cont rols scheduled j obs t hat run at user- defined int ervals. For replicat ion, t hese are recurring calls t o t he DBMS_REPCAT DBA_JOBS procedures t hat process ent ries in deft rans, defcall, and repcat log and t hat refresh Ot her: snapshot s. Not e t hat t he j ob queue can schedule calls t o any package procedure; it s DEFSCHEDULE use is not rest rict ed t o replicat ion- relat ed DBA_JOBS_RUNNI NG act ivit y. Prim ary:

Job

I n t he case of synchronous m ult i- m ast er replicat ion, DML act ivit y is not queued. Changes are delivered t o all sit es sim ult aneously using a t wo- phase com m it prot ocol.

The next st ep t o underst anding t he replicat ion archit ect ure is underst anding t he m echanism s Oracle uses t o add and rem ove ent ries from t hese queues. As you would probably guess, it 's done wit h t riggers and packaged procedures.

9 .3 .2 Th e Tr igge r s a n d Pa ck a ge s Whet her you are using snapshot s, asynchronous row- level replicat ion, or procedural replicat ion, you are using som e com binat ion of queues, t riggers, and packages. This sect ion exam ines t he precise m echanism s behind all of t he preceding replicat ion m et hods. I n each case, we use an exam ple t able, called I SO_COUNTRI ES, t o illust rat e t he sequence of event s t hat replicat es an updat e t o t he t able. The I SO_COUNTRI ES t able is defined as follows:

199

Oracle Distributed Systems SQL> desc iso_countries Name Null? ------------------COUNTRY_ID NOT NULL ISO_CODE NOT NULL ISO_NAME NOT NULL AUDIT_DATE NOT NULL AUDIT_USER NOT NULL GLOBAL_NAME NOT NULL

Type -------------NUMBER(6) VARCHAR2(2) VARCHAR2(50) DATE VARCHAR2(30) VARCHAR2(20)

The prim ary key of t he I SO_COUNTRI ES t able is COUNTRY_I D.

9 .3 .2 .1 The r e a d- only sn a psh ot m e ch a n ism The sim plest m eans of replicat ion is t he read- only snapshot , which is essent ially a t able at t he snapshot sit e t hat holds t he result s of a rem ot e query. This t able is refreshed at an int erval t hat is det erm ined when t he snapshot is creat ed and t hat can be m odified wit hout re- creat ing t he snapshot . Read- only snapshot s can be creat ed in such a way t hat t he refreshes have t o updat e only records t hat have been m odified since t he last refresh. This opt im izat ion is called a fast refresh. I n order t o use a fast refresh, t he m ast er t able m ust keep t rack of which records have changed since t he last refresh. This bookkeeping happens aut om at ically if you creat e a snapshot log on t he m ast er t able. I f you do not creat e a snapshot log on t he m ast er t able, t hen every snapshot will be a com plet e refresh, which m eans t hat t he snapshot t able is com plet ely repopulat ed. Obviously t his is undesirable, part icularly for large snapshot s. To creat e a snapshot log on t he I SO_COUNTRI ES t able, we issue t he following st at em ent : CREATE SNAPSHOT LOG ON iso_countries WITH PRIMARY KEY TABLESPACE sprocket_data STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0)

The preceding CREATE SNAPSHOT LOG st at em ent uses t he WI TH PRI MARY KEY opt ion, which is new wit h Oracle8. I n Oracle7, changed records are t racked in t he snapshot log by t heir ROWI D. Oracle8 gives you t he choice of building t he snapshot log- based on prim ary key or ROWI D.

The snapshot log on t he I SO_COUNTRI ES t able looks like t his: SQL> desc SPROCKET.mlog$_iso_countries Name Null? Type -------------------------COUNTRY_ID NUMBER(6) SNAPTIME$$ DATE DMLTYPE$$ VARCHAR2(1) OLD_NEW$$ VARCHAR2(1)

200

Oracle Distributed Systems CHANGE_VECTOR$$

RAW(255)

Oracle also creat es an aft er- row t rigger on t he I SO_COUNTRI ES t able t hat populat es t he snapshot log aft er every insert , updat e, and delet e. I n Oracle8, t he t rigger is int ernalized, so it is not visible in t he dat a dict ionary. I n an Oracle7 dat abase, however, we can see t he t ext of t he t rigger, nam ed TLOG$_I SO_COUNTRI ES: DECLARE dmltype CHAR; BEGIN IF inserting then dmltype := 'I'; ELSIF updating then dmltype := 'U'; ELSIF deleting then dmltype := 'D'; END IF; INSERT INTO "SPROCKET"."MLOG$_ISO_COUNTRIES" (m_row$$, dmltype$$) VALUES (:old.rowid, dmltype); END;

The Oracle7 version of t he MLOG$_I SO_COUNTRI ES t able ident ifies row s by t heir ROWI D inst ead of by prim ary key and does not have t he fields OLD_NEW$$ or CHANGE_VECTOR$$.

So far, we have only described t he m ast er sit e's archit ect ure. What happens at t he snapshot sit e when we creat e a snapshot ? CREATE SNAPSHOT iso_countries REFRESH FAST START WITH SYSDATE NEXT SYSDATE+10/1440 WITH PRIMARY KEY AS SELECT country_id, iso_code, iso_name, audit_date, audit_user, global_name FROM [email protected]; This CREATE SNAPSHOT st at em ent creat es a t able at t he snapshot sit e nam ed SNAP$_I SO_COUNTRI ES, which cont ains all colum ns of t he m ast er I SO_COUNTRI ES t able. I f we use t he Oracle8 WI TH PRI MARY KEY synt ax, t he snapshot t able has exact ly t he sam e colum ns as t he m ast er t able. I n Oracle7, or if we use t he WI TH ROWI D synt ax in Oracle8, t he snapshot will have an ext ra colum n, M_ROW$$, which cont ains t he ROWI D corresponding t o t he record in t he m ast er dat abase. The CREATE SNAPSHOT st at em ent also creat es a view, nam ed I SO_COUNTRI ES. This view is defined as a query on t he SNAP$_I SO_COUNTRI ES t able, which ret urns exact ly t he fields in t he m ast er t able.

201

Oracle Distributed Systems Finally, t he CREATE SNAPSHOT st at em ent also schedules a j ob in t he j ob queue t o refresh t he snapshot . This j ob is a call t o DBMS_REFRESH, and it is scheduled t o recur at t he frequency specified by t he NEXT clause in t he CREATE SNAPSHOT st at em ent . Table 9.3 sum m arizes t he obj ect s Oracle creat es t o support read- only snapshot s.

Table 9.3. Objects Created to Support Read-Only Snapshots Site

DDL Statement

Objects Created Table MLOG$_m ast er_t able_nam e

Mast er sit e

CREATE Trigger TLOG$_m ast er_t able_nam e SNAPSHOT LOG ( Not e t hat t he TLOG$ t rigger is int ernalized in Oracle8 and not visible in t he dat a dict ionary.) Table SNAP$_m ast er_t able_nam e View MLOG$_m ast er_t able_nam e ( Oracle7 only)

Snapshot sit e

CREATE SNAPSHOT

I ndex PK_m ast er_t able_nam e ( Oracle8 only) View m ast er_t able_nam e Scheduled j ob t o call DBMS_REFRESH

Figure 9.1 illust rat es how t hese com ponent s work t oget her.

Figu r e 9 .1 . H ow r e a d- on ly sn a psh ot s w or k

202

Oracle Distributed Systems

At t he m ast er sit e, we see t he TLOG$ t rigger firing t o populat e t he MLOG$ t able when DML is applied t o t he m ast er t able. At t he snapshot sit e, we see t he SNAP$ t able, and t he call t o DBMS_REFRESH which reexecut es t he snapshot 's defining query at a specified int erval.

9 .3 .2 .2 The upda t e a ble sn a psh ot m e cha n ism Updat eable snapshot s perm it DML at t he snapshot sit es and propagat e DML changes from t he snapshot t able back t o t he m ast er t able. The archit ect ure of updat eable snapshot s is quit e sim ilar t o t hat of read- only snapshot s. The prim ary archit ect ural differences are t he following: •

•

Updat eable snapshot sit es m aint ain a t able analogous t o t he m ast er sit e's MLOG$ t able, populat ed by a t rigger analogous t o t he m ast er sit es TLOG$ t rigger. The updat eable snapshot log t able is nam ed USLOG$_m ast er_t able_nam e and t he t rigger is nam ed USTRG$_m ast er_t able_nam e. As wit h t he TLOG$ t rigger, t he USTRG$ t rigger is int ernalized in Oracle8 and t herefore is not visible in t he dat a dict ionary. Updat eable snapshot sit es use a t rigger t o post deferred RPCs t hat send DML changes t o t he m ast er sit e.

Unlike read- only snapshot s, updat ebable snapshot s require t hat advanced replicat ion be inst alled and configured.

203

Oracle Distributed Systems

How do t hese addit ional obj ect s propagat e updat es at t he snapshot sit e t o t he m ast er sit e? Let us again consider our I SO_COUNTRI ES t able. We can creat e an updat eable snapshot of t his t able as follows: CREATE SNAPSHOT iso_countries REFRESH FAST START WITH SYSDATE NEXT SYSDATE+10/1440 WITH PRIMARY KEY FOR UPDATE AS SELECT country_id, iso_code, iso_name, audit_date, audit_user, global_name FROM [email protected]; Again, t he WI TH PRI MARY KEY synt ax is unique t o Oracle8. When you creat e a snapshot wit h t he FOR UPDATE clause and m ake t he appropriat e calls t o t he replicat ion packages t hat creat e t he support ing obj ect s for t he updat eable snapshot , you end up wit h t he following obj ect s. Unless ot herwise not ed, t hese obj ect s reside at t he snapshot sit e: Table SNAP$_I SO_COUNTRI ES Cont ains t he result s of t he query t hat defines t he snapshot , plus a field M_ROW$$ if t he snapshot sit e is an Oracle7 dat abase or if t he WI TH ROWI D synt ax is used in an Oracle8 dat abase. Table USLOG$_I SO_COUNTRI ES Capt ures inform at ion about rows t hat have been changed; Oracle uses t his inform at ion t o updat e t he m ast er t able. Trigger USTRG$_I SO_COUNTRI ES on t able SNAP$_I SO_COUNTRI ES Populat es t he USLOG$_I SO_COUNTRI ES t able; visible in Oracle7 only; int ernalized in Oracle8. Trigger I SO_COUNTRI ES$RT on t able SNAP$_I SO_COUNTRI ES Makes calls t o I SO_COUNTRI ES$TP; visible in Oracle7 only; int ernalized in Oracle8. Package I SO_COUNTRI ES$TP Builds deferred RPCs, which call I SO_COUNTRI ES$RP at t he m ast er sit e; visible in Oracle7 only; int ernalized in Oracle8.

204

Oracle Distributed Systems Package I SO_COUNTRI ES$RP Perform s DML on t he m ast er t able. Package I SO_COUNTRI ES$RR Defined only at t he m ast er sit e. This package cont ains rout ines used for conflict resolut ion. Oracle creat es only t he package at t he snapshot sit e; at t he m ast er sit e Oracle creat es bot h t he package and t he package body. View I SO_COUNTRI ES View defined on t he SNAP$_I SO_COUNTRI ES t able, which cont ains all colum ns except for t he M_ROW$$ colum n. Ent ry in j ob queue t hat calls DBMS_REFRESH DBMS_REFRESH refreshes t he snapshot and pushes DML changes back t o t he m ast er. The USLOG$_I SO_COUNTRI ES t able looks like t he following: Oracle7: SQL> desc uslog$_iso_countries Name Null? Type ---------------------------M_ROW$$ VARCHAR2(255) SNAPTIME$$ DATE DMLTYPE$$ VARCHAR2(1) Oracle8: SQL> desc uslog$_iso_countries Name Null? Type ---------------------------COUNTRY_ID NUMBER(6) SNAPTIME$$ DATE DMLTYPE$$ VARCHAR2(1) OLD_NEW$$ VARCHAR2(1) As is t he case wit h t he MLOG$ t ables at t he m ast er sit e, t he prim ary difference bet ween t he Oracle7 and Oracle8 versions of t he USLOG$ t able is t hat Oracle8 ident ifies rows by prim ary key value, whereas Oracle7 ident ifies t hem by ROWI D. The t riggers USTRG$_I SO_COUNTRI ES and I SO_COUNTRI ES$RT are visible only in t he Oracle7 dat a dict ionary because t he Oracle8 version of t he t rigger is int ernalized but logically sim ilar. The Oracle7 t riggers are defined as follows. Trigger USTRG$_I SO_COUNTRI ES:

205

Oracle Distributed Systems declare dmltype char; begin if not dbms_snapshot.I_am_a_refresh then if updatingthen dmltype := 'U'; elsif deletingthen dmltype := 'D'; end if; insert into "SPROCKET"."USLOG$_ISO_COUNTRIES" (m_row$$, dmltype$$, snaptime$$) values (:old.m_row$$, dmltype, to_date('4000-01-01:00:00:00','YYYY-MM-DD:HH24:MI:SS')); end if; end; The purpose of t he USLOG$_I SO_COUNTRI ES t able is t o capt ure inform at ion about DML t hat occurs at t he snapshot sit e. Trigger I SO_COUNTRI ES$RT: declare flag char; begin if "ISO_COUNTRIES$TP".active then if inserting then flag := 'I'; elsif updating then flag := 'U'; elsif deleting then flag := 'D'; end if; "ISO_COUNTRIES$TP".replicate( :old."AUDIT_DATE",:new."AUDIT_DATE", :old."AUDIT_USER",:new."AUDIT_USER", :old."COUNTRY_ID",:new."COUNTRY_ID", :old."GLOBAL_NAME",:new."GLOBAL_NAME", :old."ISO_CODE",:new."ISO_CODE", :old."ISO_NAME",:new."ISO_NAME", flag); end if; end; This t rigger calls I SO_COUNTRI ES$TP.REPLI CATE, which builds a deferred RPC t o propagat e changes t o t he snapshot back t o t he m ast er sit e. The I SO_COUNTRI ES$TP.REPLI CATE procedure is defined in Exam ple 9.1.

Ex a m ple 9 .1 . I SO_ COUN TRI ES$ TP Pa ck a ge package body "ISO_COUNTRIES$TP" as I_am_a_snapshot CHAR; is_snapshot BOOLEAN; function active return boolean is

206

Oracle Distributed Systems begin return (not((is_snapshot and dbms_snapshot.I_am_a_refresh) or not dbms_reputil.replication_is_on)); end active; procedure replicate( "AUDIT_DATE1_o" IN DATE, /*-- The _o and _n parameters --*/ "AUDIT_DATE1_n" IN DATE, /*-- correspond to the old and new --*/ "AUDIT_USER2_o" IN VARCHAR2, /*-- values of the data. --*/ "AUDIT_USER2_n" IN VARCHAR2, /*-- This information is used to --*/ "COUNTRY_ID3_o" IN NUMBER, /*-- check that existing row at the --*/ "COUNTRY_ID3_n" IN NUMBER, /*-- destination site is the same --*/ "GLOBAL_NAME4_o" IN VARCHAR2, /*-- old row at the origin. --*/ "GLOBAL_NAME4_n" IN VARCHAR2, /*-- If there are discrepancies, --*/ "ISO_CODE5_o" IN VARCHAR2, /*-- the conflict resolution method --*/ "ISO_CODE5_n" IN VARCHAR2, /*-- (if defined for the table) is --*/ "ISO_NAME6_o" IN VARCHAR2, /*-- invoked. --*/ "ISO_NAME6_n" IN VARCHAR2, flag IN CHAR) is begin if flag = 'U' then /*-- If updating... --*/ dbms_defer.call('SPROCKET','ISO_COUNTRIES$RP', 'REP_UPDATE',14,'RG_SPROCKET'); dbms_defer.date_arg("AUDIT_DATE1_o"); dbms_defer.date_arg("AUDIT_DATE1_n"); dbms_defer.varchar2_arg("AUDIT_USER2_o"); dbms_defer.varchar2_arg("AUDIT_USER2_n"); dbms_defer.number_arg("COUNTRY_ID3_o"); dbms_defer.number_arg("COUNTRY_ID3_n"); dbms_defer.varchar2_arg("GLOBAL_NAME4_o"); dbms_defer.varchar2_arg("GLOBAL_NAME4_n"); dbms_defer.varchar2_arg("ISO_CODE5_o"); dbms_defer.varchar2_arg("ISO_CODE5_n"); dbms_defer.varchar2_arg("ISO_NAME6_o"); dbms_defer.varchar2_arg("ISO_NAME6_n"); elsif flag = 'I' then /*-- If inserting... --*/ dbms_defer.call('SPROCKET','ISO_COUNTRIES$RP', 'REP_INSERT',8,'RG_SPROCKET'); dbms_defer.date_arg("AUDIT_DATE1_n"); dbms_defer.varchar2_arg("AUDIT_USER2_n"); dbms_defer.number_arg("COUNTRY_ID3_n"); dbms_defer.varchar2_arg("GLOBAL_NAME4_n"); dbms_defer.varchar2_arg("ISO_CODE5_n"); dbms_defer.varchar2_arg("ISO_NAME6_n"); elsif flag = 'D' then /*-- If deleting... */ dbms_defer.call('SPROCKET','ISO_COUNTRIES$RP',

207

Oracle Distributed Systems 'REP_DELETE',8,'RG_SPROCKET'); dbms_defer.date_arg("AUDIT_DATE1_o"); dbms_defer.varchar2_arg("AUDIT_USER2_o"); dbms_defer.number_arg("COUNTRY_ID3_o"); dbms_defer.varchar2_arg("GLOBAL_NAME4_o"); dbms_defer.varchar2_arg("ISO_CODE5_o"); dbms_defer.varchar2_arg("ISO_NAME6_o"); end if; dbms_defer.varchar2_arg(dbms_reputil.global_name); dbms_defer.char_arg(I_am_a_snapshot); end replicate; begin select decode(master, 'N', 'Y', 'N') into I_am_a_snapshot from all_repcat where gname = 'RG_SPROCKET'; is_snapshot := (I_am_a_snapshot = 'Y'); end "ISO_COUNTRIES$TP"; Not e t hat t he calls t o I SO_COUNTRI ES$RP in t his package are RPCs; t he I SO_COUNTRI ES$RP package execut es at t he m ast er sit e. I t applies t he DML from t he snapshot sit e t o t he m ast er t able. I t is defined as shown in Exam ple 9.2:

Ex a m ple 9 .2 . I SO_ COUN TRI ES$ RP Pa ck a ge package body "ISO_COUNTRIES$RP" as procedure rep_delete( "AUDIT_DATE1_o" IN DATE, "AUDIT_USER2_o" IN VARCHAR2, "COUNTRY_ID3_o" IN NUMBER, "GLOBAL_NAME4_o" IN VARCHAR2, "ISO_CODE5_o" IN VARCHAR2, "ISO_NAME6_o" IN VARCHAR2, site_name IN VARCHAR2, propagation_flag IN CHAR) is begin rep_delete( NULL, "AUDIT_DATE1_o", "AUDIT_USER2_o", "COUNTRY_ID3_o", "GLOBAL_NAME4_o", "ISO_CODE5_o", "ISO_NAME6_o", site_name, propagation_flag); end rep_delete; procedure rep_delete( column_changed$ IN RAW, "AUDIT_DATE1_o" IN DATE, "AUDIT_USER2_o" IN VARCHAR2, "COUNTRY_ID3_o" IN NUMBER, "GLOBAL_NAME4_o" IN VARCHAR2, "ISO_CODE5_o" IN VARCHAR2, "ISO_NAME6_o" IN VARCHAR2, site_name IN VARCHAR2, propagation_flag IN CHAR) is

208

Oracle Distributed Systems column_sent$_varchar2 VARCHAR2(6); begin column_changed$$ := column_changed$; if column_changed$ is not null then dbms_reputil.raw_to_varchar2(column_changed$, 2, column_sent$_varchar2); end if; if propagation_flag = 'N' then dbms_reputil.replication_off; end if; dbms_reputil.rep_begin(site_name); dbms_reputil.global_name := site_name; delete from "ISO_COUNTRIES" where ( /*-- make sure the current row matches the origin's row --*/ decode(substr(column_sent$_varchar2, 1, 1), 'N', 'Y', decode("AUDIT_DATE1_o", "AUDIT_DATE", 'Y', 'N')) = 'Y' and decode(substr(column_sent$_varchar2, 2, 1), 'N', 'Y', decode("AUDIT_USER2_o", "AUDIT_USER", 'Y', 'N')) = 'Y' and decode(substr(column_sent$_varchar2, 3, 1), 'N', 'Y', decode("COUNTRY_ID3_o", "COUNTRY_ID", 'Y', 'N')) = 'Y' and decode(substr(column_sent$_varchar2, 4, 1), 'N', 'Y', decode("GLOBAL_NAME4_o", "GLOBAL_NAME", 'Y', 'N')) = 'Y' and decode(substr(column_sent$_varchar2, 5, 1), 'N', 'Y', decode("ISO_CODE5_o", "ISO_CODE", 'Y', 'N')) = 'Y' and decode(substr(column_sent$_varchar2, 6, 1), 'N', 'Y', decode("ISO_NAME6_o", "ISO_NAME", 'Y', 'N')) = 'Y' ); if sql%rowcount = 0 then raise no_data_found; /*-- no records match --*/ elsif sql%rowcount > 1 then raise too_many_rows; /*-- more than one record matches -*/ end if; dbms_reputil.rep_end; exception when no_data_found then begin if not "ISO_COUNTRIES$RR".delete_conflict_handler( "AUDIT_DATE1_o", "AUDIT_USER2_o", "COUNTRY_ID3_o", "GLOBAL_NAME4_o", "ISO_CODE5_o", "ISO_NAME6_o",

209

Oracle Distributed Systems site_name, propagation_flag, column_changed$, column_sent$_varchar2) then dbms_reputil.rep_end; raise; end if; dbms_reputil.rep_end; exception when others then dbms_reputil.rep_end; raise; end; when others then dbms_reputil.rep_end; raise; end rep_delete; procedure rep_insert( "AUDIT_DATE1_n" IN DATE, "AUDIT_USER2_n" IN VARCHAR2, "COUNTRY_ID3_n" IN NUMBER, "GLOBAL_NAME4_n" IN VARCHAR2, "ISO_CODE5_n" IN VARCHAR2, "ISO_NAME6_n" IN VARCHAR2, site_name IN VARCHAR2, propagation_flag IN CHAR) is begin if propagation_flag = 'N' then dbms_reputil.replication_off; end if; dbms_reputil.rep_begin(site_name); dbms_reputil.global_name := site_name; insert into "ISO_COUNTRIES" ( "AUDIT_DATE", "AUDIT_USER", "COUNTRY_ID", "GLOBAL_NAME", "ISO_CODE", "ISO_NAME") values ( "AUDIT_DATE1_n", "AUDIT_USER2_n", "COUNTRY_ID3_n", "GLOBAL_NAME4_n", "ISO_CODE5_n", "ISO_NAME6_n"); dbms_reputil.rep_end; exception when dup_val_on_index then begin if not "ISO_COUNTRIES$RR".unique_conflict_insert_handler( "AUDIT_DATE1_n", "AUDIT_USER2_n", "COUNTRY_ID3_n", "GLOBAL_NAME4_n", "ISO_CODE5_n", "ISO_NAME6_n",

210

Oracle Distributed Systems site_name, propagation_flag, SQLERRM) then dbms_reputil.rep_end; raise; end if; dbms_reputil.rep_end; exception when others then dbms_reputil.rep_end; raise; end; when others then dbms_reputil.rep_end; raise; end rep_insert; procedure rep_update( "AUDIT_DATE1_o" IN DATE, "AUDIT_DATE1_n" IN DATE, "AUDIT_USER2_o" IN VARCHAR2, "AUDIT_USER2_n" IN VARCHAR2, "COUNTRY_ID3_o" IN NUMBER, "COUNTRY_ID3_n" IN NUMBER, "GLOBAL_NAME4_o" IN VARCHAR2, "GLOBAL_NAME4_n" IN VARCHAR2, "ISO_CODE5_o" IN VARCHAR2, "ISO_CODE5_n" IN VARCHAR2, "ISO_NAME6_o" IN VARCHAR2, "ISO_NAME6_n" IN VARCHAR2, site_name IN VARCHAR2, propagation_flag IN CHAR) is begin rep_update( NULL, "AUDIT_DATE1_o", "AUDIT_DATE1_n", "AUDIT_USER2_o", "AUDIT_USER2_n", "COUNTRY_ID3_o", "COUNTRY_ID3_n", "GLOBAL_NAME4_o", "GLOBAL_NAME4_n", "ISO_CODE5_o", "ISO_CODE5_n", "ISO_NAME6_o", "ISO_NAME6_n", site_name, propagation_flag); end rep_update; procedure rep_update( column_changed$ IN RAW, "AUDIT_DATE1_o" IN DATE, "AUDIT_DATE1_n" IN DATE, "AUDIT_USER2_o" IN VARCHAR2, "AUDIT_USER2_n" IN VARCHAR2, "COUNTRY_ID3_o" IN NUMBER, "COUNTRY_ID3_n" IN NUMBER,

211

Oracle Distributed Systems "GLOBAL_NAME4_o" IN VARCHAR2, "GLOBAL_NAME4_n" IN VARCHAR2, "ISO_CODE5_o" IN VARCHAR2, "ISO_CODE5_n" IN VARCHAR2, "ISO_NAME6_o" IN VARCHAR2, "ISO_NAME6_n" IN VARCHAR2, site_name IN VARCHAR2, propagation_flag IN CHAR) is column_changed$_varchar2 VARCHAR2(6); column_sent$_varchar2 VARCHAR2(6); begin column_changed$$ := column_changed$; if column_changed$ is not null then dbms_reputil.raw_to_varchar2(column_changed$, 1, column_changed$_varchar2); dbms_reputil.raw_to_varchar2(column_changed$, 2, column_sent$_varchar2); end if; if propagation_flag = 'N' then dbms_reputil.replication_off; end if; dbms_reputil.rep_begin(site_name); dbms_reputil.global_name := site_name; update "ISO_COUNTRIES" set "AUDIT_DATE" = decode(substr(column_changed$_varchar2, 1, 1), 'N', "AUDIT_DATE", 'Y', "AUDIT_DATE1_n", NULL, decode("AUDIT_DATE1_o", AUDIT_DATE1_n","AUDIT_DATE", AUDIT_DATE1_n")), "AUDIT_USER" = decode(substr(column_changed$_varchar2, 2, 1), 'N', "AUDIT_USER", 'Y', "AUDIT_USER2_n", NULL, decode("AUDIT_USER2_o", AUDIT_USER2_n","AUDIT_USER", AUDIT_USER2_n")), "COUNTRY_ID" = decode(substr(column_changed$_varchar2, 3, 1), 'N', "COUNTRY_ID", 'Y', "COUNTRY_ID3_n", NULL, decode("COUNTRY_ID3_o", "COUNTRY_ID3_n","COUNTRY_ID", "COUNTRY_ID3_n")), "GLOBAL_NAME" = decode(substr(column_changed$_varchar2, 4, 1), 'N', "GLOBAL_NAME", 'Y', "GLOBAL_NAME4_n", NULL, decode("GLOBAL_NAME4_o", "GLOBAL_NAME4_n","GLOBAL_NAME", "GLOBAL_NAME4_n")), "ISO_CODE" = decode(substr(column_changed$_varchar2, 5, 1), 'N', "ISO_CODE",

212

Oracle Distributed Systems 'Y', "ISO_CODE5_n", NULL, decode("ISO_CODE5_o", "ISO_CODE5_n","ISO_CODE", "ISO_CODE5_n")), "ISO_NAME" = decode(substr(column_changed$_varchar2, 6, 1), 'N', "ISO_NAME", 'Y', "ISO_NAME6_n", NULL, decode("ISO_NAME6_o", "ISO_NAME6_n","ISO_NAME", "ISO_NAME6_n")) where (((decode(substr(column_changed$_varchar2, 1, 1), 'N', 'Y', 'Y', 'N', decode("AUDIT_DATE1_o", "AUDIT_DATE1_n", 'Y', 'N')) = 'Y' and decode(substr(column_changed$_varchar2, 2, 1), 'N', 'Y', 'Y', 'N', decode("AUDIT_USER2_o","AUDIT_USER2_n", 'Y', 'N')) = 'Y' and 1 = 1 and decode(substr(column_changed$_varchar2, 4, 1), 'N', 'Y', 'Y', 'N', decode("GLOBAL_NAME4_o", "GLOBAL_NAME4_n", 'Y', 'N')) = 'Y'and decode(substr(column_changed$_varchar2, 5, 1), 'N', 'Y', 'Y', 'N', decode("ISO_CODE5_o", "ISO_CODE5_n", 'Y', 'N')) = 'Y' and decode(substr(column_changed$_varchar2, 6, 1), 'N', 'Y', 'Y', 'N', decode("ISO_NAME6_o", "ISO_NAME6_n", 'Y', 'N')) = 'Y')) or (decode(substr(column_sent$_varchar2, 1, 1), 'N', 'Y', decode("AUDIT_DATE1_o", "AUDIT_DATE", 'Y', 'N')) = 'Y' and decode(substr(column_sent$_varchar2, 2, 1), 'N', 'Y', decode("AUDIT_USER2_o", "AUDIT_USER", 'Y', 'N')) = 'Y' and 1 = 1 and decode(substr(column_sent$_varchar2, 4, 1), 'N', 'Y', decode("GLOBAL_NAME4_o", "GLOBAL_NAME", 'Y', 'N')) = 'Y' and decode(substr(column_sent$_varchar2, 5, 1), 'N', 'Y', decode("ISO_CODE5_o", "ISO_CODE", 'Y', 'N')) = 'Y' and decode(substr(column_sent$_varchar2, 6, 1), 'N', 'Y', decode("ISO_NAME6_o", "ISO_NAME", 'Y', 'N')) = 'Y')) and "COUNTRY_ID3_o" = "COUNTRY_ID"; if sql%rowcount = 0 then

213

Oracle Distributed Systems raise no_data_found; elsif sql%rowcount > 1 then raise too_many_rows; end if; dbms_reputil.rep_end; exception when no_data_found then begin if not "ISO_COUNTRIES$RR".update_conflict_handler( "AUDIT_DATE1_o", dbms_reputil2.choose_date( "AUDIT_DATE1_o", "AUDIT_DATE1_n", column_changed$_varchar2, 1), "AUDIT_USER2_o", dbms_reputil2.choose_varchar2( "AUDIT_USER2_o", "AUDIT_USER2_n", column_changed$_varchar2, 2), "COUNTRY_ID3_o", dbms_reputil2.choose_number( "COUNTRY_ID3_o", "COUNTRY_ID3_n", column_changed$_varchar2, 3), "GLOBAL_NAME4_o", dbms_reputil2.choose_varchar2( "GLOBAL_NAME4_o", "GLOBAL_NAME4_n", column_changed$_varchar2, 4), "ISO_CODE5_o", dbms_reputil2.choose_varchar2( "ISO_CODE5_o", "ISO_CODE5_n", column_changed$_varchar2, 5), "ISO_NAME6_o", dbms_reputil2.choose_varchar2( "ISO_NAME6_o", "ISO_NAME6_n", column_changed$_varchar2, 6), site_name, propagation_flag, column_changed$, column_sent$_varchar2, null) then dbms_reputil.rep_end; raise; end if; dbms_reputil.rep_end; exception when others then dbms_reputil.rep_end; raise; end; when dup_val_on_index then begin if not "ISO_COUNTRIES$RR".unique_conflict_update_handler( "AUDIT_DATE1_o",

214

Oracle Distributed Systems dbms_reputil2.choose_date( "AUDIT_DATE1_o", "AUDIT_DATE1_n", column_changed$_varchar2, 1), "AUDIT_USER2_o", dbms_reputil2.choose_varchar2( "AUDIT_USER2_o", "AUDIT_USER2_n", column_changed$_varchar2, 2), "COUNTRY_ID3_o", dbms_reputil2.choose_number( "COUNTRY_ID3_o", "COUNTRY_ID3_n", column_changed$_varchar2, 3), "GLOBAL_NAME4_o", dbms_reputil2.choose_varchar2( "GLOBAL_NAME4_o", "GLOBAL_NAME4_n", column_changed$_varchar2, 4), "ISO_CODE5_o", dbms_reputil2.choose_varchar2( "ISO_CODE5_o", "ISO_CODE5_n", column_changed$_varchar2, 5), "ISO_NAME6_o", dbms_reputil2.choose_varchar2( "ISO_NAME6_o", "ISO_NAME6_n", column_changed$_varchar2, 6), site_name, propagation_flag, column_changed$, column_sent$_varchar2, null, SQLERRM) then dbms_reputil.rep_end; raise; end if; dbms_reputil.rep_end; exception when others then dbms_reputil.rep_end; raise; end; when others then dbms_reputil.rep_end; raise; end rep_update; end "ISO_COUNTRIES$RP"; Not e t hat t he I SO_COUNTRI ES$RP package has several references t o I SO_COUNTRI ES$RR. The $RR package cont ains logic t o resolve conflict s. Figure 9.2 illust rat es t he int eract ion am ong all of t hese obj ect s.

215

Oracle Distributed Systems

Figu r e 9 .2 . H ow u pda t e a ble sn a psh ot s w or k

9 .3 .2 .3 Th e m u lt i- m a st e r r e plica t ion m e ch a n ism I n som e respect s, t he m ult i- m ast er replicat ion archit ect ure is sim pler t han t he updat eable snapshot archit ect ure. Because t here is no dist inct ion bet ween m ast er sit es and snapshot sit es, DML propagat ion is handled ident ically at all sit es; local DML changes are queued as soon as t hey occur and dispat ched at an int erval specified in DBMS_DEFER_SYS.SCHEDULE_EXECUTI ON ( Oracle7) or DBMS_DEFER_SYS.PUSH ( Oracle8) . The m echanism behind m ult i- m ast er replicat ion consist s of t riggers on t he replicat ed t ables t hat call package procedures, which queue deferred RPCs t o t he rem ot e m ast er dat abases. The call t o DBMS_REPCAT.GENERATE_REPLI CATI ON_SUPPORT support generat es t hese t riggers and packages. Table 9.4 list s t he obj ect s t hat Oracle creat es t o support m ult i- m ast er replicat ion of t he I SO_COUNTRI ES t able.

Table 9.4. Objects to Support Multi-Master Replication of Table ISO_COUNTRIES 216

Oracle Distributed Systems

Object Name

Object Type

I SO_COUNTRI ES$RT Trigger

Function Trigger on I SO_COUNTRI ES; m akes calls t o I SO_COUNTRI ES$TP. Not e t hat t his t rigger is int ernalized in Oracle8.

Builds deferred RPCs, which queue DML for I SO_COUNTRI ES$TP Package propagat ion t o ot her m ast er sit es. The deferred RPCs are t o t he I SO_COUNTRI ES$RP package. Applies DML from rem ot e m ast ers t o t he local t able. I SO_COUNTRI ES$RP Package I nvokes I SO_COUNTRI ES$RR in t he event t hat conflict s are det ect ed. I SO_COUNTRI ES$RR Package I nvoked conflict resolut ion m et hods, if defined. Figure 9.3 illust rat es t he int eract ion of t hese obj ect s.

Figu r e 9 .3 . H ow m u lt i- m a st e r r e plica t ion w or k s

9 .3 .3 Th e Ba ck gr ou n d Pr oce sse s The aut om at ion of dat a propagat ion in a replicat ed environm ent depends on t he j ob queue. Oracle's j ob queue is analogous t o a VMS bat ch queue or t o Unix cron j obs; you use it t o schedule act ivit ies t hat occur wit hout user int eract ion. Just as operat ing syst em processes drive a VMS bat ch queue or Unix cron j obs, Oracle uses background processes t o drive it s j ob queue. I n a Solaris environm ent , t hese

217

Oracle Distributed Systems processes have a nam e in t he form ora_snpn_ORACLE_SI D. For exam ple, t he PHQS inst ance has allocat ed five background processes t o cont rol it s j ob queue: socrates% ps -ef | grep snp | oracle 27409 1 0 Jun oracle 27411 1 0 Jun oracle 27413 1 0 Jun oracle 27415 1 0 Jun oracle 27419 1 0 Jun

grep -v grep | sort 23 ? 26:10 ora_snp0_PHQS 23 ? 26:30 ora_snp1_PHQS 23 ? 26:21 ora_snp2_PHQS 23 ? 27:19 ora_snp3_PHQS 23 ? 26:10 ora_snp4_PHQS

As t heir nam e im plies, t hese background processes also handle snapshot refreshes. I n fact , t he j ob queue it self is an ext ension of t echnology t hat was developed t o support snapshot s. You can cont rol how m any background processes are allocat ed t o t he j ob queue and t heir behavior wit h t wo I NI T.ORA param et ers: JOB_QUEUE_PROCESSES Det erm ines how m any background processes t o launch. Each background process can service at m ost one j ob queue ent ry at a t im e; m ake sure t hat you have enough t o keep your j obs running on schedule. The m axim um num ber allowable is 36 ( snp0 t hrough snp9 and snpA t hrough snpZ) . JOB_QUEUE_I NTERVAL Det erm ines how oft en t he j ob queue processes " wake up" t o see if t here are j obs t hat are due t o run. The range of values is 1 t o 3600; t he unit s are seconds.

Oracle Version 7.1 has a param et er, JOB_QUEUE_KEEP_CONNECTI ONS, which can be used t o keep open rem ot e dat abase connect ions t hat t he j ob queue background process creat es. Alt hough t his param et er also exist s in Oracle Versions 7.2, 7.3, and 8.0, it is included for backw ard com pat ibilit y only and does not have any effect . I n Version 7.2 and lat er, Oracle closes rem ot e dat abase connect ions aft er j obs execut e.

I f you are using t he parallel propagat ion feat ure of Oracle8, t hen you also need t o be sure t o allocat e t he query server background processes. Alt hough t hese processes generally are associat ed wit h t he Parallel Query Opt ion, Oracle also uses t hem t o propagat e DML changes in parallel. These processes are nam ed ora_pnnn_ORACLE_SI D. The PHQS dat abase has eight of t hem : socrates% ps -ef | grep ora_p0 | grep -v grep | sort oracle 27427 1 0 Jun 23 ? 0:00 ora_p000_PHQS

218

Oracle Distributed Systems oracle oracle oracle oracle oracle oracle oracle

27429 27431 27433 27435 27437 27439 27441

1 1 1 1 1 1 1

0 0 0 0 0 0 0

Jun Jun Jun Jun Jun Jun Jun

23 23 23 23 23 23 23

? ? ? ? ? ? ?

0:00 0:00 0:00 0:00 0:00 0:00 0:00

ora_p001_PHQS ora_p002_PHQS ora_p003_PHQS ora_p004_PHQS ora_p005_PHQS ora_p006_PHQS ora_p007_PHQS

The following init ializat ion param et ers cont rol t he num ber and behavior of t hese background processes: PARALLEL_MAX_SERVERS The m axim um num ber of background processes t o creat e. Must be great er t han or equal t o PARALLEL_MI N_SERVERS. This param et er allows you t o put a cap on t he num ber of background processes Oracle spawns so t hat t hey do not consum e excessive resources. However, not e t hat you need one background process for every st ream of parallel propagat ion. The range of values is t hrough 256. PARALLEL_MI N_SERVERS The m inim um num ber of background processes t o spawn. PARALLEL_SERVER_I DLE_TI ME The am ount of t im e a query server background process can rem ain idle before it is t erm inat ed. You m ust set t he JOB_QUEUE_PROCESSES if you want t o use t he j ob queue; t he default value is 0. Sim ilarly, if you want t o ut ilize parallel propagat ion, you m ust set t he PARALLEL_MI N_SERVERS init ializat ion param et er.

9 .4 Re plica t ion of D D L Oracle allows you t o replicat e DDL as well as DML. I n ot her words, if you want t o alt er a t able or creat e a new obj ect such as an index or synonym , you can do so at t he m ast er definit ion sit e and aut om at ically propagat e t he changes t o t he ot her m ast er sit es. The procedure DBMS_REPCAT.EXECUTE_DDL provides t his funct ionalit y. The DBMS_REPCAT.EXECUTE_DDL procedure queues changes in t he replicat ion cat alog queue ( repcat log) , and t he scheduled j ob DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMI N pushes t he changes t o t he ot her m ast ers. Ent ries in t he repcat log are visible in t he DBA_REPCATLOG dat a dict ionary view; a STATUS field cont ains t he value ERROR when errors occur; t he MESSAGE field cont ains t he error t ext . Not only does t he repcat log queue DDL t o ot her m ast er sit es, it also queues replicat ion adm inist rat ive t asks such as quiescing t he environm ent or adding new m ast er sit es. Chapt er 12, describes t hese ot her act ivit ies in det ail.

219

Oracle Distributed Systems

9 .5 Or a cle 8 En h a n ce m e n t s The funct ionalit y of t he advanced replicat ion facilit y is great ly enhanced in Oracle8— so m uch so t hat you should m ake every effort t o upgrade t o Oracle8 ( if you haven't already) before creat ing a replicat ed environm ent . The following is a sum m ary of t he new funct ionalit y: Parallel propagat ion Oracle8 can deliver deferred t ransact ions t o rem ot e dat abases in m ult iple st ream s, t hereby significant ly im proving t hroughput . I nt ernalized t riggers The t able_nam e $RT t riggers are int ernalized in Oracle8, which im proves perform ance and reduces adm inist rat ive chores. Reduced dat a propagat ion Unlike Oracle7, Oracle8 sends m odified colum n values t o rem ot e dat abases only when a record is updat ed. Subquery snapshot s Snapshot s cont aining subqueries can be fast - refreshed provided t hat t hey m eet cert ain rest rict ions. LOB support Oracle8 support s t he replicat ion of LOB, CLOB, and NCLOB dat at ypes ( which are new t o Oracle8) . The Oracle7 predecessors of t hese dat at ypes, LONG and LONG RAW, could not be replicat ed. Fine- grained quiesce Oracle8 can quiesce one replicat ion group at a t im e. I n Oracle7, quiescing one group effect ively quiesces all ot her groups. Prim ary key snapshot s Oracle8 snapshot s are based on t he prim ary key, rat her t han on ROWI D. Thus, m ast er t ables can be reorganized wit hout having t o perform com plet e refreshes on all snapshot t ables. Mast er sit e snapshot regist rat ion When you creat e a snapshot from an Oracle8 snapshot sit e t o an Oracle8 m ast er sit e, Oracle records t he exist ence of t he snapshot in t he m ast er sit e's dat a dict ionary view DBA_REGI STERED_SNAPSHOTS.

220

Oracle Distributed Systems Support for offline inst ant iat ion The procedure for adding new m ast er and snapshot sit es requires less downt im e and is m ore aut om at ic. Deferred const raint checking for updat eable snapshot s Uniqueness and referent ial int egrit y const raint s on updat eable snapshot s can be checked and enforced aft er a refresh is com plet e inst ead of during t he refresh. Validat ion procedure Oracle8 provides t he DBMS_REPCAT.VALI DATE procedure which can help t o verify t he correct configurat ion of a replicat ed environm ent . Part it ioned t ables and indexes Oracle8 support s t he replicat ion of part it ioned t ables and t ables wit h part it ioned indexes.

9 .6 Or a cle 8 i En h a n ce m e n t s Oracle8i enhancem ent s t o replicat ion focus prim arily on im proved perform ance, sim pler adm inist rat ion, and m ass deploym ent ( e.g., hundreds of updat eable snapshot s from a single m ast er t able) : •

• • •

The generat ed replicat ion apply packages ( t able_nam e $RP and t able_nam e $RR) are int ernalized inst ead of PL/ SQL packages—t hat is, t hey are writ t en in C and com piled direct ly int o t he dat abase engine. This result s in fast er execut ion and generat ion of replicat ion support . I n addit ion, t he packages are m ore secure. Snapshot refreshes have been opt im ized t o support refresh groups wit h up t o 400 snapshot s per group. I n addit ion, t he refresh algorit hm has been m odified t o significant ly reduce t he num ber of round- t rips required t o perform a refresh. Snapshot deploym ent t em plat es allow t he DBA t o cont rol t he cont ent s of snapshot sit es. The t em plat es are defined at t he m ast er sit e and deployed t o snapshot sit es, as opposed t o snapshot sit es defining t heir own snapshot s. This ensures a uniform configurat ion of all snapshot sit es. Vert ical part it ioning of updat eable snapshot s. Not e t hat vert ical part it ions m ust include all colum ns t hat com prise t he m ast er t able's prim ary key, and t he colum ns t hat are not included m ust eit her be nullable in t he m ast er t able or have default values assigned.

9 .7 Alt e r n a t ive s t o Re plica t ion Before m oving on, I want t o point out t hat t here are alt ernat ives t o advanced replicat ion. Like advanced replicat ion, t hese alt ernat ives can creat e replicas of t able

221

Oracle Distributed Systems and dat a at rem ot e sit es. However, unlike advanced replicat ion, t hey are not aut om at ic.

9 .7 .1 A pplica t ion - a n d Tr igge r - Ba se d Re plica t ion I f you have a relat ively sim ple replicat ion requirem ent , you m ight consider replicat ing DML yourself, eit her by having your applicat ion perform writ es t o m ult iple dat abases or by including t riggers on t ables t hat perform rem ot e DML. This is a " quick and dirt y" solut ion and is pract ical only if very few obj ect s are being replicat ed. I f you choose t o creat e your own replicat ion funct ionalit y, you will have t o be sure t o address issues such as failed writ es t o t he rem ot e dat abases and degraded perform ance if writ es t o m any locat ions are required.

9 .7 .2 Ex por t / I m por t You can use Oracle's export and im port ut ilit ies t o m ove dat a from one locat ion t o anot her. This is part icularly useful if a large am ount of dat a needs t o be relocat ed, especially if t he rem ot e sit e( s) are available over a WAN or ot herwise expensive net work connect ion. Of course, t he disadvant ages of t he export / im port ut ilit ies are t hat t hey are far from aut om at ed and are only point - in- t im e pict ures of t he dat abase. I n addit ion, changes you m ake t o im port ed t ables are not propagat ed back t o t he t ables t hat were originally im port ed.

9 .7 .3 COPY/ CREATE TABLE AS SELECT You can use t he SQL com m ands COPY or CREATE TABLE AS SELECT t o m ake a replica of a rem ot e t able over a dat abase link. These com m and are easy t o use but , like t he export / im port ut ilit ies, do not propagat e dat a changes back t o t he original t ables. I n short , alt hough t here are a variet y of ways t o process replicat ed dat a, t he advanced replicat ion facilit y provides t he m ost sophist icat ed and robust archit ect ure.

222

Oracle Distributed Systems

Ch a pt e r 1 0 . Adva n ce d Re plica t ion I n st a lla t ion Many of t he difficult ies people experience wit h using advanced replicat ion st em from incorrect or incom plet e inst allat ions. Unfort unat ely, inst allat ion errors m ay go undet ect ed unt il you have creat ed and inst ant iat ed replicat ion groups. But fort unat ely, it is possible t o validat e an inst allat ion before creat ing obj ect s. I f you carefully follow t he inst ruct ions provided here, your inst allat ions should be successful.

1 0 .1 I n it ia liza t ion Pa r a m e t e r s Several init ializat ionparam et ers have a st rong bearing on t he perform ance and reliabilit y of advanced replicat ion. Table 10.1 sum m arizes t hese param et ers.

Table 10.1. Initialization Parameters for Advanced Replication Parameter Name

Default Value

Value Range

Remarks The num ber of seconds t hat dist ribut ed t ransact ions will wait for locked obj ect s. The default m ay not be adequat e for rem ot e t ransact ions t o com plet e, part icularly if you are on a slow net work or a WAN.

DI STRI BUTED_LOCK_TI MEOUT

60 ( seconds)

60 ndash; 300

DI STRI BUTED_TRANSACTI ONS

The num ber of dist ribut ed t ransact ions in which t he dat abase can part icipat e at OS dependent ; one t im e. I f set t o 0, no 0 ndash; TRANSACTI ONS dist ribut ed approxim at ely t ransact ions TRANSACTI ONS/ 4 are allowed. Make sure it is set high enough t o support your sit e's act ivit y.

223

Oracle Distributed Systems

G LOBAL_NAMES

JOB_QUEUE_I NTERVAL

JOB_QUEUE_PROCESSES

OPEN_LI NKS

FALSE

60 ( seconds)

0

4

TRUE or FALSE

Enforces global nam ing. I t m ust be set t o TRUE t o use advanced replicat ion. Even if you are not using advanced replicat ion, TRUE is t he recom m ended set t ing and m ay be required in fut ure Oracle releases.

1 ndash; 3600

Set s t he frequency wit h which j ob queue background processes wake up. I t should be at least as frequent as your m ost frequent scheduled j ob.

0 ndash; 36

This param et er dict at es t he num ber of background processes Oracle will st art for t he j ob queue. Must be at least 1. Should be at least as high as t he m axim um num ber of j obs you need t o run sim ult aneously.

0 ndash; 255

The m axim um num ber of dat abase links t hat can be open sim ult aneously.

224

Oracle Distributed Systems

Set s t he m axim um num ber of query server background processes. I f you are using parallel propagat ion, m ake sure it is set high enough for your workload.

OS dependent ; PARALLEL_MAX_SERVERS 5 on Solaris

0 ndash; 256

( Oracle8 only) 5 on NT

PARALLEL_MI N_SERVERS 0 ( Oracle8 only)

Set s t he num ber of query server background processes Oracle st art s 0 ndash; up. I f you are PARALLEL_MAX_SERVERS using parallel propagat ion, you need a parallel query background process for each st ream .

0 ndash; OS- dependent m axim um

The num ber of m inut es a query server background process is idle before Oracle t erm inat es t he process.

TRUE or FALSE

Enables Oracle's dependency t racking, which parallel propagat ion uses. Must be set t o TRUE.

TRUE or FALSE

Leave t his set t ing at FALSE; a bug causes propagat ion t o rem ot e sit es t o fail wit h " session lim it

OS dependent ; PARALLEL_SERVER_I DLE_TI ME

5 on Solaris

( Oracle8 only)

5 on NT ( m inut es)

REPLI CATI ON_DEPENDENCY_TRACKI NG TRUE ( Oracle8 only)

RESOURCE_LI MI T

FALSE

225

Oracle Distributed Systems

exceeded" even if t he propagat or's profile has no lim it s set .

SHARED_POOL_SI ZE

3.5MB

Advanced replicat ion uses a significant am ount of shared pool resources. Oracle Corporat ion has st at ed t hat t he shared pool ut ilizat ion for replicat ed DML is at least six t im es t hat of nonreplicat ed DML.

300K ndash; OSdependent lim it

Of t he param et ers list ed in Table 10.1, SHARED_POOL_SI ZE is t he m ost crucial for a successful inst allat ion. I n fact , t he cat rep.sql script , which creat es t he dat a dict ionary obj ect s for replicat ion, will fail if t he shared pool is less t han 11MB. As a pract ical m at t er, 32MB should be considered t he absolut e m inim um for a replicat ed dat abase.

1 0 .2 Re do Logs a n d Rollba ck Se gm e n t s The dat abase act ivit y t hat drives t he replicat ion syst em generat es a t rem endous am ount of redo and rollback act ivit y—at least five t im es t hat of a nonreplicat ed environm ent by Oracle Corporat ion's own est im at es. Most of t his overhead is associat ed wit h int ernal t ransact ions t hat m odify dat a dict ionary t ables: • • •

•

Enqueuing and dequeueing deferred t ransact ions updat e t he t ables SYSTEM.DEF$_AQCALL and SYSTEM.DEF$_AQERROR in Oracle8, and SYSTEM.DEF$_CALL in Oracle7. The scheduled j obs t hat propagat e DML and DDL updat e SYS.JOB$ every t im e t hey run. These updat es alone can account for m any m egabyt es of redo logs per hour depending on t he frequency wit h which t hese j obs run. Collect ing st at ist ics about resolved conflict s updat es SYSTEM.REPCAT$_RESOLUTI ON_STATI STI CS. Snapshot refreshes updat e t he t ables SYSTEM.SNAP$, SYSTEM.RGCHI LD$, and ( in Oracle8) SYSTEM.SNAP_REFTI ME$.

Because of t his addit ional act ivit y, you should use m ore and larger redo logs and rollback segm ent s t han you would for a nonreplicat ed environm ent . A good st art ing point is t o have five redo groups using 32MB redo logs and at least five rollback segm ent s, wit h an opt im al size of 64MB. This configurat ion is easiest t o do at t he t im e you creat e t he dat abase.

226

Oracle Distributed Systems

1 0 .3 Size a n d Pla ce m e n t of D a t a D ict ion a r y Obj e ct s The propert ies of advanced replicat ion's underpinning t ables and indexes are such t hat t hey warrant t heir own t ablespace. A default inst allat ion, however, places t hese obj ect s in t he SYSTEM t ablespace wit h it s default values for I NI TI AL and NEXT ext ent s. The default inst allat ion quickly fragm ent s t he SYSTEM t ablespace and oft en requires t he addit ion of several dat a files t o support t he growt h of t he replicat ion dat a dict ionary. Fort unat ely, t hese problem s are avoidable if you follow t hese st eps when you creat e your dat abase or at least before you run cat proc.sql : 1. Creat e a separat e t ablespace for t he replicat ion dat a dict ionary obj ect s, and specify default st orage param et ers for I NI TI AL, NEXT, and PCTI NCREASE: 2. CREATE TABLESPACE symrep_data 3. DATAFILE '/export/vol01/oradata/PHQS/symrep_data01.dbf' SIZE 500M DEFAULT STORAGE (INITIAL 512K NEXT 1M PCTINCREASE 1); 4. Make t he new t ablespace t he default t ablespace for user SYSTEM: ALTER USER system DEFAULT TABLESPACE symrep_data; 5. Run t he cat proc.sql script from server m anager, connect ed as user SYS: 6. socrates% svrmgrl 7. 8. Oracle Server Manager Release 3.0.4.0.0 - Production 9. 10. (c) Copyright 1997, Oracle Corporation. All Rights Reserved. 11. 12. Oracle8 Enterprise Edition Release 8.0.4.1.0 - Production 13. With the Partitioning and Objects options 14. PL/SQL Release 8.0.4.1.0 - Production 15. 16. SVRMGR> connect internal 17. Connected. 18. SVRMGR> @catproc ... cat proc.sql creat es, am ong ot her t hings, t he obj ect s t hat support deferred t ransact ions, as well as t he Advanced Queueing facilit y in Oracle8. 19. Run t he replicat ion cat alog script s cat rep.sql and cat repad.sql. You m ust be connect ed as SYS t o run t hese script s: 20. SVRMGR> connect internal 21. Connected. 22. SVRMGR> @catrep 23. ... 24. SVRMGR> @catrepad ... I t is a good idea t o confirm t hat all dat abase obj ect s have a st at us of VALI D aft er you run t he script s cat proc.sql, cat rep.sql, and cat repad.sql. Query t he dat a dict ionary view DBA_OBJECTS t o confirm t he st at us, and repair any

227

Oracle Distributed Systems obj ect s t hat are invalid eit her by com piling t hem or by increasing t he shared pool and rerunning t he script s. 25. The t riggers and packages t hat Oracle creat es when you generat e replicat ion support can pot ent ially am ount t o a t rem endous volum e of PL/ SQL source in t he dat abase. I f you expect t o replicat e m ore t han about 20 t ables, you should change t he set t ing for t he NEXT ext ent on t he t able SYS.SOURCE$ and index SYS.I _SOURCE$: 26. ALTER TABLE sys.source$ STORAGE (NEXT 1M); ALTER INDEX sys.i_source$ STORAGE (NEXT 1M); Alt ernat ively, you can edit t he cat alog script which creat es t hese obj ect s, sql.bsq. This script cont ains t he boot st rap.sql code t hat Oracle uses t o build a dat abase.

Do not m odify t he sql.bsq file unless you are cert ain t hat you underst and t he consequences of your m odificat ions. Also, be aware t hat Oracle m ay not support dat abases t hat are creat ed wit h a m odified version of t his file. We can only hope t hat fut ure releases of Oracle include a variet y of sql.bsq files so t hat we can creat e a dat a dict ionary whose st orage param et ers suit specific t ypes of dat abases.

1 0 .4 Adm in ist r a t ive Accou n t s, Pr ivile ge s, a n d D a t a ba se Lin k s Depending on whet her you are running Oracle7 or Oracle8 and which securit y m odel you choose t o follow, t he account - creat ion process can be sim ple or t edious. I n Oracle7, you have t he choice of eit her m irrored user access or global access. I n Oracle8, t he m anagem ent of user account s is subst ant ially easier; you need only t o creat e propagat or and receiver account s. Regardless of which m odel you choose or which Oracle version you are using, t he proper configurat ion of account s, privileges, and dat abase links is crucial. I n t his sect ion we provide st ep- by- st ep procedures you can follow.

I n all cases, t he creat ion of adm inist rat ive account s and dat abase links requires t hat you have already run t he cat alog script s cat proc.sql, cat rep.sql, and opt ionally cat repad.sql.

1 0 .4 .1 Con figu r in g Or a cle 7 for t h e M ir r or e d Use r Acce ss M ode l As it s nam e im plies, t he m irrored user access m odel requires t hat every dat abase have an account for every user who is allowed t o perform DML against replicat ed

228

Oracle Distributed Systems t ables. The onus of creat ing account s for all of t hese users in m ult iple dat abases lies wit h t he DBA, who m ust also ensure t hat t hese account s have t he sam e passwords in each dat abase. I n addit ion, t hese user account s require EXECUTE privileges on t he generat ed replicat ion support packages for each replicat ed obj ect t hey can m anipulat e. These privileges m ust be direct ly grant ed, not inherit ed t hrough a dat abase role. Each of t hese account s also requires a privat e dat abase link t o each m ast er dat abase. See Chapt er 14, for a package t hat can creat e user account s in rem ot e dat abases. Here are t he st eps for configuring advanced replicat ion for m irrored user access: 1. Creat e public dat abase links from every m ast er sit e t o every ot her m ast er sit e. Creat e t hese links as user SYS, and do not use t he CONNECT TO clause: 2. CREATE PUBLIC DATABASE LINK PHQS.BIGWHEEL.COM USING 'prodhq'; Oracle uses t his dat abase link t o resolve privat e dat abase links, which m ust be creat ed wit hout a USI NG clause ( see St ep 2) . This public dat abase link t ells Oracle t hat privat e links nam ed PHQS.BI GWHEEL.COM should connect t o t he dat abase ident ified by t he SQL* Net alias prodhq. 3. Creat e a REPSYS user in all m ast er dat abases, wit h t he sam e password in each dat abase; grant t his user surrogat e SYS privileges: 4. CREATE USER REPSYS 5. IDENTIFIED BY surrogate 6. DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; 7. EXECUTE dbms_repcat_auth.grant_surrogate_repcat (' REPSYS'); The REPSYS account is t he one t o which privat e dat abase links from user SYS in rem ot e m ast er dat abases connect . Dat abase links t hat connect from SYS t o SYS in t he rem ot e dat abase com prom ise securit y because t he privat e dat abase links required for replicat ion use t he CONNECT TO clause, which m eans t hat usernam es and unencrypt ed passwords are visible in t he SYS.LI NK$ t able. The DBMS_REPCAT_AUTH.GRANT_SURROGATE_REPCAT procedure grant s t he account CREATE SESSI ON privileges, as well as t he obj ect privileges displayed by t he following query: SQL> 2 3 4*

SELECT owner, table_name, grantee, grantor, privilege FROM dba_tab_privs WHERE grantee = ' REPSYS' ORDER BY owner, table_name, grantee, grantor, privilege;

Table Granted Owner Table Name Grantee Privilege -------------------------- ---------SYS DBA_CONSTRAINTS REPSYS SELECT

Grantor ---------

--------

SYS

229

Oracle Distributed Systems SYS SELECT SYS SELECT SYS SELECT SYS SELECT SYS SELECT SYS SELECT SYS SELECT SYS EXECUTE SYS EXECUTE SYS EXECUTE SYS EXECUTE SYS EXECUTE SYS EXECUTE SYS EXECUTE SYS EXECUTE SYS EXECUTE SYS EXECUTE SYS EXECUTE SYS EXECUTE SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT SYSTEM UPDATE SYSTEM DELETE SYSTEM INSERT

DBA_CONS_COLUMNS

REPSYS

SYS

DBA_SOURCE

REPSYS

SYS

DBA_TABLESPACES

REPSYS

SYS

DBA_TAB_COLUMNS

REPSYS

SYS

DBA_TRIGGERS

REPSYS

SYS

DBA_USERS

REPSYS

SYS

DBA_VIEWS

REPSYS

SYS

DBMSOBJGWRAPPER

REPSYS

SYS

DBMS_DEFER

REPSYS

SYS

DBMS_DEFERGEN

REPSYS

SYS

DBMS_DEFER_INTERNAL_SYS

REPSYS

SYS

DBMS_REPCAT

REPSYS

SYS

DBMS_REPCAT_CONF

REPSYS

SYS

DBMS_REPCAT_MAS

REPSYS

SYS

DBMS_REPCAT_SNA

REPSYS

SYS

DBMS_REPCAT_SNA_UTL

REPSYS

SYS

DBMS_REPCAT_UTL

REPSYS

SYS

DBMS_REPCAT_UTL2

REPSYS

SYS

DBMS_REPCAT_UTL3

REPSYS

SYS

REPCAT$_AUDIT_ATTRIBUTE

REPSYS

SYSTEM

REPCAT$_AUDIT_ATTRIBUTE

REPSYS

SYSTEM

REPCAT$_AUDIT_ATTRIBUTE

REPSYS

SYSTEM

REPCAT$_AUDIT_COLUMN

REPSYS

SYSTEM

REPCAT$_AUDIT_COLUMN

REPSYS

SYSTEM

REPCAT$_AUDIT_COLUMN

REPSYS

SYSTEM

REPCAT$_AUDIT_COLUMN

REPSYS

SYSTEM

REPCAT$_COLUMN_GROUP

REPSYS

SYSTEM

REPCAT$_COLUMN_GROUP

REPSYS

SYSTEM

230

Oracle Distributed Systems SYSTEM SELECT SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT SYSTEM INSERT SYSTEM SELECT SYSTEM SELECT SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT SYSTEM SELECT SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT SYSTEM UPDATE SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT SYSTEM INSERT SYSTEM SELECT SYSTEM UPDATE SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT SYSTEM UPDATE

REPCAT$_COLUMN_GROUP

REPSYS

SYSTEM

REPCAT$_CONFLICT

REPSYS

SYSTEM

REPCAT$_CONFLICT

REPSYS

SYSTEM

REPCAT$_CONFLICT

REPSYS

SYSTEM

REPCAT$_DDL

REPSYS

SYSTEM

REPCAT$_DDL

REPSYS

SYSTEM

REPCAT$_GENERATED

REPSYS

SYSTEM

REPCAT$_GROUPED_COLUMN

REPSYS

SYSTEM

REPCAT$_GROUPED_COLUMN

REPSYS

SYSTEM

REPCAT$_GROUPED_COLUMN

REPSYS

SYSTEM

REPCAT$_KEY_COLUMNS

REPSYS

SYSTEM

REPCAT$_PARAMETER_COLUMN

REPSYS

SYSTEM

REPCAT$_PARAMETER_COLUMN

REPSYS

SYSTEM

REPCAT$_PARAMETER_COLUMN

REPSYS

SYSTEM

REPCAT$_PARAMETER_COLUMN

REPSYS

SYSTEM

REPCAT$_PRIORITY

REPSYS

SYSTEM

REPCAT$_PRIORITY

REPSYS

SYSTEM

REPCAT$_PRIORITY

REPSYS

SYSTEM

REPCAT$_PRIORITY_GROUP

REPSYS

SYSTEM

REPCAT$_PRIORITY_GROUP

REPSYS

SYSTEM

REPCAT$_PRIORITY_GROUP

REPSYS

SYSTEM

REPCAT$_REPCAT

REPSYS

SYSTEM

REPCAT$_REPCAT

REPSYS

SYSTEM

REPCAT$_REPCAT

REPSYS

SYSTEM

REPCAT$_REPCATLOG

REPSYS

SYSTEM

REPCAT$_REPCATLOG

REPSYS

SYSTEM

REPCAT$_REPCATLOG

REPSYS

SYSTEM

REPCAT$_REPCATLOG

REPSYS

SYSTEM

231

Oracle Distributed Systems SYSTEM SELECT SYSTEM UPDATE SYSTEM DELETE SYSTEM SELECT SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT SYSTEM UPDATE SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT SYSTEM DELETE SYSTEM INSERT SYSTEM SELECT

REPCAT$_REPOBJECT

REPSYS

SYSTEM

REPCAT$_REPOBJECT

REPSYS

SYSTEM

REPCAT$_REPPROP

REPSYS

SYSTEM

REPCAT$_REPPROP

REPSYS

SYSTEM

REPCAT$_REPSCHEMA

REPSYS

SYSTEM

REPCAT$_REPSCHEMA

REPSYS

SYSTEM

REPCAT$_REPSCHEMA

REPSYS

SYSTEM

REPCAT$_REPSCHEMA

REPSYS

SYSTEM

REPCAT$_RESOLUTION

REPSYS

SYSTEM

REPCAT$_RESOLUTION

REPSYS

SYSTEM

REPCAT$_RESOLUTION

REPSYS

SYSTEM

REPCAT$_RESOLUTION_METHOD

REPSYS

SYSTEM

REPCAT$_RESOLUTION_METHOD

REPSYS

SYSTEM

REPCAT$_RESOLUTION_METHOD

REPSYS

SYSTEM

71 rows selected. 8. Creat e privat e dat abase links from user SYS t o user REPSYS from each m ast er dat abase t o every ot her m ast er dat abase. As user SYS: CREATE DATABASE LINK PHQS.BIGWHEEL.COM CONNECT TO repsys IDENTIFIED BY surrogate; Not e t hat t hese privat e dat abase links do not include a USI NG clause. 9. Creat e replicat ion adm inist rat ion account s in each m ast er dat abase and grant t his account privileges t o adm inist er any replicat ion group and EXECUTE privileges on DBMS_DEFER. Typically, t he nam e for t his account is REPADMI N. As user SYS: CREATE USER repadmin IDENTIFIED BY replicator DEFAULT TABLESPACE USERS TEMPORARY TABLESPACE TEMP; EXECUTE dbms_repcat_admin.grant_admin_any_repgroup('REPADMIN'); GRANT EXECUTE ON dbms_defer TO repadmin WITH GRANT OPTION;

232

Oracle Distributed Systems I f you int end t o have m ult iple replicat ion groups and you wish t o adm inist er t hem under separat e account s, you m ay do so by grant ing adm inist rat ive privileges at t he replicat ion group level. These privileges m ust grant ed t o t he owner of t he replicat ed schem a, and t he replicat ion group m ust have t he sam e nam e as t he schem a owner: CREATE USER sprocket IDENTIFIED BY spokes DEFAULT TABLESPACE sprocket_data TEMPORARY TABLESPACE temp; EXECUTE dbms_repcat.grant_admin_repgroup('SPROCKET'); GRANT EXECUTE ON dbms_defer TO sprocket WITH GRANT OPTION; 10. Creat e privat e dat abase links from REPADMI N in each m ast er dat abase t o REPADMI N in every ot her m ast er dat abase. As user REPADMI N: CREATE DATABASE LINK PHQS.BIGWHEEL.COM CONNECT TO repadmin IDENTIFIED BY replicator; Again, not e t hat t hese links m ust be creat ed wit hout t he USI NG clause. 11. Creat e privat e dat abase links from t he account owning t he replicat ed t ables t o it s peer account in every ot her m ast er dat abase. For exam ple, if t he Oracle user SPROCKET owns t he replicat ed schem a, we would creat e links as follows: 12. CREATE DATABASE LINK PHQS.BIGWHEEL.COM CONNECT TO sprocket IDENTIFIED BY repschema; 13. Creat e privat e dat abase links for end users of t he replicat ed applicat ion: 14. CREATE DATABASE LINK PHQS.BIGWHEEL.COM CONNECT TO scott IDENTIFIED BY tiger; Not e t hat t he end users should have ident ical privileges on t he replicat ed schem a in all dat abases. I f a user changes his password in a dat abase, t hen his privat e dat abase links int o t hat dat abase m ust be dropped and re- creat ed. 15. Grant EXECUTE privileges on t he DBMS_DEFER package t o schem a owner account s and user account s in each dat abase. As user SYS in each m ast er dat abase: GRANT EXECUTE ON dbms_defer TO repadmin; GRANT EXECUTE ON dbms_defer TO scott; ... At t his point you are ready t o creat e replicat ed obj ect s on which users can perform DML. Chapt er 12, describes t he procedures for creat ing replicat ed obj ect s. Not e t hat t he execut e_as_user param et er m ust be set t o FALSE, t he default , in calls t o t he following procedures:

233

Oracle Distributed Systems DBMS_DEFER_SYS.EXECUTE DBMS_DEFER_SYS.SCHEDULE_EXECUTE DBMS_SNAPSHOT.REFRESH DBMS_REPCAT.RESUME_MASTER_ACTI VI TY DBMS_REPCAT.SUSPEND_MASTER_ACTI VI TY When an end user perform s DML against a t able, t he t able_nam e$RT t rigger on t he t able fires, queueing t he DML t o rem ot e sit es. Because t he owner of t he t able owns t his t rigger, t he t able owner queues t he deferred RPC. When Oracle pushes t he deferred RPC t o rem ot e sit es, it m akes a rem ot e connect ion via a dat abase link. Oracle first at t em pt s t o use a privat e link belonging t o t he I D t hat queued t he t ransact ion ( i.e., t he t able owner) . I f no such privat e dat abase link exist s, Oracle at t em pt s t o use a privat e dat abase link belonging t o t he connect ed user. The connect ed user is t he user t hat is pushing t he deferred RPC queue, t ypically REPADMI N. The I D t o which Oracle connect s at t he rem ot e dat abase m ust have EXECUTE privileges on t he t able_nam e$RP package at t he rem ot e sit e because t he deferred RPC is, in fact , a call t o t he t able_nam e$RP package. Bot h t he t able owner and t he REPADMI N account have sufficient privileges t o execut e t his package—t he form er because it owns t he package and t he lat t er because it has EXECUTE ANY PROCEDURE syst em privileges.

I f you are using synchronous replicat ion, DML is applied sim ult aneously t o t he rem ot e sit es; it is not queued. I f t he end user has a privat e dat abase link, t he user specified in t he link's CONNECT TO clause m ust have EXECUTE privileges on t he t able_nam e$RP package or EXECUTE ANY PROCEDURE syst em privileges.

1 0 .4 .2 Con figu r in g Or a cle 7 for t h e Globa l Acce ss M ode l I f your dat abase has t ens or hundreds of user account s, t he adm inist rat ion of dat abase links and passwords becom es quit e daunt ing, even im pract ical. Therefore, Oracle allows you t o use a single account in t he m ast er dat abases t o replicat e DML on behalf of all users. Not e t hat t his approach is sim pler and closely resem bles t he access m et hod used in Oracle8. The first six st eps of t he procedure for configuring t he global access m odel are t he sam e as t he m irrored access m odel. What you do not have t o do is t o creat e privat e dat abase links for end users. To force t he deferred t ransact ions, use t he REPADMI N account 's privat e dat abase link. The execut e_as_user param et er m ust be set t o TRUE in calls t o t he following procedures: DBMS_DEFER_SYS.EXECUTE DBMS_DEFER_SYS.SCHEDULE_EXECUTE

234

Oracle Distributed Systems DBMS_SNAPSHOT.REFRESH DBMS_REPCAT.RESUME_MASTER_ACTI VI TY DBMS_REPCAT.SUSPEND_MASTER_ACTI VI TY

1 0 .4 .3 Con figu r in g Or a cle 8 for Adva n ce d Re plica t ion The configurat ion of Oracle8 m ast er sit es is a hybrid m ix of t he Oracle7 m irrored access and global access m odels. Oracle8 designat es special propagat or and receiver account s, which process deferred RPCs. Gone are t he im m ense dat abase link adm inist rat ive chores and t he execut e_as_user param et er. I n general, an Oracle8 inst allat ion is m uch sim pler t han an Oracle7 inst allat ion. Aft er you have run cat rep.sql and cat repad.sql , follow t hese st eps: 1. Creat e anonym ous public dat abase links in every m ast er dat abase t o every ot her m ast er dat abase: 2. CREATE PUBLIC DATABASE LINK PHQS.BIGWHEEL.COM using 'prodhq'; 3. Creat e a replicat ion adm inist rat or account in each m ast er dat abase. Typically, t his account is nam ed REPADMI N. As user SYS: CREATE USER repadmin IDENTIFIED BY replicator DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; EXECUTE dbms_repcat_admin.grant_admin_any_schema('REPADMIN'); I f you plan t o have m ult iple replicat ion groups and wish t o adm inist er t hem separat ely, you can grant adm inist rat ive privileges t o a specific schem a: EXECUTE dbms_repcat_admin.grant_admin_schema('SPROCKET') This call grant s t he SPROCKET account privileges t o perform adm inist rat ive t asks on replicat ed obj ect s in t he SPROCKET schem a. Not e t hat t he use of separat e adm inist rat ive account s works only if t he replicat ion group does not span m ult iple schem a. 4. Creat e privat e dat abase links from t he replicat ion adm inist rat or account ( s) creat ed in St ep 2 from each m ast er dat abase t o every ot her m ast er dat abase. Not e t hat t hese links m ust be creat ed wit hout specifying a USI NG clause: 5. CREATE DATABASE LINK PHQS.BIGWHEEL.COM CONNECT TO repadmin IDENTIFIED BY replicator; 6. Creat e propagat or and receiver accounts in each m ast er dat abase, and grant t he account s privileges t o perform replicat ed DML: 7. CREATE USER proprep IDENTIFIED BY pusher 8. DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; 9. EXECUTE dbms_defer_sys.register_propagator('PROPREP');

235

Oracle Distributed Systems The DBMS_DEFER_SYS.REGI STER_PROPAGATOR procedure grant s t he following privileges t o t he grant ee: CREATE SESSI ON CREATE DATABASE LI NK CREATE PROCEDURE EXECUTE ANY PROCEDURE Usually we use t he propagat or account t o bot h propagat e and receive replicat ed DML, but you can also creat e a separat e receiver account if you desire a m ore granular securit y policy: CREATE USER recvrep IDENTIFIED BY receiver DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; GRANT CREATE SESSION TO recvrep; GRANT EXECUTE ANY PROCEDURE TO recvrep; You can designat e only one propagat or account per dat abase inst ance, regardless of t he num ber of replicat ion groups. 10. Creat e privat e dat abase links from t he propagat or account in each m ast er dat abase t o t he designat ed receiver account in every ot her m ast er dat abase. 11. CREATE DATABASE LINK PHQS.BIGWHEEL.COM CONNECT TO proprep IDENTIFIED BY pusher; You are now ready t o creat e replicat ion groups and obj ect s. See Chapt er 12 for det ails.

236

Oracle Distributed Systems

Ch a pt e r 1 1 . Ba sic Re plica t ion The origin of Oracle's replicat ion t echnology is t he read- only snapshot feat ure, which shipped wit h t he first Oracle7 release. Read- only snapshot s, also known as basic replicat ion, are essent ially t ables t hat hold t he result set of a query on a rem ot e dat abase. We usually configure t he snapshot t o refresh t he result set at a predet erm ined int erval so t hat t he dat a is current .

1 1 .1 Abou t Re a d- On ly Sn a psh ot s Read- only snapshot s provide a m eans t o access rem ot e dat a wit hout requiring a const ant net work connect ion. They are int ended t o m aint ain local inst ances of dat a t hat t he rem ot e m ast er sit e m aint ains. Exam ples of t he appropriat e use of read- only snapshot s include t he following: • • •

•

A regional sales office has a snapshot of t he PRODUCT_PRI CES t able which t he headquart ers sit e m aint ains. The snapshot is refreshed once a m ont h, when prices change. A ret ailer's dat a warehouse perform s a snapshot of t he DAI LY_REGI STER_RECEI PTS t able as part of t he night ly dat a ext ract ion process. A billing syst em perform s a snapshot of t he CUSTOMER_ADDRESS t able prior t o each invoice run so t hat t he bills are m ailed t o t he correct addresses. A salesperson wit h a lapt op connect s t o t he m ast er sales dat abase and refreshes a snapshot of t he subset of t he CUSTOMER_LEAD t able corresponding t o her sales region.

Not ice t hat in each case t he snapshot is refreshed at an int erval t hat ensures accurat e business processing and t hat t he m ast er sit e " owns" t he dat a—t hat is, only t he m ast er sit e can m odify t he dat a. The basic procedure for creat ing read- only snapshot s is as follows: 1. I dent ify t he t able( s) at t he m ast er sit e( s) t hat you want t o replicat e t o t he snapshot sit e and t he schem a t hat will own t he snapshot s. Generally, t he schem a t hat owns t he snapshot s should have t he sam e nam e as t he schem a t hat owns t he m ast er t able; alt hough t his is not a requirem ent , it sim plifies adm inist rat ion. 2. Creat e dat abase link( s) from t he snapshot sit e t o t he m ast er sit es. These should be privat e dat abase links owned by t he snapshot owner. The dat abase links m ust connect t o an account in t he m ast er dat abase t hat has sufficient privileges t o issue t he snapshot query. 3. Creat e snapshot logs in t he m ast er dat abase for every m ast er t able. Snapshot logs are required for FAST refreshes. Snapshot logs are not required for COMPLETE refreshes. 4. Use t he CREATE SNAPSHOT st at em ent t o creat e t he snapshot ( s) . 5. Creat e one or m ore refresh groups at t he snapshot sit e and assign each snapshot t o a group. This st ep is opt ional but recom m ended. 6. Grant privileges as appropriat e t o ot her roles or account s in t he snapshot dat abase so t hat t hey can query t he snapshot .

237

Oracle Distributed Systems

1 1 .2 Pr e r e qu isit e s a n d Re st r ict ion s Read- only snapshot s do not require t he advanced replicat ion facilit ies. You m ust , however, have t he Procedural Opt ion inst alled ( i.e., t he cat alog script cat proc.sql m ust have been run) , and t he script s dbm ssnap.sql and prvt snap.plb m ust have been run. ( Oracle runs t hese script s aut om at ically when you inst all t he Procedural Opt ion by running cat proc.sql.) You also m ust set init ializat ion param et ers and grant appropriat e syst em privileges t o account s t hat creat e snapshot s.

1 1 .2 .1 I n it ia liza t ion Pa r a m e t e r s I n order for snapshot s t o be capable ofrefreshing aut om at ically, you m ust set t he following init ializat ion param et ers: JOB_QUEUE_PROCESSES This param et er should be set t o at least 1. The default is 0. JOB_QUEUE_I NTERVAL This param et er should be set t o a value t hat is less t han or equal t o your m ost frequent snapshot int erval. The default is 60; t he unit s are seconds.

1 1 .2 .2 Syst e m Pr ivile ge s The following syst em privileges are associat ed wit h snapshot adm inist rat ion: ALTER ANY SNAPSHOT The grant ee can change various propert ies of snapshot s in any schem a. You should reserve t his privilege for DBA account s; it is grant ed t o t he DBA role when t he dat abase is creat ed. CREATE ANY SNAPSHOT The grant ee can creat e a snapshot in any schem a. You should reserve t his privilege for DBA account s; it is grant ed t o t he roles DBA and I MP_FULL_DATABASE when t he dat abase is creat ed. CREATE DATABASE LI NK The grant ee can creat e and drop privat e dat abase links. Technically, t his privilege is not required t o creat e a snapshot because t he connect ion t o t he m ast er sit e could be over a public dat abase link. However, for securit y's sake, snapshot s should always use privat e dat abase links. Of course, t he account t o which t he dat abase link connect s m ust have adequat e privileges on t he m ast er t able( s) t o execut e t he snapshot 's defining query. CREATE SNAPSHOT

238

Oracle Distributed Systems The grant ee can creat e, alt er, and drop snapshot s under it s own schem a— t hat is, t he account owns and can adm inist er what ever snapshot s it creat es. This is t he appropriat e privilege for schem a owner account s. CREATE VI EW The grant ee can creat e views. This privilege is required because snapshot s consist of an underlying t able t hat m ay cont ain t he ROWI D of t he m ast er t able and a view on t he underlying t able t hat cont ains only t he fields act ually queried. DROP ANY SNAPSHOT The grant ee can drop snapshot s from any schem a. You should reserve t his privilege for DBA account s; it is grant ed t o t he roles DBA and I MP_FULL_DATABASE when t he dat abase is creat ed. I n addit ion t o t hese syst em privileges, t he snapshot creat or m ust also have a sufficient space quot a in t he t ablespace( s) t hat will cont ain t he snapshot base t able and any indexes on t his t able.

1 1 .2 .3 Re st r ict ion s Snapshot queries can select from SYS- owned t ables or views, and t hey cannot cont ain colum ns of t ype LONG, LONG RAW, BFI LE, or any user- defined dat at ypes. Oracle8 creat es prim ary key snapshot s by default . The m ast er t able of prim ary key snapshot s m ust have a prim ary key defined and enabled, and t he snapshot 's defining query m ust cont ain all fields of t he prim ary key.

1 1 .3 Sn a psh ot Cr e a t ion Ba sics The CREATESNAPSHOT synt ax cont ains several com ponent s, allowing t he creat or t o m anipulat e t he snapshot 's physical st orage, it s refresh int erval, and even what rollback segm ent s t o use when it refreshes if you are using Oracle8. Let 's exam ine t he com ponent s of t his st at em ent one at a t im e, using t he following snapshot creat ion st at em ent as a sam ple ( line num bers are included for reference) : 1 2 3 4 5 6 7 8 9 10 11 12 13

CREATE SNAPSHOT product_prices PCTFREE 0 PCTUSED 99 TABLESPACE sprocket_data STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0) USING INDEX TABLESPACE sprocket_indx STORAGE (INITIAL 128K NEXT 128K PCTINCREASE 0) REFRESH FAST START WITH sysdate NEXT sysdate + 1 WITH PRIMARY KEY USING LOCAL ROLLBACK SEGMENT rb_large AS SELECT product_id,

239

Oracle Distributed Systems 14 15 16 17

catalog_number, price, effective_date FROM [email protected];

This st at em ent creat es a snapshot of t he PRODUCT_PRI CES t able, m ast ered in dat abase PHQS.BI GWHEEL.COM.

1 1 .3 .1 Th e Sn a psh ot STORAGE Cla u se Lines 1 t hrough 6 specify t he nam e of t he snapshot , PRODUCT_PRI CES, and specify st orage param et ers for t he snapshot 's base t able and t he prim ary key index: 1 2 3 4 5 6

CREATE SNAPSHOT product_prices PCTFREE 0 PCTUSED 99 TABLESPACE sprocket_data STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0) USING INDEX TABLESPACE sprocket_indx STORAGE (INITIAL 128K NEXT 128K PCTINCREASE 0)

The prim ary key index is an Oracle8 feat ure; t he USI NG I NDEX synt ax does not exist in Oracle7.

You will not ice t hat we chose ext rem e values for PCTFREE and PCTUSED, and 99, respect ively. Recall t hat t hese st orage param et ers govern t he m inim um am ount of free space Oracle reserves in each block. This free space provides growing room for records t hat are updat ed. I f m ore t han PCTFREE percent of a block is em pt y, t he block will be on t he free list , which m eans t hat m ore records can be added t o t he block. Sim ilarly, PCTUSED is t he m axim um am ount of space t hat dat a can consum e in a block. Set t ing PCTFREE t o and PCTUSED t o 99 t ells Oracle t o pack each block as full of dat a as possible; do not leave any free space for updat es. We need not be concerned wit h updat es because dat a in read- only snapshot s is never updat ed, not even by t he refresh procedure. ( Snapshot refreshes perform updat es by delet ing t he old record and reinsert ing it wit h it s new values.) Packing t he dat a as t ight ly as possible m inim izes t he am ount of space required for a snapshot 's st orage, and we can expect som e gains in query perform ance against t he snapshot . I n addit ion t o t he PCTFREE and PCTUSED param et ers, t he t ablespace in which t o put t he snapshot base t able is specified ( SNAP$_PRODUCT_PRI CES in t his case) , as well as t he size of it s init ial and next ext ent s and t he percent by which subsequent ext ent s should grow. I deally, t he t able will fit int o a single ext ent .

240

Oracle Distributed Systems

Measure t he st orage allocat ed t o t he m ast er t able so t hat you can set t he snapshot 's st orage param et ers appropriat ely. Rem em ber t hat t he snapshot will m ost likely occupy less space t han t he m ast er t able if you use PCTFREE and PCTUSED 99.

The last port ion of t he STORAGE clause cont rols t he st orage of t he prim ary key index, a feat ure available in Oracle8. I n general, it is a wise pract ice t o place indexes in separat e t ablespaces from t heir dat a. Every schem a owner should ut ilize at least t wo t ablespaces, one for dat a and one for indexes. This exam ple uses t ablespace SPROCKET_DATA and SPROCKET_I NDX.

1 1 .3 .2 Th e REFRESH Cla u se The REFRESH clause cont rols t he t im e of t he init ial refresh, as well as t he m et hod and frequency of subsequent refreshes: 7 8 9 10 11

REFRESH FAST START WITH sysdate NEXT sysdate + 1 WITH PRIMARY KEY USING LOCAL ROLLBACK SEGMENT rb_large

I f you are using Oracle8, you can also specify t he snapshot t ype, PRI MARY KEY ( t he default ) or ROWI D. Oracle8 also allows you t o specify a rollback segm ent t o use during t he snapshot refresh.

I f you plan t o add t he snapshot t o a snapshot refresh group, t hen you should not specify a value for t he NEXT refresh. I f you do, t he snapshot will refresh at t he int erval defined in t he CREATE SNAPSHOT st at em ent inst ead of t he int erval defined for t he refresh group.

You can specify one of t hree refresh m et hods in t he REFRESH clause: FAST A FAST snapshot refresh queries t he snapshot log on t he m ast er t able t o det erm ine what records are new or have been m odified since t he previous refresh. Only t hese records are brought over t o t he snapshot sit e. FAST refreshes are possible only wit h sim ple snapshot s ( i.e., snapshot s t hat query a single m ast er t able and t hat do not perform aggregat ion funct ions) . FAST refreshes also require a snapshot log on t he m ast er t able t hat predat es t he snapshot .

241

Oracle Distributed Systems COMPLETE A com plet e refresh reinst ant iat es t he snapshot from scrat ch. Oracle m ust use t he COMPLETE m et hod for com plex snapshot s and snapshot s whose m ast er t able does not have a preexist ing snapshot log ( or any snapshot log at all) . FORCE You can specify REFRESH FORCE in t he REFRESH clause t o direct Oracle t o perform a FAST refresh if possible and a COMPLETE refresh if necessary. The FORCE m et hod avoids errors t hat occur when t he FAST m et hod is specified but not possible.

1 1 .3 .3 Th e D e fin in g Qu e r y The last elem ent of t he CREATE SNAPSHOT st at em ent is t he defining query: 12 13 14 15 16 17

AS SELECT

product_id, catalog_number, price, effective_date FROM [email protected];

The result set of t he query is st ored in t he snapshot base t able. Any query t hat does not select fields of t ype LONG, LONG RAW, or user- defined dat at ypes and t hat does not cont ain an ORDER BY clause is valid as a snapshot 's defining query. However, not all queries can be refreshed wit h t he FAST REFRESH m et hod.

Re fe r e n cin g Re m ot e Ta ble s Oracle's docum ent at ion recom m ends t hat t he defining query reference t able nam es in t he form owner.t able_nam e. This way, you can be sure of what t he m ast er t able is and not m ist akenly point t o t he wrong t able because a synonym changed. We discourage t his pract ice because it com es at t he expense of flexibilit y. Of course, you do need t o be m indful of what t ables are visible over t he dat abase link t hat you use t o creat e and t o refresh snapshot s, but t hese are det ails over which t he DBA has cont rol, part icularly in a product ion environm ent .

1 1 .4 Sim ple Ve r su s Com ple x Sn a psh ot s Sim ple snapshot s are t he only t ype t hat can use t he FAST REFRESH m et hod. A snapshot is considered sim ple if t he defining query m eet s t he following crit eria:

242

Oracle Distributed Systems • • • •

It It It It

does does does does

not not not not

cont ain any DI STI NCT or aggregat ion funct ions. cont ain a GROUP BY or CONNECT BY clause. perform set operat ions ( UNI ON, UNI ON ALL, I NTERSECT, et c.) . perform j oins ot her t han t hose used for subquery subset t ing.

Essent ially, a sim ple snapshot is one t hat select s from a single t able and t hat m ay or m ay not use a WHERE clause.

Oracle8 ext ends t he universe of sim ple snapshot s wit h a feat ure known as subquery subset t ing, described in t he lat er sect ion ent it led " Subquery Subset t ing."

Not surprisingly, any snapshot t hat is not a sim ple snapshot is a com plex snapshot . Com plex snapshot s can only use COMPLETE refreshes, which are not always pract ical. For t ables of m ore t han about 100,000 rows, COMPLETE refreshes can be quit e unwieldy. You can oft en avoid t his sit uat ion by creat ing sim ple snapshot s of individual t ables at t he m ast er sit e and perform ing t he offending query against t he local snapshot s. For exam ple, avoid creat ing a com plex snapshot such as t he following: CREATE SNAPSHOT sales_by_region REFRESH COMPLETE START WITH sysdate NEXT sysdate + 1 AS SELECT r.region_name, r.sales_rep, p.product_id, count(*) num_sold, sum(sales_price) FROM [email protected] p, [email protected] r WHERE p.region_id = r.region_id which m ust reinst ant iat e t he snapshot com plet ely wit h every refresh. I nst ead, sim ply creat e t wo sim ple snapshot s, one on t he PRODUCT_SALES t able and t he ot her on t he REGI ONS t able. Bot h snapshot s can use a FAST refresh, and you can issue t he desired query locally.

1 1 .5 Sn a psh ot Logs Asnapshot log is a t able t hat resides at t he m ast er sit e and t hat keeps t rack of changes t o a m ast er t able. The nam e of t he snapshot log t able is MLOG$_m ast er_t able_nam e. Snapshot logs m ake FAST refreshes possible because t he refresh process can consult t he snapshot log t o det erm ine which rows have changed since t he previous refresh; it t hen applies only t hese changes inst ead of replacing every record in t he snapshot . I n ot her words, snapshot logs enable t he use of FAST refreshes. For t ables wit h m ore t han 100,000 records, a FAST refresh is t he only viable m eans of m aint aining a snapshot .

243

Oracle Distributed Systems

I n order for Oracle t o ut ilize t he FAST refresh m echanism , t he snapshot log m ust be creat ed at t he m ast er sit e before t he snapshot it self.

1 1 .5 .1 Re st r ict ion s on Sn a psh ot Logs Pleasenot e t hat in Oracle8, which uses prim ary keys t o ident ify records in t he m ast er t able, t he m ast er t able m ust have a prim ary key defined and enabled in order t o creat e a snapshot log.

1 1 .5 .2 Cr e a t ion Tips Records in a snapshot log are never updat ed, so you should creat e t hem wit h st orage param et ers t hat pack records as t ight ly as possible so you will realize t he best perform ance and m ost efficient use of space.

1 1 .5 .3 Sn a psh ot Logs for ROW I D Sn a psh ot s I f your m ast er t able is in an Oracle8 dat abase and t he snapshot eit her is in an Oracle7 dat abase or was creat ed using t he WI TH ROWI D opt ion, t hen you m ust also creat e t he snapshot log using t he WI TH ROWI D opt ion. Try t o use prim ary key snapshot s whenever possible because of t he flexibilit y t hey im part t o rout ine t asks such as reorganizing t he m ast er t able or t he snapshot base t able. Not e t hat snapshot s logs can cont ain bot h ROWI Ds and prim ary keys in order t o support bot h Oracle7 and Oracle8 snapshot s.

1 1 .6 Su bqu e r y Su bse t t in g Subquery subset t ing is one of t he m ost significant feat ure addit ions t o replicat ion in Oracle8. This is a m et hod t hat allows you t o creat e snapshot sit es cont aining only t he dat a t hat is locally relevant wit hout having t o have a dist inguishing key in every t able for which you creat e a snapshot . For exam ple, an order fulfillm ent cent er m ight process orders only from cust om ers in California, yet it needs dat a from t ables CUSTOMERS, ORDERS, and ORDER_I TEMS. The challenge is t o creat e snapshot s of t he ORDERS and ORDER_I TEMS t ables t hat cont ain dat a for t he California cust om ers only. However, t he ORDERS t able has a cust om er_id field and no st at e field, while t he ORDER_I TEMS t able doesn't even have a cust om er_id field. I n ot her words, t he schem a is norm alized. Clearly adding and m aint aining a st at e field in t he ORDERS and ORDER_I TEMS t able would be awkward at best . Rat her t han denorm alize t he schem a by put t ing t he st at e field in all of t he t ables for which you creat ed a snapshot , we can use a subquery subset snapshot , which t akes advant age of foreign keys defined on t he t ables t o det erm ine which records of t he ORDERS and ORDER_I TEMS t ables t he snapshot sit e needs t o see. We can creat e t he snapshot s as follows:

244

Oracle Distributed Systems 1. Creat e a snapshot on t he CUSTOMERS t able cont aining only t he records where st at e = CA: 2. CREATE SNAPSHOT customers 3. REFRESH FAST 4. START WITH sysdate 5. NEXT sysdate + 1 6. AS 7. SELECT customer_id, 8. sales_rep_id, 9. first_name, 10. last_name, 11. addr_line_1, 12. addr_line_2, 13. city, 14. state, 15. zip 16. FROM [email protected] WHERE state = 'CA'; 17. Creat e a subquery subset snapshot on ORDERS cont aining only t he orders associat ed wit h cust om ers from California: 18. CREATE SNAPSHOT orders 19. REFRESH FAST 20. START WITH sysdate 21. NEXT sysdate + 1 22. AS 23. SELECT order_id, 24. customer_id, 25. purchase_order_id, 26. order_date, 27. order_taker, 28. status 29. FROM [email protected] o 30. WHERE EXISTS (SELECT customer_id 31. FROM [email protected] c 32. WHERE c.customer_id = o.customer_id AND c.state = 'CA'); 33. Creat e a subquery subset snapshot on t he ORDER_I TEMS t able cont aining only t he records associat ed wit h t he orders for California cust om ers: 34. CREATE SNAPSHOT order_items 35. REFRESH FAST 36. START WITH sysdate 37. NEXT sysdate + 1 38. AS 39. SELECT order_line_id, 40. order_id, 41. item_number, 42. product_id, 43. quantity, 44. unit_of_measure, 45. unit_price, 46. extended_price, 47. status 48. FROM [email protected] i 49. WHERE EXISTS (SELECT order_id

245

Oracle Distributed Systems 50. 51. 52. 53. c 54. o.customer_id

FROM [email protected] o WHERE i.order_id = o.order_id AND EXISTS (SELECT customer_id FROM [email protected] WHERE AND

c.customer_id = c.state = 'CA'));

Thus, we have creat ed t hree separat e snapshot s t hat obt ain t he subset of dat a t he snapshot sit e requires wit hout having t o denorm alize t he schem a or m odify t he applicat ion code in any way. I n ot her words, we can creat e a snapshot for records associat ed wit h t he filt er colum n st at e even t hough t he m ast er t ables ORDERS and ORDER_I TEMS do not cont ain t he filt er colum n. Not ice t hat t hese snapshot s can all use t he FAST refresh ( assum ing t hat t he m aster t ables have snapshot logs defined) .

Updat es t o t he filer colum n, t hough perm it t ed, should be avoided.

1 1 .6 .1 Re st r ict ion s on Su bqu e r y Su bse t s Of course, not all operat ions or relat ionships can benefit from subquery snapshot s. Specifically,subquery subset t ing works only if t he following rest rict ions are m et : •

• • •

•

•

• •

The defining query does not include explicit j oins, aggregat ion operat ions, set operat ions, GROUP BY, HAVI NG, or CONNECT BY. Each m ast er t able referenced in t he defining query m ust have a prim ary key. All m ast er t ables m ust reside in t he sam e dat abase inst ance. All subqueries m ust be posit ive and form ulat ed wit h t he EXI STS clause—t hat is, explicit j oins and NOT EXI STS are not perm it t ed. The subqueries m ust use equij oins on colum ns t hat have a m any- t o- one relat ionship. All m ast er t ables referenced in t he defining query m ust have a snapshot log, even if you are using a COMPLETE refresh. Snapshot logs m ust cont ain prim ary key values. Snapshot logs m ust cont ain all filt er colum ns.

1 1 .6 .2 Su bqu e r y Su bse t Sn a psh ot Ba se Ta ble s You will not ice t hat t he base t able of subquery subset snapshot s cont ains fields in addit ion t o t hose of t he m ast er t able. For exam ple, t he ORDER_I TEMS snapshot base t able, SNAP$_ORDER_I TEMS, cont ains a cust om er_id field. Snapshot base t ables m ust cont ain t he prim ary key values of each t able referenced in t he subquery. Oracle aut om at ically adds t hese fields if and only if t hey are not part of t he SELECT list in t he snapshot 's defining query. I n addit ion, Oracle aut om at ically creat es indexes on t hese hidden colum ns when t he snapshot is creat ed.

246

Oracle Distributed Systems

1 1 .6 .3 A Spe cia l Ca se I n t he previous exam ple, ORDERS and ORDER_I TEMS records were filt ered t o t hose associat ed wit h cust om ers in California. Suppose we wish t o furt her rest rict t he query t o California cust om ers whose sales represent at ive is John Sm it h. Assum e a m any- t o- m any relat ionship bet ween t he CUSTOMERS t able and t he SALES_REPS t able. I n ot her words, a sales represent at ive can handle m any cust om ers, and a given cust om er m ay have m ore t han one represent at ive. The CUSTOMER_REP_I NTERSECT t able resolves t he m any- t o- m any relat ionship bet ween CUSTOMERS and SALES_REPS. Oracle's subquery subset t ing allows us t o snapshot dat a associat ed wit h cust om ers m eet ing t wo rest rict ions: t hey are from California, and t heir sales rep is John Sm it h. The snapshot on t he ORDER_I TEMS t able would be defined as follows: CREATE SNAPSHOT order_items REFRESH FAST START WITH sysdate NEXT sysdate + 1 AS SELECT order_line_id, order_id, item_number, product_id, quantity, unit_of_measure, unit_price, extended_price, status FROM [email protected] i WHERE EXISTS (SELECT order_id FROM [email protected] o WHERE i.order_id = o.order_id AND EXISTS (SELECT customer_id FROM [email protected] c WHERE c.customer_id = o.customer_id AND c.state = 'CA' AND EXISTS (SELECT sales_rep_id FROM customer_rep_intersect i WHERE i.customer_id = c.customer_id AND EXISTS (SELECT sales_rep_id FROM sales_reps r WHERE r.sales_rep_id = i.sales_rep_id AND r.rep_name = 'John Smith')))) While subquery subset snapshot s of t his com plexit y are possible, t here does com e a point where t he perform ance of t he subquery snapshot lags behind t hat of snapshot s cont aining all records from a m ast er t able. You will have t o experim ent t o det erm ine which approach works bet t er for you.

247

Oracle Distributed Systems

1 1 .7 Re fr e sh Gr ou ps As in t he previous exam ple, oft en you need snapshot s on a group of relat ed t ables, which m ay have int erdependencies. I f you refresh snapshot s individually, t he result ing dat a is not guarant eed t o have a point - in- t im e consist ency; in fact , it probably will not . For exam ple, if we were t o refresh t he ORDER_I TEMS snapshot followed by t he ORDERS t able, we could end up wit h ent ries in ORDERS t hat have no corresponding ent ries in ORDER_I TEMS if users creat e orders while t he ORDER_I TEMS t able refreshes. Obviously, t his is not an accept able st at e of affairs. Oracle uses t heconcept of a refresh group t o encapsulat e snapshot s t hat m ust have point - in- t im e consist ency. You are guarant eed t hat all snapshot s in a single refresh group will be refreshed wit h dat a from t he m ast er t ables as of a single point in t im e. I n addit ion, refresh groups provide ease of m anagem ent because Oracle includes a variet y of built - in procedures in t he package DBMS_REFRESH for t heir m aint enance. The following procedures m anipulat e refresh groups at t he snapshot sit e: DBMS_REFRESH.ADD Adds a snapshot t o an exist ing group. DBMS_REFRESH. CHANGE Modifies propert ies of a refresh group, such as refresh int erval, next refresh t im e, and so on. DBMS_REFRESH.DESTROY Drops a refresh group. DBMS_REFRESH. MAKE Creat es a refresh group. DBMS_REFRESH. SUBTRACT Rem oves a snapshot from an exist ing refresh group. The following sect ions provide brief exam ples of using t hese procedures; refer t o Appendix A, for t he com plet e API reference t o t hese procedures.

Refresh groups are applicable t o updat eable snapshot s as well as t o read- only snapshot s.

248

Oracle Distributed Systems

1 1 .7 .1 Cr e a t in g a n d D e st r oyin g Re fr e sh Gr ou ps Use t he built - in package procedure DBMS_REFRESH.MAKE t o creat e a refresh group and DBMS_REFRESH.DESTROY t o drop it ; execut e bot h of t hese procedures from t he snapshot sit e. The following exam ples illust rat e t heir use.

1 1 .7 .1 .1 Cr e a t in g a sn a psh ot r e fr e sh gr ou p of r e a d- on ly sn a psh ot s This exam ple shows t he sim plest invocat ion of DBMS_REFRESH.MAKE; default s are used for all param et ers possible. This call creat es a refresh group on four relat ed t ables and schedules t hem t o be refreshed every day at m idnight : DECLARE vSnapshotList dbms_utility.uncl_array; BEGIN vSnapshotList(1) := 'CUSTOMERS'; vSnapshotList(2) := 'ORDERS'; vSnapshotList(3) := 'ORDER_ITEMS'; vSnapshotList(4) := 'CUSTOMER_REP_INTERSECT'; DBMS_REFRESH.MAKE(

name => 'SG_CUST_ORDERS', tab => vSnapShotList, next_date => TRUNC(sysdate) + 1, interval => 'SYSDATE + 1');

END;

1 1 .7 .1 .2 Cr e a t in g a sn a psh ot r e fr e sh gr ou p of r e a d- on ly sn a psh ot s w it h spe cia lize d pa r a m e t e r s DECLARE vSnapshotList dbms_utility.uncl_array BEGIN vSnapshotList(1) = 'CUSTOMERS' vSnapshotList(2) = 'ORDERS' vSnapshotList(3) = 'ORDER_ITEMS' vSnapshotList(4) = 'CUSTOMER_REP_INTERSECT' DBMS_REFRESH.MAKE(

name => 'SG_CUST_ORDERS', tab => vSnapShotList, next_date => TRUNC(sysdate) + 1, interval => 'SYSDATE + 1', implicit_destroy => TRUE, lax => TRUE, rollback_segment 'RB1');

END; This exam ple creat es t he sam e refresh group as in t he first exam ple but wit h t he following addit ional propert ies: im plicit _dest roy = > TRUE

249

Oracle Distributed Systems This set t ing causes t he refresh group SG_CUST_ORDERS t o be dest royed if all of t he snapshot s in t he group are dropped. The default behavior is t o preserve t he refresh group, even if it has no m em bers. lax = > TRUE I f any of t he snapshot s being added t o SG_CUST_ORDERS exist in anot her refresh group, t his set t ing inst ruct s Oracle t o rem ove t hem from t he ot her group before adding t hem t o t he new group. A snapshot cannot be a m em ber of m ore t han one refresh group. rollback_segm ent = > 'RB1' This set t ing causes Oracle t o use rollback segm ent RB1 whenever it refreshes refresh group SG_CUST_ORDERS. You should consider specifying rollback segm ent s if your snapshot refreshes result in long t ransact ions requiring a large rollback segm ent .

1 1 .7 .1 .3 Cr e a t in g a sn a psh ot r e fr e sh gr ou p t h a t u se s pa r a lle l pr opa ga t ion ( Or a cle 8 on ly) This exam ple set s parallelism t o 4, so t hat Oracle uses four processes t o perform t he refresh: DECLARE vSnapshotList dbms_utility.uncl_array BEGIN vSnapshotList(1) = 'CUSTOMERS' vSnapshotList(2) = 'ORDERS' vSnapshotList(3) = 'ORDER_ITEMS' vSnapshotList(4) = 'CUSTOMER_REP_INTERSECT' DBMS_REFRESH.MAKE(

name => 'SG_CUST_ORDERS', tab => vSnapShotList, next_date => TRUNC(sysdate) + 1, interval => 'SYSDATE + 1', parallelism => 4,);

END;

I n order t o t ake advant age of parallel propagat ion, you m ust have parallel query slave background processes running. The num ber of processes is cont rolled by t he init ializat ion param et ers PARALLEL_MI N_SERVERS and PARALLEL_MAX_SERVERS.

1 1 .7 .1 .4 D r oppin g a r e fr e sh gr ou p This exam ple dest roys t he snapshot group SG_CUST_ORDERS. I t does not drop t he m em ber snapshot s t hem selves; however, t hey will not be refreshed again unless you

250

Oracle Distributed Systems eit her add t hem t o anot her snapshot group or refresh t hem m anually wit h DBMS_SNAPSHOT.REFRESH: BEGIN DBMS_REFRESH.DESTROY(name => 'SG_CUST_ORDERS' ); END;

1 1 .8 M a n a ge m e n t a n d Opt im iza t ion Snapshot s require a cert ain am ount of DBA at t ent ion in order t o keep t hem running opt im ally. I n addit ion, Oracle provides packaged procedures t o render t he DBA's responsibilit ies less t axing. This sect ion discusses your opt ions for squeezing opt im al perform ance out of snapshot s and offers som e com m on solut ions t o com m on problem s.

1 1 .8 .1 Tu n in g Sn a psh ot s Sect ion 11.3 recom m ended t hat you select PCTFREE and PCTUSED set t ings t hat will pack t he dat a in your read- only snapshot base t ables as t ight ly as possible, t hus preserving disk space and reducing t he expense of scanning t he t able. You can also t ake t he following st eps t o enhance t he perform ance of queries against t he snapshot base t ables and t he snapshot refresh it self: I ndex t he snapshot base t able You can place indexes on t he colum ns of t he snapshot base t able t o enhance t he perform ance of your applicat ion's queries. Not e, however, t hat you cannot use unique indexes if you are using Oracle7; if you are using Oracle8, unique const raint s m ust be deferrable. This rest rict ion exist s because uniqueness is not guarant eed during t he period of t he act ual snapshot refresh. Clust er read- only snapshot base t ables I f you snapshot several t ables t hat share com m on keys, consider using a clust er index for t he key as was done in t he CUSTOMERS, ORDERS, ORDER_I TEMS exam ple. Tune t he defining query When you creat e subquery subset snapshot s, be sure t hat t he defining query is opt im ized. You can creat e t he appropriat e indexes on t he m ast er t ables and/ or use EXPLAI N PLAN, TKPROF, or anot her ut ilit y t o t une t he st at em ent s t hem selves. Analyze t he snapshot log I f you are using t he cost - based opt im izer, be sure t o ANALYZE t he snapshot log t ables at t he m ast er sit e. Oracle recom m ends analyzing t he snapshot log when it is em pt y or nearly so.

251

Oracle Distributed Systems

1 1 .8 .2 Adm in ist r a t ive Ta sk s The DBMS_REFRESH and DBMS_SNAPSHOT built - in packages include a variet y of rout ines t he DBA can use t o m anage snapshot s and snapshot logs. I n addit ion t o t he procedures m ent ioned for m aint aining snapshot logs and refresh groups, t he following procedures are available: DBMS_REFRESH.REFRESH Refreshes a snapshot refresh group. DBMS_REFRESH.USER_EXPORT Produces t he SQL st at em ent required t o creat e a given refresh group ( Oracle8 only) . DBMS_REFRESH.USER_EXPORT_CHI LD Produces t he SQL st at em ent required t o creat e a given snapshot wit hin a refresh group ( Oracle8 only) . DBMS_SNAPSHOT.REFRESH Refreshes a specific snapshot . DBMS_SNAPSHOT.REFRESH_ALL Refreshes all snapshot s t hat are due t o be refreshed. DBMS_SNAPSHOT.I _AM_A_REFRESH Queries a st at e variable for a session t o det erm ine whet her it is act ing on behalf of a snapshot refresh. DBMS_SNAPSHOT.SET_ I _AM_A_REFRESH Set s a session st at e variable t o indicat e t hat t he session is act ing on behalf of a snapshot refresh. DBMS_SNAPSHOT. BEGI N_TABLE_REORGANI ZATI ON Called prior t o reorganizing a m ast er t able in order t o preserve snapshot log inform at ion ( Oracle8 only) . DBMS_SNAPSHOT. END_TABLE_REORGANI ZATI ON Called at t he conclusion of a m ast er t able reorganizat ion t o resum e norm al logging of DML ( Oracle8 only) .

252

Oracle Distributed Systems DBMS_SNAPSHOT.REGI STER_SNAPSHOT Creat es an ent ry for a snapshot in t he dat a dict ionary view DBA_REGI STERED_SNAPSHOTS at t he m ast er sit e. DBMS_SNAPSHOT. UNREGI STER_SNAPSHOT Rem oves t he ent ry for a snapshot in t he dat a dict ionary view DBA_REGI STERED_SNAPSHOTS at t he m ast er sit e. The full specificat ion of t hese procedures is provided in Appendix A.

1 1 .8 .3 Re or ga n izin g a M a st e r Ta ble in Or a cle 8 Occasionally, a DBA m ust reorganize a t able—t hat is, coalesce it s ext ent s and reduce row chaining. These t wo new m odules in Oracle8 allow you t o reorganize a m ast er t able wit hout invalidat ing it s snapshot log. Therefore, you do not have t o perform com plet e refreshes of t he t able's snapshot s aft er it is reorganized. To t ake advant age of t his new feat ure, you m ust be using prim ary key snapshot s. The procedure is t o call DBMS_SNAPSHOT.BEGI N_REORGANI ZATI ON before reorganizing t he t able and DBMS_SNAPSHOT.END_REORGANI ZATI ON when you are finished. The following sect ions illust rat e how t o use t hese procedures as part of a t able reorganizat ion.

1 1 .8 .3 .1 St e ps for r e or ga n izin g a m a st e r t a ble u sin g t r u n ca t ion 1. Call DBMS_SNAPSHOT.BEGI N_TABLE_REORGANI ZATI ON: 2. EXECUTE DBMS_SNAPSHOT.BEGIN_TABLE_REORGANIZATION ( 3. tabowner => 'SPROCKET', tabname => 'COUNTRIES'); 4. Back up t he t able by export ing it or spooling it t o a flat file. 5. Truncat e t he m ast er t able, preserving t he snapshot log: TRUNCATE TABLE countries PRESERVE SNAPSHOT LOG; 6. Rest ore t he t able from t he export file or flat file. 7. Call DBMS_SNAPSHOT.END_TABLE_REORGANI ZATI ON: 8. EXECUTE DBMS_SNAPSHOT.END_TABLE_REORGANIZATION ( 9. tabowner => 'SPROCKET', tabname => 'COUNTRIES');

1 1 .8 .3 .2 St e ps for r e or ga n izin g a m a st e r t a ble by r e n a m in g 1. Call DBMS_SNAPSHOT.BEGI N_TABLE_REORGANI ZATI ON: 2. EXECUTE DBMS_SNAPSHOT.BEGIN_TABLE_REORGANIZATION ( 3. tabowner => 'SPROCKET',

253

Oracle Distributed Systems tabname

=> 'COUNTRIES');

4. Renam e t he t able: RENAME TABLE countries TO countries_pre_reorg; 5. Creat e a new version of t he t able: CREATE TABLE countries AS SELECT * FROM countries_pre_reorg; 6. Call DBMS_SNAPSHOT.END_TABLE_REORGANI ZATI ON: 7. EXECUTE DBMS_SNAPSHOT.END_TABLE_REORGANIZATION ( 8. tabowner => 'SPROCKET', tabname => 'COUNTRIES'); 9. Re- creat e any t riggers t hat were defined on t he t able. I n bot h of t hese exam ples, snapshot s will be able t o use t he snapshot log for FAST refreshes aft er t he t able reorganizat ion is com plet e.

1 1 .8 .4 Offlin e I n st a n t ia t ion of Sn a psh ot s I n cases in which you wish t o inst ant iat e a snapshot sit e wit h a large am ount of dat a in an advanced replicat ion environm ent , offline inst ant iat ion m ay be m ore convenient t han using t he DBMS_REPCAT m et hods. Offline inst ant iat ion refers t o t he populat ion of snapshot s wit h t he im port and export ut ilit ies as opposed t o using t he DBMS_SNAPSHOT.REFRESH procedure. This t echnique is less t im e consum ing and less t axing on your net work, and it m inim izes t he t im e your environm ent m ust be quiesced. The DBMS_OFFLI NE_SNAPSHOT package provides t he bulk of t he funct ionalit y of offline inst ant iat ion. You m ust also call DBMS_REPCAT.CREATE_SNAPSHOT_REPGROUP t o creat e a new replicat ed snapshot group. The procedure for perform ing offline inst ant iat ion of snapshot s in an advanced replicat ion environm ent is as follows: 1. Creat e a snapshot log for each m ast er t able if one does not already exist . 2. Creat e a snapshot of each m ast er t able in t he m ast er dat abase and in t he sam e schem a as t he m ast er t able. Of course, t he nam e of t he snapshot will have t o be different from t he nam e of t he m ast er t able. The CREATE SNAPSHOT st at em ent m ust also include a loopback dat abase link qualifier: 3. CREATE SNAPSHOT snp_countries AS SELECT * FROM [email protected] 4. Perform user export s of all schem as t hat own m ast er t ables. You should be logged on t o t he schem a owner account for t hese export s. The only t ables t hat you need t o export are t he snapshot base t ables ( i.e., t hose whose nam es begin wit h SNAP$_) . 5. Copy t he export dum p file( s) t o t he new snapshot sit e( s) . 6. Use DBMS_REPCAT.CREATE_SNAPSHOT_REPGROUP at t he snapshot sit es t o creat e a new snapshot replicat ion obj ect group. The nam e of t his obj ect group

254

Oracle Distributed Systems should be t he sam e as t he nam e of t he replicat ion group of which t he m ast er t ables are m em bers: 7. EXECUTE DBMS_REPCAT.CREATE_SNAPSHOT_REPGROUP( 8. gname => 'SPROCKET', 9. master => 'D7CA.BIGWHEEL.COM', 10. comment => 'Group created on '||sysdate|| ' by '||user, propagation_mode => 'ASYNCHRONOUS'); 11. Call DBMS_OFFLI NE_SNAPSHOT.BEGI N_LOAD t o begin loading t he dat a from t he export file( s) . You m ust call t he procedure for every snapshot you plan t o im port : 12. EXECUTE DBMS_OFFLINE_SNAPSHOT.BEGIN_LOAD( 13. gname => 'SPROCKET', 14. sname => 'SPROCKET', 15. master_site => 'D7CA.BIGWHEEL.COM' 16. snapshot_oname => 'SNP_COUNTRIES' 17. storage_c => 'TABLESPACE sprocket_data STORAGE (INITIAL 64K)' comment => 'Load of COUNTRIES snapshot begun at '||sysdate); 18. I m port t he snapshot base t able( s) from t he export file( s) creat ed in St ep 4. 19. Call DBMS_OFFLI NE_SNAPSHOT.END_LOAD for each snapshot when t he load is com plet e: 20. EXECUTE DBMS_OFFLINE_SNAPSHOT.END_LOAD( 21. gname => 'SPROCKET' 22. sname => 'SPROCKET' snapshot_oname => 'SNP_COUNTRIES');

1 1 .8 .5 Tr ou ble sh oot in g The following sect ions describe solut ions t o som e com m on problem s t hat arise when using snapshot s.

1 1 .8 .5 .1 Sn a psh ot s a r e n ot r e fr e sh in g When snapshot s fail t o refresh, it is generally because of eit her a connect ivit y problem ( i.e., t he snapshot sit e cannot connect t o t he m ast er sit e) or a privilege problem . When a snapshot first fails t o refresh, Oracle ret ries t he operat ion one m inut e lat er. I f t he refresh cont inues t o fail, Oracle reat t em pt s t wo m inut es lat er, t hen four m inut es lat er, and so on. I f t he ret ry int erval exceeds t he snapshot refresh int erval, t hen Oracle ret ries at t he refresh int erval. I f t he refresh fails 16 t im es, t hen Oracle m arks t he snapshot as BROKEN in t he DBA_REFRESH and DBA_REFRESH_CHI LDREN dat a dict ionary views.

This behavior is t he sam e as for j obs in t he j ob queue precisely because snapshot refresh j obs are j obs in t he j ob queue.

255

Oracle Distributed Systems When you not ice t hat a snapshot is not refreshing, you can alm ost always det erm ine t he problem by looking for a t race file in t he direct ory specified by t he init ializat ion param et er BACKGROUND_DUMP_DEST. The t race file will have inform at ion about what ever errors t he snapshot background process has encount ered. For exam ple, if t he dat abase link from t he snapshot sit e t o t he m ast er sit e at t em pt s t o connect wit h an invalid usernam e or password, t he t race file cont ains ent ries like t his: *** SESSION ID:(10.9446) 1998.06.21.21.19.47.000 ORA-12012: error on auto execute of job 29 ORA-01017: invalid username/password; logon denied ORA-06512: at "SYS.DBMS_SNAPSHOT", line 380 ORA-06512: at "SYS.DBMS_IREFRESH", line 450 ORA-06512: at "SYS.DBMS_REFRESH", line 182 ORA-06512: at line 1 Sun Jun 21 21:19:47 1998 Usually, t he problem is reasonably easy t o diagnose by looking in t he t race file.

1 1 .8 .5 .2 Sn a pshot s r e fr e sh in g con t inu ou sly At t he ot her end of t he spect rum is a sit uat ion in which snapshot s refresh const ant ly. This can occur if t he int erval specified for t he refresh is less t han t he t im e it t akes t o act ually refresh t he snapshot . I n ot her words, t he snapshot is overdue for a refresh aft er it com plet es each refresh. The solut ion t o t his problem is t o m odify t he snapshot 's refresh int erval accordingly, eit her wit h t he package procedure DBMS_REFRESH.CHANGE ( if t he snapshot is a m em ber of a refresh group) or wit h t he ALTER SNAPSHOT com m and ( for snapshot s t hat are not m em bers of refresh groups) .

1 1 .8 .5 .3 Sn a psh ot logs a r e gr ow in g u n con t r olla bly One of t he m ost com m only report ed problem s wit h snapshot logs is a log t hat cont inues growing seem ingly wit hout bounds. This can occur if t he m ast er sit e t hinks t hat t here are unrefreshed snapshot sit es t hat st ill need t o reference t he log. Oracle does not rem ove ent ries from t he snapshot log unt il all snapshot s have " seen" it . So, if a sit e becom es unavailable for an ext ended period of t im e, or if a snapshot is dropped, t he snapshot log can cont inue t o queue records for t he non- exist ent snapshot . Oracle provides several package procedures t hat allow you t o rid t he snapshot log of irrelevant records or t o purge t he log ent irely: DBMS_SNAPSHOT. GET_LOG_AGE Finds t he age of t he oldest record in t he snapshot log ( Oracle8 only) . DBMS_SNAPSHOT. PURGE_LOG Delet es som e or all records from a snapshot log. DBMS_SNAPSHOT. PURGE_SNAPSHOT_FROM_LOG

256

Oracle Distributed Systems Rem oves log ent ries associat ed wit h a part icular snapshot from t he snapshot log. Refer t o Appendix A for t he com plet e API reference for t hese procedures.

1 1 .9 Scr ipt s Several script s provided in Appendix B, are part icularly useful for providing inform at ion about snapshot s in your environm ent . See snaps.sql, reqsnaps.sql, and m ast ersnapinfo.sql. .

257

Oracle Distributed Systems

258

Oracle Distributed Systems

Ch a pt e r 1 2 . M u lt i- M a st e r Re plica t ion Mult i- m ast er replicat ion, also known as advanced replicat ion orsym m et ric replicat ion, allows you t o m aint ain m ult iple set s of ident ical dat a at various sit es; Oracle can aut om at ically synchronize all DDL and DML changes. Obviously, t his funct ionalit y com es at t he expense of addit ional planning and adm inist rat ive t asks and int roduces a new level of sophist icat ion t o t he environm ent . This chapt er describes how t o creat e and m aint ain a replicat ed environm ent and how t o assess it s healt h.

1 2 .1 Conce pt s a nd Te r m inology As you em bark down t he road ofreplicat ion, you will encount er several phrases repeat edly; t hese include: • • • • • • • • •

Deferred t ransact ion Replicat ion group Quiescence Mast er definit ion sit e Mast er sit e Replicat ion support Conflict Propagat ion lat ency I nst ant iat ion

The following sect ions briefly describe what t hese phrases m ean.

1 2 .1 .1 D e fe r r e d Tr a n sa ct ion A deferred t ransact ion is a t ransact ion t hat is queued for delivery t o one or m ore rem ot e dat abases. I f you use m ult i- m ast er replicat ion wit h asynchronous propagat ion, Oracle creat es deferred t ransact ions for all local DML act ivit y against t he replicat ed t ables.

1 2 .1 .2 Re plica t ion Gr ou p A replicat ion group is a collect ion of one or m ore replicat ed obj ect s ( t ypically t ables) t hat are adm inist rat ed t oget her. Very generally speaking, t he obj ect s in a given replicat ion group are logically relat ed; for exam ple, t hey are oft en t he set of obj ect s t hat a given applicat ion uses. Prior t o Oracle Version 7.3, t he concept of a replicat ion group did not exist ; inst ead, obj ect s had t o be replicat ed on a schem a- by- schem a basis. Beginning wit h Version 7.3, Oracle organized replicat ed obj ect s int o replicat ion groups. A given replicat ion group can cont ain obj ect s from m ult iple schem a, and a given schem a can have obj ect s in m ore t han one replicat ion group. However, any given obj ect can be in only one replicat ion group. The m ost significant propert y of replicat ion groups is t hat all obj ect s in a given group are quiesced t oget her. That is, DML act ivit y is enabled and disabled for all group m em bers sim ult aneously.

259

Oracle Distributed Systems

1 2 .1 .3 Qu ie sce n ce Quiescence is t he act of suspending DML act ivit y for all t ables in a given replicat ion group. This is required in order t o perform cert ain adm inist rat ive t asks on obj ect s in a replicat ion group, such as alt ering a t able. The Oracle built - in package procedure call t hat quiesces a replicat ion group is DBMS_REPCAT.SUSPEND_MASTER_ACTI VI TY.

Prior t o Oracle8, quiescing a single replicat ion group act ually caused all groups t o be quiesced, even t hough t he DBMS_REPCAT.SUSPEND_MASTER_ACTI VI TY call requires t hat you specify a single group. Oracle refers t o t he abilit y t o quiesce a single replicat ion group as a fine- grained quiesce.

1 2 .1 .4 M a st e r D e fin it ion Sit e The m ast er definit ion sit e of a replicat ion group is t he dat abase inst ance from which t he group is adm inist ered. This sit e is usually, but not necessarily, t he sit e at which t he replicat ion group was originally creat ed. ( You can use t he built - in package procedure DMBS_REPCAT.RELOCATE_MASTERDEF t o change a replicat ion group's m ast er definit ion sit e.) Act ivit ies such as quiescence and DDL on replicat ed obj ect s m ust be perform ed at t he m ast er definit ion sit e. There is exact ly one m ast er definit ion sit e for each replicat ion group. I t is wort h not ing t hat t he behavior of DML is t he sam e at t he m ast er definit ion sit e as at any ot her sit e. I n ot her words, DML perform ed at t he m ast er definit ion sit e does not have any precedence over DML perform ed at ot her m ast er sit es.

1 2 .1 .5 M a st e r Sit e A m ast er sit e is a sit e t hat is part icipat ing in one or m ore replicat ion groups but is not t he m ast er definit ion sit e.

1 2 .1 .6 Re plica t ion Su ppor t Replicat ion support refers t o t he packages and t riggers t hat Oracle creat es in order t o propagat e changes t o replicat ed obj ect s, t o det ect and resolve conflict s, and so on. See Chapt er 9, for a descript ion of t hese obj ect s.

1 2 .1 .7 Con flict When Oracle propagat es an updat e t o dest inat ion t ables, it expect s t he current dat a for t he row at t he dest inat ion t o m at ch t he dat a at t he originat ing sit e prior t o t he updat e. I f t he dat a is not t he sam e, an updat e conflict result s. Sim ilarly, if an insert fails because of a prim ary key violat ion ( i.e., a unique const raint violat ion) t he result is a uniqueness conflict or violat ion. And, if t he t arget row of a delet e does not exist

260

Oracle Distributed Systems at t he dest inat ion sit e, a delet e conflict result s. Chapt er 15, discusses advanced t echniques for det ect ing and resolving conflict s aut om at ically.

1 2 .1 .8 Pr opa ga t ion La t e n cy Unless you are propagat ing changes am ong m ast er sit es synchronously, t here is a delay bet ween t he t im e a DML change is applied at t he originat ing dat abase and t he t im e t he t ransact ion reaches t he dest inat ion dat abases. This lag is known as propagat ion lat ency.

1 2 .1 .9 I n st a n t ia t ion I nst ant iat ion is t he act of creat ing and populat ing a t able so t hat it has ident ical st ruct ure and dat a as it s replica in ot her m ast er dat abases.

1 2 .2 Ge t t in g St a r t e d Before set t ing up t ables for replicat ion, you m ust com plet e t he prelim inary t asks described in Chapt er 10. These t asks include t he following: • • • • •

Det erm ining and set t ing init ializat ion param et ers appropriat ely Sizing rollback segm ent s and redo logs Running cat proc.sql and cat rep.sql ( and opt ionally cat repad.sql ) Creat ing adm inist rat ive account s wit h appropriat e privileges Creat ing necessary dat abase links

I f you have accom plished t hese t asks, you are ready t o creat e replicat ion groups, configure t ables, and ot her obj ect s for replicat ion and add m ast er dat abases.

1 2 .2 .1 Th e Qu ick - a n d- D ir t y Se t u p Many people want t o configure obj ect s for replicat ion as quickly and sim ply as possible so t hat t hey can get a sense of t he adm inist rat ion and perform ance considerat ions and t o learn about how replicat ion works first hand. To speed t hese people on t heir way, t he st eps required t o set up a bare- bones replicat ed environm ent are included here. The m ain dist inct ion bet ween t hism inim al configurat ion and one t hat is appropriat e for product ion is t hat it does not include any conflict resolut ion logic.

Alt hough t hese st eps will indeed creat e a replicat ed environm ent , it is not suit able for a product ion inst allat ion because it does not t ake conflict s int o account , rendering it anyt hing but robust . This procedure assum es t hat you have set t he proper init ializat ion param et ers, run t he required cat alog script s, and creat ed necessary dat abase links and adm inist rat ive account s. Now, wit h no furt her ado, t he m inim al procedure for replicat ing an obj ect is t o follow t hese st eps:

261

Oracle Distributed Systems 1. Creat e t he obj ect in all m ast er dat abases; if it is a t able, you can populat e it wit h ident ical dat a at all locat ions before configuring it for replicat ion, or you can let Oracle's replicat ion packages populat e t he t able. 2. Creat e one or m ore replicat ion groups using t he package procedure DBMS_REPCAT.CREATE_MASTER_REPGROUP. 3. Add obj ect s t o t he replicat ion groups using t he package procedure DBMS_REPCAT.CREATE_MASTER_REPOBJECT. 4. Generat e replicat ion support for each obj ect using t he package procedure DBMS_REPCAT.GENERATE_REPLI CATI ON_SUPPORT. 5. Add one or m ore m ast er sit es t o t he replicat ion group using t he package procedure DBMS_REPCAT.ADD_MASTER_DATABASE. 6. Schedule t he propagat ion of DML changes and replicat ed procedure calls t o each m ast er sit e using DBMS_DEFER_SYS.SCHEDULE_PUSH ( for Oracle8 dat abases) or DBMS_DEFER_SYS.SCHEDULE_EXECUTI ON ( for Oracle7 dat abases) .

Alt hough Oracle8 includes t he DBMS_DEFER_SYS.SCHEDULE_EXECUTI ON package procedure, it is int ended for backward com pat ibilit y only. Always use DBMS_DEFER_SYS.SCHEDULE_PUSH. 7. 8. ( Oracle8 only) Schedule t he purging of t he deft ran queue using t he DBMS_DEFER_SYS.SCHEDULE_PURGE.

1 2 .2 .2 A Qu ick - a n d- D ir t y Ex a m ple Here aret he st eps t o go t hrough t o replicat e a single t able nam ed SPROCKET.REGI ONS at sit es PHQS.BI GWHEEL.COM and PSLS.BI GWHEEL.COM. Suppose t his t able looks like t his: SQL> describe regions Name Null? --------------- -------REGION_ID NOT NULL COUNTRY_ID NOT NULL REGION_NAME NOT NULL AUDIT_DATE NOT NULL AUDIT_USER NOT NULL GLOBAL_NAME NOT NULL

Type --------NUMBER(6) NUMBER(6) VARCHAR2(15) DATE VARCHAR2(30) VARCHAR2(20)

For t he purposes of t his exam ple, assum e t hat PHQS.BI GWHEEL.COM is t he m ast er definit ion sit e and t hat t he REGI ONS t able has already been creat ed and populat ed at bot h sit es. Perform all of t he following st eps connect ed t o t he m ast er definit ion sit e under t he replicat ion adm inist rat or account , t ypically REPADMI N. 1. Creat e a replicat ion group, in t his case nam ed RG_SALES: 2. EXECUTE dbms_repcat.create_master_repgroup( 3. gname => 'RG_SALES', -

262

Oracle Distributed Systems 4.

group_comment => 'Created by ' ||user|| ' on ' || sysdate, master_comment => 'Created by ' ||user|| ' on ' || sysdate)

5. Add REGI ONS t o t he RG_SALES replicat ion group: 6. EXECUTE dbms_repcat.create_master_repobject(7. sname => 'SPROCKET',8. oname => 'REGIONS',9. type => 'TABLE',10. use_existing_object => TRUE,11. comment => 'Added by '||lower(user)||' on '||sysdate,12. copy_rows => FALSE,gname => 'RG_SALES'); 13. Generat e replicat ion support for t he REGI ONS t able: 14. EXECUTE dbms_repcat.generate_replication_support( 15. sname => 'SPROCKET',16. oname => 'REGIONS',17. type => 'TABLE',distributed => TRUE); 18. Add t he m ast er sit e PSLS.BI GWHEEL.COM t o t he replicat ion group: 19. EXECUTE dbms_repcat.add_master_database( 20. gname => 'RG_THROW', 21. master => 'PHQS.BIGWHEEL.COM', 22. use_existing_objects => TRUE, 23. copy_rows => FALSE, 24. comment => 'PSLS.BIGWHEEL.COM added on '||sysdate, propagation_mode => 'ASYNCHRONOUS');

Act ually, you can add m ast er dat abases t o a replicat ion group as soon as you creat e t he group. However, it is fast er t o generat e replicat ion support for all replicat ed obj ect s before adding m ast ers. Whenever possible, generat e replicat ion support for obj ect s first .

25. Schedule propagat ion bet ween t he dat abases PHQS.BI GWHEEL.COM and PSLS.BI GWHEEL.COM. I n t his case, t he propagat ion int erval is once per m inut e ( t here are 1440 m inut es in a day) . I n PHQS.BI GWHEEL.COM ( m ast er definit ion sit e) : Oracle8 synt ax: EXECUTE dbms_defer_sys.schedule_push( destination => 'PSLS.BIGWHEEL.COM', interval => 'SYSDATE+1/1440', next_date => SYSDATE+1/1440);

263

Oracle Distributed Systems Oracle7 synt ax: EXECUTE dbms_defer_sys.schedule_execution( destination => 'PSLS.BIGWHEEL.COM', interval => 'SYSDATE+1/1440', next_date => SYSDATE+1/1440); I n PSLS.BI GWHEEL.COM ( m ast er sit e) : Oracle8 synt ax: EXECUTE dbms_defer_sys.schedule_push( destination => 'PHQS.BIGWHEEL.COM', interval => 'SYSDATE+1/1440', next_date => SYSDATE+1/1440); Oracle7 synt ax: EXECUTE dbms_defer_sys.schedule_execution( destination => 'PHQS.BIGWHEEL.COM', interval => 'SYSDATE+1/1440', next_date => SYSDATE+1/1440); 26. For Oracle8 dat abases, you m ust also schedule a periodic purge of t he deft ran queue. Here t he purge is scheduled t o run every 10 m inut es in bot h dat abases ( Oracle8 only) . I n PHQS.BI GWHEEL.COM ( m ast er definit ion sit e) : EXECUTE dbms_defer_sys.schedule_purge( interval => 'SYSDATE+10/1440', next_date => SYSDATE+10/1440); I n PSLS.BI GWHEEL.COM ( m ast er sit e) : EXECUTE dbms_defer_sys.schedule_purge( interval => 'SYSDATE+10/1440', next_date => SYSDATE+10/1440); 27. Enable replicat ion. From t he m ast er definit ion sit e, PHQS.BI GWHEEL.COM, call DBMS_REPCAT.RESUME_MASTER_ACTI VI TY: EXECUTE dbms_repcat.resume_master_activity(gname => 'RG_SALES'); At t his point , you should be able t o perform insert s, updat es, and delet es on t he REGI ONS t able from eit her sit e and see t he t ransact ion applied at t he ot her sit e wit hin approxim at ely 1 m inut e. Now, if you want t o creat e a robust replicat ed environm ent t hat will st and up t o realworld product ion usage, read on.

264

Oracle Distributed Systems

1 2 .3 Re plica t ion Gr ou ps As described earlier, a replicat ion group is a collect ion of one or m ore obj ect s, generally t ables, t hat are logically relat ed and t hat can or should be adm inist ered t oget her. As a very general guideline, you can place all replicat ed obj ect s associat ed wit h a given applicat ion int o a single group. A com m on pract ice is t o creat e all of an applicat ion's obj ect s under a single schem a ( i.e., Oracle user account ) ; in such cases, it oft en m akes sense t o use a one- t o- one correspondence bet ween schem a and replicat ion groups. I n fact , prior t o Oracle 7.3, t hat was not only t he assum pt ion but also t he requirem ent .

1 2 .3 .1 API Ca lls Oracle furnishes t he following built - in package procedures t o creat e and drop replicat ion groups: DBMS_REPCAT. CREATE_MASTER_REPGROUP Creat es a replicat ion group. The group is init ially quiesced and cont ains no obj ect s. DBMS_REPCAT. DROP_MASTER_REPGROUP Drops a replicat ion group. DBMS_REPCAT. COMMENT_ON_REPGROUP Creat es or replaces a com m ent on a replicat ion group, visible in t he DBA_REPGROUP dat a dict ionary view. Refer t o Appendix A, for t he com plet e API reference t o t hese procedures. The dat a dict ionary view DBA_REPGROUP cont ains inform at ion about all replicat ion groups at t he current sit e.

The call t o DBMS_REPCAT.CREATE_MASTER_REPGROUP aut om at ically creat es an ent ry in t he j ob queue t o process t asks in t he repcat log queue. This scheduled j ob calls DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMI N every 10 m inut es.

265

Oracle Distributed Systems

1 2 .3 .2 N a m in g Con ve n t ion s Oracle replicat ion has m any different ent it ies associat ed wit h it : replicat ion groups, colum n groups, sit e priorit ies, and so on. We find t hat adm inist rat ion is sim plified im m ensely if such obj ect s are nam ed according t o a uniform convent ion. Wit h t his end in m ind, we recom m end nam ing replicat ion groups in t he form RG_nam e. I f you are creat ing a replicat ion group t hat will include all replicat ed obj ect s for a single schem a, t hen nam e should be t he nam e of t he schem a. You can use t he following script t o report on all replicat ion groups: --------------------------------------------------------------------------- Filename: repgroup.sql -- Purpose: Lists status of all replication groups. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column column column column column SELECT

FROM WHERE AND /

MASTER MASTERDEF STATUS GNAME SCHEMA_COMMENT

heading heading heading heading heading

"Mast|Site" "Mast|Def|Site" "Status" "Group" "Comment"

format format format format format

a4 a4 a9 a12 a45

g.gname, decode(g.master, 'N', 'No', 'Y', 'Yes') master, decode(s.masterdef, 'Y', 'Yes', 'N', 'No') masterdef, g.status, g.schema_comment dba_repgroup g, dba_repsites s g.gname = s.gname s.my_dblink = 'Y'

1 2 .3 .3 W h ich Ta ble s Be lon g in t h e Sa m e Re plica t ion Gr ou p? I n t he m aj orit y of cases, t he easiest st rat egy is t o associat e a single replicat ion group wit h a single schem a. However, t his advice com es wit h t he caveat s list ed here: •

Do not allow t ransact ions t o cross replicat ion group boundaries. I f you have t ransact ions t hat m anipulat e m ult iple t ables, m ake sure t hat all affect ed t ables are in t he sam e replicat ion group. This approach ensures t hat DML is eit her enabled for all t ables in t he t ransact ion or disabled for all t ables in t he t ransact ion. I n ot her words, eit her all or none of t he t ables in t he t ransact ion will be quiesced at any given t im e.

•

Do not allow referent ial int egrit y const raint s t o cross replicat ion group boundaries.

266

Oracle Distributed Systems Com m on sense and experience have shown t hat a t able wit h foreign keys should be in t he sam e replicat ion group as t he t able t hat parent s t he keys. Alt hough DML is not necessarily prevent ed when one or t he ot her t able is quiesced, applicat ions oft en m odify such t ables t oget her, albeit not always in a single t ransact ion. For exam ple, an order ent ry applicat ion m ay insert a record int o t he ORDERS t able in one t ransact ion and t he ORDER_I TEMS t able in t he next . Of course t his is not a hard- and- fast rule, but unless you have a good reason t o separat e t ables t hat are bound by int egrit y const raint s, keep t hem in t he sam e replicat ion group. •

I dent ify and isolat e " problem " t ables int o separat e replicat ion groups. Does your applicat ion include a few t ables t hat are subst ant ially larger or hot t er t han t he ot hers? I t is oft en wort hwhile t o put such t ables in t heir own replicat ion groups so t hat you can perform m aint enance on t hem wit hout having t o quiesce t he rest of t he schem a.

Oracle int roduced t he concept of a replicat ion group in Oracle 7.3. Prior t o Oracle 7.3, you had t o replicat e obj ect s on a schem a- by- schem a basis; in ot her words, obj ect s belonging t o a given schem a had t o be m anaged t oget her.

1 2 .3 .4 H ow t o D r op a Re plica t ion Gr ou p You can drop a replicat ion group wit h a call t o DBMS_REPCAT.DROP_MASTER_REPGROUP, which can also drop t he underlying obj ect s in t he replicat ion group if you wish. The procedure is defined as follows: PROCEDURE drop_master_repgroup( gname IN VARCHAR2, drop_contents IN BOOLEAN := FALSE, all_sites IN BOOLEAN := FALSE); You are not required t o quiesce t he replicat ion group before dropping it , but t he call will fail if t here are t ransact ions associat ed wit h t he group in t he deft ran queue. Table 12.1 describes t he behavior of t he drop_cont ent s and all_sit es param et ers.

Table 12.1. Effect of drop_contents and all_sites in DROP_MASTER_REPGROUP Calling Site

drop_contents all_sites

Effect

Mast er TRUE definit ion sit e

TRUE

Replicat ion group gnam e and it s underlying obj ect s are dropped from all sit es.

Mast er FALSE definit ion sit e

TRUE

Replicat ion group gnam e is dropped from all m ast er sit es.

267

Oracle Distributed Systems

Mast er TRUE definit ion sit e

FALSE

Mast er FALSE definit ion sit e

Replicat ion group gnam e is dropped from t he FALSE m ast er definit ion sit e only. Underlying obj ect s rem ain at all sit es.

Mast er sit e

TRUE

FALSE

Replicat ion group gnam e and all underlying obj ect s are dropped at t he calling sit e.

Mast er sit e

FALSE

FALSE

Replicat ion group gnam e is dropped; underlying obj ect s are unaffect ed.

Replicat ion group gnam e and underlying cont ent s are dropped from t he m ast er definit ion sit e only.

The all_sit es param et er m ust be set t o FALSE if t he calling sit e is not t he m ast er definit ion sit e.

When Oracle drops t he replicat ion group, t hat m eans t hat all replicat ion support packages and t riggers associat ed wit h t he replicat ion group are dropped, and t he replicat ion group is rem oved from all relevant dat a dict ionary views.

1 2 .4 M a st e r Sit e M a int e na n ce a n d Pr opa ga t ion Thesit e at which you creat e a replicat ion group is aut om at ically t he m ast er definit ion sit e for t hat replicat ion group. Of course, for replicat ion t o have any m eaning, you will need t o add at least one m ast er sit e. The DBMS_REPCAT package includes procedures for adding and rem oving m ast er sit es. You also need t o cont rol how DML changes propagat e bet ween sit es; t he DBMS_DEFER_SYS package cont ains t he procedures for configuring t he propert ies of propagat ion.

1 2 .4 .1 API Ca lls The following procedures m anipulat e m ast er sit es: DBMS_REPCAT. ADD_MASTER_DATABASE Adds a m ast er dat abase t o t he specified replicat ion group. The call can creat e t he obj ect s if t hey do not already exist at t he m ast er sit e, populat e replicat ed t ables if t hey do not cont ain any dat a, or ut ilize t he t ables and dat a t hat are already at t he new m ast er sit e. DBMS_REPCAT. RELOCATE_MASTERDEF Changes t he locat ion of a replicat ion group's m ast er definit ion sit e. This procedure is useful if t he exist ing m ast er definit ion sit e becom es unavailable or ot herwise irrelevant . DBMS_REPCAT. REMOVE_MASTER_DATABASES Rem oves a m ast er sit e from a replicat ion group.

268

Oracle Distributed Systems Refer t o Appendix A for t he com plet e API reference t o t hese procedures.

1 2 .4 .2 Addin g a M a st e r Sit e I f you are creat ing a brand new replicat ion group, your prim ary t asks are t o inst ant iat e t he dat a at all m ast er sit es, generat e replicat ion support for all obj ect s, and add all sit es t o t he environm ent . There are a num ber of ways t o accom plish t hese t asks, and som e are m ore effect ive t han ot hers. Experience has t aught t hat , given a choice, you should add m ast er sit es aft er you have added obj ect s t o t he replicat ion group at t he m ast er definit ion sit e and t hat you should pre- creat e and inst ant iat e replicat ed t ables at all m ast er sit es. You will not ice t hat t he DBMS_REPCAT.ADD_MASTER_DATABASE procedure includes param et ers for creat ing and inst ant iat ing obj ect s at t he new m ast er: PROCEDURE add_master_database( gname master use_existing_objects copy_rows comment propagation_mode 'ASYNCHRONOUS');

IN IN IN IN IN IN

VARCHAR2, VARCHAR2, BOOLEAN := TRUE, BOOLEAN := TRUE, VARCHAR2 := '', VARCHAR2 :=

I st rongly advise you t o not rely on t his procedure t o creat e or inst ant iat e obj ect s. Alt hough t his procedure m ay work adequat ely for sm all and sim ple t ables, you effect ively relinquish cont rol of t he inst ant iat ion process and m ay end up wait ing a very long t im e before learning of problem s. I nst ead, follow t hese st eps at each int ended m ast er sit e: 1. Creat e t he t ables and procedures t hat are in t he replicat ion group. 2. Populat e t ables wit h ident ical dat a, using ut ilit ies such as im port / export or SQL* Loader. 3. Creat e prim ary keys and ot her indexes on all replicat ed t ables. 4. Creat e any user- defined t riggers on replicat ed t ables. User- defined t riggers are part icularly useful for populat ing colum ns t hat are used for conflict resolut ion. 5. Add t he sit e by calling DBMS_REPCAT.ADD_MASTER_DATABASEat t he m ast er definit ion sit e, wit h t he param et ers: 6. use_existing_objects => TRUE copy_rows => FALSE I t is quit e easy t o follow t his m et hodology if you m aint ain appropriat e script s t o creat e your schem a obj ect s. For exam ple, m aint aining t he REGI ONS t able used in t he earlier quick- and- dirt y exam ple are t he script s cr_regions.sql ( which creat es t he t able and synonym s) , pk_regions.sql ( which creat es t he const raint s and indexes on t he t able) , and t rg_regions.sql ( which creat es t he user- defined t riggers) . The cont ent s of t hese script s follow. Adm it t edly, creat ing t hese script s can be a chore, but it is well wort h t he effort if you are at t em pt ing t o m aint ain replicat ed schem a at m ult iple m ast er sit es.

269

Oracle Distributed Systems

1 2 .4 .2 .1 Cr e a t in g t h e REGI ON S t a ble --------------------------------------------------------------------------- Filename: cr_regions.sql -- Purpose: Creates the REGIONS table and its public synonym. -- Author: Chas. Dye ([email protected]) -- Date: 12-Jan-1998 -------------------------------------------------------------------------set echo on set termout on spool regions.log DROP PUBLIC SYNONYM regions / DROP TABLE regions CASCADE CONSTRAINTS / CREATE TABLE regions ( region_id NUMBER(6) NOT NULL, country_id NUMBER(6) NOT NULL, region_name VARCHAR2(15) NOT NULL, audit_date DATE NOT NULL, audit_user VARCHAR2(30) NOT NULL, global_name VARCHAR2(20) NOT NULL ) TABLESPACE sprocket_data STORAGE (INITIAL 16K NEXT 16K PCTINCREASE 0) / CREATE PUBLIC SYNONYM regions FOR regions / spool off

1 2 .4 .2 .2 Cr e a t in g con st r a in t s a nd in de x e s on REGI ON S t a ble --------------------------------------------------------------------------- Filename: pk_regions.sql -- Purpose: Creates the constraints and indexes on table REGIONS. -- Author: Chas. Dye ([email protected]) -- Date: 12-Jan-1998 -------------------------------------------------------------------------set echo on set termout on spool pk_regions.log ALTER TABLE regions ADD ( CONSTRAINT pk_regions PRIMARY KEY (region_id) USING INDEX TABLESPACE sprocket_indx STORAGE (INITIAL 16K NEXT 16K PCTINCREASE 0) ) /

270

Oracle Distributed Systems ALTER TABLE regions ADD ( CONSTRAINT fk_regions_country_id FOREIGN KEY (country_id) REFERENCES countries (country_id) ) / CREATE INDEX i_region_country_id ON regions(country_id) TABLESPACE sprocket_indx STORAGE (INITIAL 16K NEXT 16K PCTINCREASE 0) / spool off

1 2 .4 .2 .3 Cr e a t in g use r - de fin e d t r igge r s on t h e REGI ON S t a ble --------------------------------------------------------------------------- Filename: trg_regions.sql -- Purpose: Creates trigger(s) on table REGIONS. -- Author: Chas. Dye ([email protected]) -- Date: 12-Jan-1998 -------------------------------------------------------------------------set echo on set termout on spool trg_regions.log CREATE OR REPLACE TRIGGER t_br_iu_regions BEFORE INSERT OR UPDATE ON regions FOR EACH ROW BEGIN IF (dbms_reputil.from_remote != TRUE) THEN :new.audit_date := SYSDATE; :new.audit_user := USER; :new.global_name := DBMS_REPUTIL.GLOBAL_NAME; END IF; END; /

spool off

1 2 .4 .3 D r oppin g a M a st e r Sit e I f you need t o drop a m ast er sit e from a replicat ion group, you can do so by calling t he built - in package procedure DBMS_REPCAT.REMOVE_MASTER_DATABASES. You m ay use t his procedure even if t he m ast er sit es referenced in t he call are not accessible; however, t he rem aining m ast er sit es do need t o be accessible. I n addit ion, you m ust call REMOVE_MASTER_DATABASES from t he replicat ion group's m ast er definit ion sit e.

271

Oracle Distributed Systems REMOVE_MASTER_DATABASES is overloaded—t hat is, t he list of m ast er sit es m ay be passed eit her as a com m a- separat ed st ring of dat abase nam es or as a PL/ SQL t able of dat abase nam es: PROCEDURE remove_master_databases( gname IN VARCHAR2, master_list IN VARCHAR2); PROCEDURE remove_master_databases( 1492 gname IN VARCHAR2, master_table IN dbms_utility.dblink_array); The following exam ples illust rat e how t o call t he procedure in eit her of it s incarnat ions. I n bot h cases, we drop t he m ast er sit es PSLS.BI GWHEEL.COM and PMFG.BI GWHEEL.COM from t he replicat ion group RG_SALES: • • •

Calling REMOVE_MASTER_DATABASE wit h t he m ast er_list param et er: EXECUTE dbms_repcat.remove_master_database( gname => 'RG_SALES', master_list => 'PSLS.BIGHWHEEL.COM,PMFG.BIGWHEEL.COM'); Calling REMOVE_MASTER_DATABASES wit h t he m ast er_t able param et er: DECLARE vMasterTable dbms_utility.dblink_array; BEGIN vMasterTable(1) := 'PSLS.BIGWHEEL.COM'; vMasterTable(2) := 'PMFG.BIGWHEEL.COM'; dbms_repcat.remove_master_database( gname => 'RG_SALES', master_table => vMasterTable); END;

Aft er rem oving t he m ast er dat abase, you should call DBMS_REPCAT.DROP_MASTER_REPGROUP at each of t he m ast er sit es you rem oved. This procedure rem oves all replicat ion support obj ect s and associat ed dat a dict ionary ent ries. Alt hough you do not need t o quiesce t he replicat ion group t o rem ove one or m ore m ast er dat abase( s) , you are st rongly encouraged t o do so. Ot herwise, you will have t o clear t he RPC queue m anually and resolve any inconsist encies.

1 2 .4 .4 Re loca t in g a M a st e r D e fin it ion Sit e I f your m ast er definit ion sit e becom es unusable or if you sim ply want t o replace it wit h anot her sit e, you can use t he DBMS_REPCAT.RELOCATE_MASTERDEF procedure t o effect t he change. The specificat ion of t his procedure is as follows:

272

Oracle Distributed Systems PROCEDURE relocate_masterdef( gname IN old_masterdef IN new_masterdef IN notify_masters IN include_old_masterdef IN

VARCHAR2, VARCHAR2, VARCHAR2, BOOLEAN := TRUE, BOOLEAN := TRUE);

We recom m end following t hese guidelines when relocat ing a m ast er definit ion sit e: •

•

•

I f your relocat ion is planned ( i.e., all sit es are up and reachable) , set t he not ify_m ast ers and include_old_m ast erdef param et ers t o TRUE. I t t he current m ast er definit ion sit e is not available, set t he not ify_m ast ers param et er t o TRUE and include_old_m ast erdef t o FALSE. I f t he m ast er definit ion sit e as well as som e m ast er sit es are unavailable, invoke t he RELOCATE_MASTERDEF procedure from each funct ioning m ast er sit e wit h t he param et ers not ify_m ast ers and include_old_m ast erdef set t o FALSE.

Advanced replicat ion will cont inue t o funct ion even wit hout a m ast er definit ion sit e. The m ast er definit ion sit e is only required for adm inist rat ive t asks such as perform ing DDL or quiescing a replicat ion group.

1 2 .5 Con t r ollin g Pr opa ga t ion We can m easure t he success of a replicat ed environm ent by det erm ining how quickly and efficient ly DML changes and RPCs are delivered t o t heir dest inat ions. I n order t o deliver changes t o rem ot e sit es as quickly as possible, m ost people succum b t o t he t em pt at ion t o propagat e changes as frequent ly as Oracle will allow, which is once per second. I n som e cases, such an aggressive schedule is warrant ed, but in m ost it is not . Consider t he analogy of grocery shopping. Perhaps you m aint ain a list ( or queue) of it em s t hat you need t o pick up during your next shopping expedit ion. Do you run t o t he grocery st ore every t im e an it em is added t o t he list , or do you wait unt il t he list is sufficient ly long t o m erit a shopping expedit ion? Most likely, you wait unt il t he t rip is wort hwhile. So it is wit h propagat ing DML am ong m ast er sit es. The problem wit h t he one- second propagat ion st rat egy is t hat it generally t akes longer t han one second t o perform a push! Therefore, you m ay act ually end up falling behind if you opt for such a frequent schedule. On t he ot her hand, if you opt for infrequent propagat ion, t he likelihood of conflict s increases. The opt im al sit uat ion is t o schedule pushes in such a way t hat t hey deliver a fairly const ant num ber of t ransact ions wit h each push and t he average lat ency of t ransact ions does not exceed t he push int erval.

Scheduled j obs cause updat es t o dat a dict ionary t ables such as SYS.JOB$ every t im e t hey run. Therefore, t he m ore frequent a j ob is pushed, t he

273

Oracle Distributed Systems

great er t he volum e of redo log act ivit y. Beware t hat frequent pushes will result in a significant volum e of redo, which you will have t o accom m odat e if your dat abase is in ARCHI VELOG m ode.

1 2 .5 .1 API Ca lls The following built - in package procedures m aint ain propagat ion propert ies: DBMS_REPCAT. ALTER_MASTER_PROPAGATI ON Swit ches t he propagat ion m ode bet ween SYNCHRONOUS and ASYNCHRONOUS. DBMS_DEFER_SYS.SCHEDULE_EXECUTI ON ( Oracle7) Schedules aut om at ic push of t he deft ran queue t o t he specified m ast er dat abase. I n Oracle8 t his procedure is replaced wit h SCHEDULE_PUSH, t hough Oracle8 includes t his procedure for backward com pat ibilit y. DBMS_DEFER_SYS.UNSCHEDULE_EXECUTI ON Rem oves t he scheduled DBMS_DEFER_SYS.EXECUTE j ob from t he j ob queue. Oracle8 includes t his procedure for backward com pat ibilit y only. DBMS_DEFER_SYS.SCHEDULE_PURGE ( Oracle8 only) Oracle8 does not rely on t he t wo- phase com m it prot ocol t o deliver t ransact ions t o rem ot e m ast er dat abases. The scheduled purge operat ion confirm s t he delivery of t ransact ions t o rem ot e dat abases and rem oves delivered t ransact ions from t he deft ran queue. DBMS_DEFER_SYS. UNSCHEDULE_PURGE ( Oracle8 only) Rem oves t he scheduled DBMS_DEFER_SYS.PURGE j ob from t he j ob queue for t he specified m ast er dat abase. DBMS_DEFER_SYS. SCHEDULE_PUSH ( Oracle8 only) Schedules an aut om at ic push of t he deft ran queue t o t he specified m ast er dat abase. DBMS_DEFER_SYS. UNSCHEDULE_PUSH ( Oracle8 only) Rem oves t he scheduled DBMS_DEFER_SYS.PUSH j ob from t he j ob queue. Refer t o Appendix A for t he com plet e API reference t o t hese procedures.

274

Oracle Distributed Systems As you can see, Oracle8 has int roduced significant changes in t he way t hat replicat ed act ions propagat e. One fundam ent al difference bet ween propagat ion in Oracle7 and Oracle8 is t hat Oracle7 relies on a t wo- phase com m it t o deliver t ransact ions t o t he dest inat ion sit e, while Oracle8 does not . Oracle8 delivers ent ries in t he deft ran queue t o ot her m ast er sit es but does not wait for t he receiving sit e t o confirm receipt ( t he reason for t he t wo- phase com m it ) . I nst ead, Oracle8 visit s t he dest inat ion sit es lat er t o confirm t he delivery of defran ent ries—hence t he need for SCHEDULE_PURGE and it s com plem ent UNSCHEDULE_PURGE. These procedures schedule a delivery confirm at ion at all dest inat ion sit es. Anot her fundam ent al difference bet ween Oracle7 and Oracle8 is support for parallel propagat ion. Parallel propagat ion m eans t hat Oracle will invoke m ult iple connect ions t o dat abases receiving DML changes and apply m ult iple t ransact ions in deft ran sim ult aneously. Of course, Oracle ensures t hat t hese t ransact ions are independent of each ot her, so t ransact ional consist ency is preserved. I n order t o support parallel propagat ion in Oracle8, t he Oracle7 procedure SCHEDULE_EXECUTI ON is replaced wit h SCHEDULE_PUSH in Oracle8. And UNSCHEDULE_EXECUTI ON gives way t o UNSCHEDULE_PUSH. The specificat ion for t he procedures SCHEDULE_EXECUTI ON and SCHEDULE_PUSH is as follows: PROCEDURE schedule_execution( dblink IN VARCHAR2, interval IN VARCHAR2, next_date IN DATE, reset IN BOOLEAN default FALSE, stop_on_error IN BOOLEAN := NULL, transaction_count IN BINARY_INTEGER := NULL, execution_seconds IN BINARY_INTEGER := NULL, execute_as_user IN BOOLEAN, delay_seconds IN NATURAL := NULL, batch_size IN NATURAL := NULL); PROCEDURE schedule_push( destination interval next_date reset parallelism heap_size stop_on_error write_trace startup_seconds execution_seconds delay_seconds transaction_count

IN IN IN IN IN IN IN IN IN IN IN IN

VARCHAR2, VARCHAR2, DATE, BOOLEAN := FALSE, BINARY_INTEGER := BINARY_INTEGER := BOOLEAN := NULL, BOOLEAN := NULL, BINARY_INTEGER := BINARY_INTEGER := BINARY_INTEGER := BINARY_INTEGER :=

NULL, NULL,

NULL, NULL, NULL, NULL);

1 2 .5 .2 Abou t t h e Pa r a m e t e r s Som e of t he param et ers in SCHEDULE_EXECUTI ON and SCHEDULE_PUSH are not int uit ive. Here we discuss t he nonobvious param et ers:

275

Oracle Distributed Systems st op_on_error Set t ing t he Boolean param et er st op_on_error t o FALSE ( t he default ) causes Oracle t o cont inue propagat ing and execut ing deferred RPCs at dblink ( Oracle7) or dest inat ion ( Oracle8) even if one or m ore of t he calls encount ers an error. Set t ing t his param et er t o TRUE causes execut ion of deferred RPCs t o st op if an error occurs at t he dest inat ion sit e. t ransact ion_count and execut ion_seconds These t wo param et ers are usually used in t andem . They cause propagat ion of RPCs t o dest inat ion t o cease aft er execut ion_seconds seconds or t ransact ion_count t ransact ions, whichever com es first . These param et ers provide a m et hod of t hrot t ling t he t im e and resources t hat are consum ed during any one call t o DBMS_DEFER_SYS.EXECUTE ( Oracle7) or DBMS_DEFER_SYS.PUSH ( Oracle8) . Since t hese set t ings m ay cause t he propagat ion t o st op before all deferred RPCs are sent , it is your responsibilit y t o m onit or t he DEFTRANDEST dat a dict ionary view and/ or schedule aut om at ic propagat ion at int ervals. The default for bot h of t hese param et ers is 0, which m eans t hat no such lim it s are set . execut e_as_user ( obsolet e in Oracle8) This param et er det erm ines t he privilege dom ain under which t he procedure call execut es at t he dest inat ion. Set t ing execut e_as_user t o FALSE ( t he default ) causes t he call t o execut e under t he privilege dom ain of t he user who queued t he call originally, as seen in t he ORI GI N_USER colum n of t he DEFTRAN dat a dict ionary view. Set t ing it t o TRUE execut es t he call under t he privilege dom ain of t he session t hat calls DBMS_DEFER_SYS.EXECUTE ( Oracle7) or DBMS_DEFER_SYS.PUSH ( Oracle8) . The user in execut e_as_user refers t o t he user calling DBMS_DEFER_SYS.EXECUTE ( Oracle7) or DBMS_DEFER_SYS.PUSH ( Oracle8) , not t o t he user who queued t he call. delay_seconds This param et er causes DBMS_DEFER_SYS.EXECUTE ( Oracle7) or DBMS_DEFER_SYS.PUSH ( Oracle8) t o sleep for delay_seconds seconds before ret urning when it finishes propagat ing t he queued t ransact ions t o dest inat ion. The prim ary purpose of t his param et er is t o delay t he next call t o DBMS_DEFER_SYS.EXECUTE ( Oracle7) or DBMS_DEFER_SYS.PUSH ( Oracle8) , t he idea being t hat m ore t ransact ions will have a chance t o accum ulat e and be pushed by t he sam e call t o DBMS_DEFER_SYS.EXECUTE ( Oracle7) or DBMS_DEFER_SYS.PUSH ( Oracle8) . I t is m ore efficient t o propagat e five deferred RPCs wit h one call t o DBMS_DEFER_SYS.EXECUTE ( Oracle7) or DBMS_DEFER_SYS.PUSH ( Oracle8) t han wit h five calls. This param et er is relevant only if you have scheduled aut om at ic propagat ion. You can sim ulat e synchronous propagat ion by set t ing delay_seconds t o a very high value. bat ch_size

276

Oracle Distributed Systems bat ch_size is t he num ber of deferred calls t o execut e bet ween com m it s. The default is 0, which m eans t hat a com m it should occur for each deferred t ransact ion t hat is propagat ed. I f you are queuing a relat ively low volum e of deferred RPCs, t hese addit ional param et ers cont rolling t he volum e and t im ing of deliveries are not ext rem ely relevant . They are really provided for fine- t uning t he behavior and perform ance of aut om at ically scheduled RPCs, such as t hose associat ed wit h t he advanced replicat ion facilit ies.

1 2 .5 .3 Pa r a lle l Pr opa ga t ion I n Oracle7, t he dat abase pushes t he deft ran queue t o each m ast er sit e serially, so t ransact ions are applied in t he sam e order at t he dest inat ion dat abase as t hey were at t he originat ing dat abase. This m et hodology is adequat e for applicat ions t hat do not generat e a t rem endous volum e of DML act ivit y, but for high t hroughput applicat ions such as OLTP or m any web- based applicat ions, t he serial push can have a hard t im e keeping up wit h t he t ransact ion flow.

Even if you set parallelism t o 1, you will not ice im proved t hroughput over serial propagat ion of DML pushes because serial propagat ion uses a t wo- phase com m it prot ocol, w hile parallel propagat ion does not .

The engineers at Oracle recognized t hat t ransact ions do not necessarily need t o be applied in t he sam e chronological order at bot h t he origin and t he dest inat ion. For exam ple, t ransact ions against t ables t hat have no relat ionship wit h one anot her can be applied sim ult aneously. The act ual algorit hm t hat Oracle uses t o det erm ine t ransact ion dependencies is based on t he SCN ( syst em change num ber) in t he blocks t hat t he t ransact ion m odifies. So, updat es t o t he sam e t able m ay be candidat es for parallel propagat ion. There are a num ber of fact ors t hat can influence t he perform ance gain you realize by using parallel propagat ion, such as how densely your dat a is packed; t he m ore records a t able st ores in a single block, t he less likely t hat t ransact ions against t he t able can be parallelized because of t he increased likelihood t hat m ult iple t ransact ions t ouch t he sam e block. ( You can cont rol dat a densit y wit h t he st orage param et ers PCTFREE and PCTUSED.) Anot her behavior of parallel propagat ion is t hat t ransact ions originat ing from t he sam e dat abase session are not parallelized. So, applicat ions t hat run wit h one ( or very few) dat abase connect ions are not likely t o not ice a t rem endous boost . Applicat ions t hat have num erous connect ions perform ing DML and t hose wit h a m ix of independent t ransact ions will not ice a significant benefit .

I t is act ually possible t o enable parallel propagat ion of a single session's t ransact ios by issuing t his com m and:

277

Oracle Distributed Systems

ALTER SESSION SET EVENTS '26567 TRACE NAME CONNECT FOREVER, LEVEL'

1 2 .5 .3 .1 M a n a gin g pa r a lle l pr opa ga t ion To enable parallel propagat ion, you m ust set t he parallelism param et er in t he call t o DBMS_DEFER_SYS.SCHEDULE_PUSH. For exam ple: execute dbms_defer_sys.schedule_push( destination => 'PMFG.BIGWHEEL.COM', interval => 'SYSDATE+5/86400', next_date => SYSDATE+5/86400, transaction_count => 10000, parallelism => 8); This call enables parallel propagat ion for all replicat ion groups' deft ran pushes t o t he dat abase PMFG.BI GWHEEL.COM. Parallel propagat ion relies on t he parallel query background processes t o do it s bidding. To ensure t hat t he propagat ions have t he resources t hey need, do t he following: •

•

Not e t he set t ings of t he init ializat ion param et ers PARALLEL_MI N_SERVERS and PARALLEL_MAX_SERVERS. The default value for PARALLEL_MI N_SERVERS is 0. You should set t his value at least as high as t he highest degree of parallelism you have specified in your calls t o DBMS_DEFER_SYS.SCHEDULE_PUSH, preferably higher. The PARALLEL_MAX_SERVERS value should be set high enough t o support sim ult aneous parallel pushes t o all m ast er dat abases. Be aware t hat t he server background processes t hat service parallel propagat ion are t he sam e background processes t hat support parallel queries. Therefore, if your applicat ion ut ilized t he parallel query opt ion ( i.e., DEGREE is great er t han 1 for any t ables in DBA_TABLES) m ake sure t hat your PARALLEL_MAX_SERVERS can support t he replicat ion propagat ion and t he parallel query act ivit y. I recom m end against using t he parallel query opt ion on replicat ed t ables if you are also using parallel propagat ion.

When using parallel propagat ion, Oracle m ust be able t o use t he sam e num ber of parallel query background processes as t he value of parallelism in t he call t o DBMS_DEFER_SYS.PUSH. This behavior differs from parallel queries, which can funct ion even if t he query cannot allocat e t he num ber of parallel query background processes required t o support t he request ed degree of parallelism .

278

Oracle Distributed Systems I f a parallel push fails because it could not acquire enough parallel query background processes, t he push will fail; Oracle does not reat t em pt t he push using serial propagat ion.

1 2 .5 .3 .2 Ch e ck in g pa r a lle l pu sh e s When a parallel push execut es successfully, you will see m ult iple connect ions t o t he dest inat ion dat abase: SELECT

sid, serial#, username, osuser, process, substr(program, decode (instr(program,':'),0,1, (instr(program,':')+1)),32) FROM v$session WHERE username = 'PROPREP' ORDER BY username SID S# Username ----- ------ --------18 17700 PROPREP 20 41600 PROPREP 22 62490 PROPREP 38 7124 PROPREP 63 58713 PROPREP 72 42205 PROPREP 64 50893 PROPREP 58 41460 PROPREP 8 rows selected.

program

OS User PROCESS PROGRAM --------- --------- -----------------------oracle 4014 oracle@walrus (P004) oracle 4012 oracle@walrus (P003) oracle 4016 oracle@walrus (P005) oracle 4010 oracle@walrus (P002) oracle 4020 oracle@walrus (P007) oracle 4006 oracle@walrus (P000) oracle 4018 oracle@walrus (P006) oracle 4008 oracle@walrus (P001)

These sessions exist in t he dest inat ion dat abase only during t he act ual deft ran push. I f t hings are working sm oot hly, t hey should not st ay connect ed for very long— t ypically less t han a m inut e. I f t he connect ions rem ain for longer, it oft en indicat es t hat Oracle has det ect ed and is resolving a conflict .

1 2 .5 .3 .3 Pa r a lle l push e r r or s Under cert ain circum st ances, it is possible for parallel propagat ion t o " seize up" by encount ering an error from which it cannot recover. These errors are usually relat ed t o resource issues rat her t hen propagat ion conflict s. The sym pt om s are usually alarm ingly obvious; t ransact ions are queueing up at t he origin sit e( s) , and t here is no propagat ion act ivit y at t he dest inat ion sit es. You also m ay see errors like t his in t race files or at t he SQL* Plus prom pt if you at t em pt t o push t he queue m anually: ORA-12012: ORA-23388: ORA-06512: ORA-06512:

error on auto execute of job 501 replication parallel push watermark error at "SYS.DBMS_DEFER_SYS", line 1448 at line 1

279

Oracle Distributed Systems The root of t he problem is a record in t he t able SYSTEM.DEF$_DESTI NATI ON at t he originat ing sit e. This t able cont ains one record for every dat abase t hat is receiving pushes. The value of t he last _seq colum n is norm ally eit her NULL or 0. I f it holds anot her value, t hen t he last parallel push failed; t he last _error_num ber and last _error_m essage fields should cont ain det ails. For exam ple, suppose t hat propagat ion from our headquart ers sit e ( PHQS.BI GWHEEL.COM) t o our m anufact uring sit e ( PMFG.BI GWHEEL.COM) has ceased. We can query SYSTEM.DEF$_DESTI NATI ON at t he headquart ers sit e t o get an idea of t he problem : SELECT

FROM /

dblink, last_delivered, last_enq_tid, last_seq, disabled, job, last_txn_count, last_error_number, last_error_message system.def$_destination D i s a b l

Last

Last

Last

e

Txn

Error

Seq

d

Count

Number

----

-

Last Last Last Enq Error DB Link Delivered TID Message ----------------- --------- --------PSLS.BIGWHEEL.COM 525424 PMFG.BIGWHEEL.COM 525424 Exceeded call

0 1

Job

---- ------ ------271 382

262 1301

-------

-2395 limit

on io usage Here we see t hat t he propagat ion t o PMFG.BI GWHEEL.COM failed because t he propagat or process in t he rem ot e dat abase exceeded a resource lim it . We can rem edy t he sit uat ion by following t hese st eps: 1. Query t he t able SYSTEM.DEF$_ORI GI N at t he dest inat ion sit e ( PMFG.BI GWHEEL.COM in t his case) t o det erm ine what t ransact ions have already been delivered from PHQS.BI GWHEEL.COM: 2. SELECT enq_tid, origin_dblink 3. FROM system.def$_origin 4. WHERE enq_tid = 'PHQS.BIGWHEEL.COM' 5. / 6.

280

Oracle Distributed Systems 7. ENQ_TID 8. ------------9. 3.6.436763 10. 6.2.4574 5.8.53272

ORIGIN_DBLINK ------------------PHQS.BIGWHEEL.COM PHQS.BIGWHEEL.COM PHQS.BIGWHEEL.COM

11. Delet e t hese t ransact ions from t he deft ran queue at t he origin sit e ( PHQS.BI GWHEEL.COM) : 12. EXECUTE dbms_defer_sys.delete_tran('3.6.436763', 'PHQS.BIGWHEEL.COM'); 13. PL/SQL procedure successfully completed. 14. 15. EXECUTE dbms_defer_sys.delete_tran('6.2.4574', 'PHQS.BIGWHEEL.COM'); 16. PL/SQL procedure successfully completed. 17. 18. EXECUTE dbms_defer_sys.delete_tran('5.8.53272', 'PHQS.BIGWHEEL.COM'); 19. PL/SQL procedure successfully completed. 20. COMMIT; 21. Updat e t he t able SYSTEM.DEF$_DESTI NATI ON at t he origin sit e ( PHQS.BI GWHEEL.COM) : 22. UPDATE SYSTEM.DEF$_DESTINATION 23. SET last_seq = 0 24. WHERE dblink = 'PMFG.BIGHWEEL.COM 25. / 1 row updated. 26. At t his point , you should be able t o resum e propagat ion from PHQS.BI GWHEEL.COM t o PMFG.BI GWHEEL.COM. I t is best t o at t em pt a m anual serial push first , followed by a m anual parallel push. I f t hese pushes are successful, you can safely reschedule aut om at ic propagat ion.

Do not use t his procedure unless you are sure t hat propagat ion has ceased. Sym pt om s include propagat ors logged in t o t he dest inat ion account s t hat are not doing anyt hing and a lack of net work t raffic bet ween t he originat ing dat abase server and t he dest inat ion dat abase server.

Bu g Upda t e Oracle has ident ified t wo bugs ( num bers 737918 and 734902) t hat can cause dscn t o be great er t han cscn in t he t able SYSTEM.DEF$_AQCALL. When t his corrupt ion occurs, parallel propagat ion hangs.

281

Oracle Distributed Systems

Wit h Oracle's blessing, using a BEFORE UPDATE t rigger on t he t able avoids t he corrupt ion as follows: CREATE OR REPLACE TRIGGER t_bu_def$_aqcall BEFORE UPDATE ON def$_aqcall FOR EACH ROW BEGIN IF (:new.dscn > :new.cscn) THEN :new.dscn := :new.cscn; END IF; END; / These bugs are slat ed t o be fixed in version 8.0.4.4. We recom m end cont act ing Oracle Worldwide Support for a st at us updat e if you int end t o use parallel propagat ion.

1 2 .5 .3 .4 Syn ch r on ou s ve r su s a synchr onous pr opa ga t ion Synchronouspropagat ion uses a t wo- phase com m it prot ocol t o guarant ee t hat t ransact ions are com m it t ed locally if and only if t hey are also applied at t he dest inat ion dat abase( s) . Therefore, if a rem ot e dat abase cannot be reached or if a t ransact ion cannot be com m it t ed for any reason, t hen all DML act ivit y will hang. Because synchronous replicat ion has such st ringent requirem ent s and because a failure has such dram at ic consequences, m ost sit es do not use it . I nst ead of adding a level of redundancy, synchronous replicat ion effect ively adds an addit ional dependency. We recom m end t he use of asynchronous propagat ion unless your business case clearly calls for t he synchronous approach. That being said, if you wish t o swit ch bet ween propagat ion m odes, you can do so using t he package procedure DBMS_REPCAT.ALTER_MASTER_PROPAGATI ON: PROCEDURE alter_master_propagation( gname IN VARCHAR2, master IN VARCHAR2, dblink_table IN dbms_utility.dblink_array, propagation_mode IN VARCHAR2 := 'ASYNCHRONOUS', comment IN VARCHAR2 := ''); PROCEDURE alter_master_propagation( gname IN VARCHAR2, master IN VARCHAR2, dblink_list IN VARCHAR2, propagation_mode IN VARCHAR2 := 'ASYNCHRONOUS', comment IN VARCHAR2 := '');

282

Oracle Distributed Systems

The replicat ion group gnam e m ust be quiesced in order t o use t he ALTER_MASTER_PROPAGATI ON procedure. I n addit ion, you m ust regenerat e replicat ion support for all obj ect s in t he group before resum ing norm al act ivit y.

1 2 .5 .3 .5 Sch e du lin g m u lt iple push in t e r va ls for t h e sa m e da t a ba se One of t he lim it at ions of advanced replicat ion is t hat you cannot schedule different propagat ion int ervals for different replicat ion groups. The propagat ion int erval bet ween m ast er sit es is t he sam e for all replicat ion groups at t hose sit es. I t m ight be convenient , for exam ple, t o push changes t o invent ory m ore frequent ly t han changes in prices. Of course, t here is a workaround, which is, in effect , t o give t he sam e dest inat ion dat abase m ult iple nam es and schedule different propagat ion int ervals t o t he different nam es. How do you give a dat abase t wo nam es? By using connect ion qualifiers. For exam ple, you could creat e t wo nam es for t he PMFG sit e by creat ing dat abase links as follows: CREATE PUBLIC DATABASE LINK PMFG.BIGWHEEL.COM USING 'prodmanufacturing'; and CREATE PUBLIC DATABASE LINK PMFG.BIGWHEEL.COM@TCP USING 'prodmanufacturing'; Then you can use different propagat ion int ervals t o t hese t wo " different " sit es and add our replicat ion groups t o one sit e or t he ot her based on how frequent ly t he group's dat a is updat ed. Beware t hat t his solut ion is not wit hout cost . Maint enance t asks becom e m ore com plicat ed. For exam ple, if you want t o t ake t he m anufact uring sit e out of service, you m ust issue t wo calls t o DBMS_DEFER_SYS.UNSCHEDULE_EXECUTI ON—one for each nam e. You m ust also creat e addit ional dat abase links using each nam e for account s such as REPADMI N and t he replicat ion propagat or account . Finally, you should avoid configurat ions t hat lead t o t ransact ions t hat involve m ult iple replicat ion groups.

1 2 .6 Th e Re plica t ion Ca t a log The replicat ion cat alog is t he subset of t he dat a dict ionary t hat cont ains inform at ion about replicat ed obj ect s at all m ast er sit es and, t o a cert ain ext ent , snapshot sit es. Operat ions t hat m odify t he dat a in t he replicat ion cat alog, such as adding or rem oving m ast er obj ect s, m ust be propagat ed from t he m ast er definit ion sit e t o ot her m ast er sit es. I n general, changes t o t he replicat ion cat alog require t hat t he

283

Oracle Distributed Systems affect ed replicat ion group be quiesced. Just as Oracle m aint ains a deferred t ransact ion queue ( deft ran) for queued t ransact ions, it also m aint ains a queue for replicat ion cat alog changes, known as t he repcat log. The 10 DBMS_REPCAT calls which creat e ent ries in t he repcat log queue are: DBMS_REPCAT.ADD_MASTER_DATABASE DBMS_REPCAT.ALTER_MASTER_PROPAGATI ON DBMS_REPCAT.ALTER_MASTER_REPOBJECT DBMS_REPCAT.CREATE_MASTER_REPOBJECT DBMS_REPCAT.DROP_MASTER_REPGROUP DBMS_REPCAT.DROP_MASTER_REPOBJECT DBMS_REPCAT.EXECUTE_DDL DBMS_REPCAT.GENERATE_REPLI CATI ON_SUPPORT DBMS_REPCAT.RESUME_MASTER_ACTI VI TY DBMS_REPCAT.SUSPEND_MASTER_ACTI VI TY

1 2 .6 .1 Re plica t ion Ca t a log D a t a D ict ion a r y Vie w s The dat a dict ionary views t hat m ake up t he replicat ion cat alog are t he following: DBA_REPCAT Nam e, st at us, and com m ent for every replicat ion group. ( Sam e as DBA_REPGROUP.) DBA_REPCATLOG List s all it em s in t he repcat log queue. DBA_REPDDL List s all DDL calls in t he repcat log queue. DBA_REPGENERATED List s all replicat ion support obj ect s. DBA_REPGROUP Nam e, st at us, and com m ent for every replicat ion group. ( Sam e as DBA_REPCAT.) DBA_REPKEY_COLUMNS List s key colum ns for all replicat ed t ables. These colum ns are eit her prim ary key colum ns or colum ns t hat have been ident ified wit h DBMS_REPCAT.SET_COLUMNS. DBA_REPOBJECT

284

Oracle Distributed Systems List s all replicat ed obj ect s. DBA_REPPROP List s propagat ion m ode for all replicat ed obj ect s t o all sit es. DBA_REPSI TES List s sit es t hat are m em bers of each replicat ion group. Appendix B, includes script s t o generat e useful report s from t hese dat a dict ionary views.

1 2 .6 .2 Pu sh in g r e pca t log En t r ie s Youm ay have not iced t hat whenever you creat e a replicat ion group, Oracle aut om at ically m akes an ent ry in t he j ob queue t hat looks som et hing like t his: system@live SQL> SELECT job, what 2 FROM dba_jobs 3 WHERE what like '%do_deferred_repcat_admin%' 4 / Job What ---- --------------------------------------------------------------------241 dbms_repcat.do_deferred_repcat_admin('"RG_SPROCKET"', FALSE); DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMI N is t he procedure t hat processes repcat log ent ries in t he local dat abase. I f t he procedure is called wit h all_sit es set t o TRUE, t he procedure will also perform t he adm inist rat ive t asks at rem ot e m ast ers. By default , Oracle schedules t his j ob at every m ast er dat abase t o run once every 10 m inut es, wit h all_sit es set t o FALSE. The m ost com m on chores for ent ries in t he repcat log queue are suspending or resum ing m ast er act ivit y, adding and dropping replicat ed obj ect s, and generat ing replicat ion support . The default frequency of 10 m inut es is adequat e for m ost sit uat ions, but if you wish t o expedit e t he repcat log queue execut es, you can call DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMI N m anually when logged in t o t he replicat ion adm inist rat or ( REPADMI N) account .

1 2 .6 .3 M on it or in g Pr ogr e ss Once you creat e ent ries in t he repcat log queue wit h calls t o procedures such as DBMS_REPCAT.ADD_MASTER_DATABASE, you can query t he dat a dict ionary view DBA_REPCATLOG at all m ast er sit es t o det erm ine t he st at us of your operat ions. Table 12.2 describes t he m eanings of all possible st at us values.

Table 12.2. Explanation of Status Column in DBA_REPCATLOG

285

Oracle Distributed Systems

Status

Meaning

READY

The sit e is ready t o execut e t he request . The next call t o DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMI N will execut e t he pending request .

DO_CALLBACK

Oracle is updat ing t he st at us of a request from a rem ot e dat abase.

AWAI T_CALLBACK

Oracle is await ing feedback from a rem ot e dat abase about t he com plet ion of a t ask, such as generat ing replicat ion support .

ERROR

The request has failed. I nform at ion about t he failure is available in t he DBA_REPCATLOG fields ERRNUM and MESSAGE.

Sim ilarly, t he REQUEST field t ells what t he current repcat log request is. Table 12.3 describes t he request s t hat can be queued.

Table 12.3. Explanation of REQUEST Column in DBA_REPCATLOG Request

Meaning

CREATE_MASTER_REPOBJECT

Add new replicat ed obj ect .

DROP_MASTER_REPSCHEMA

Drop replicat ion group.

ADD_MASTER_DATABASE

Add m ast er dat abase t o replicat ion group.

ALTER_MASTER_REPOBJECT

Perform DDL on an exist ing replicat ed obj ect .

DROP_MASTER_REPOBJECT

Drop a m ast er replicat ed obj ect .

SUSPEND_MASTER_ACTI VI TY

Quiesce a replicat ion group.

RESUME_MASTER_ACTI VI TY

Resum e norm al act ivit y for a replicat ion group.

EXECUTE_DDL

Perform DDL.

GENERATE_REPLI CATI ON_SUPPORT

Begin generat ion of replicat ion support for a replicat ed obj ect .

GENERATE_SUPPORT_PHASE_1

Generat e replicat ion support ; phase 1.

GENERATE_SUPPORT_PHASE_2

Generat e replicat ion support ; phase 2

ALTER_MASTER_PROPAGATI ON

Alt er propagat ion m ode ( bet ween SYNCHRONOUS and ASYNCHRONOUS) .

END_PHASE_2

End of replicat ion support generat ion.

I t is usually best not t o subm it num erous ( as in scores) of request s t o t he repcat log all at once, because an error in any one request can delay subsequent request s.

The following script report s t he relevant det ails about request s in t he repcat log queue: --------------------------------------------------------------------------- Filename: repcatlog.sql -- Purpose: Lists all tasks pending in dba_repcatlog queue.

286

Oracle Distributed Systems -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column SOURCE heading "Source" format a6 column MASTER heading "Master" format a6 column SNAME heading "Group" format a10 column STATUS heading "Status" format a14 column REQUEST heading "Request" format a28 column TIMESTAMP heading "Time" format a8 SELECT

substr(source, 1, instr(source, '.', 1) -1 ) source, substr(master, 1, instr(master, '.', 1) -1 ) master sname, status, request, to_char(timestamp, 'HH24:MI:SS') timestamp FROM dba_repcatlog ORDER BY master /

1 2 .6 .4 Cor r e ct in g Er r or s Errors t hat occur during repcat log execut ions log diagnost ics in t he ERRNUM and MESSAGE fields of DBA_REPCATLOG. You can eit her correct t he cause of t he error ( such as a privilege short age) or rem ove t he request from t he repcat log queue. The following script report s on errors and generat es t he t ext of t he required call t o DBMS_REPCAT.PURGE_MASTER_LOG t o delet e t he repcat log queue ent ry: --------------------------------------------------------------------------- Filename: repcaterr.sql -- Purpose: Lists entries in dba_repcatlog with error status. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column ID heading "Id" format 9999 column SOURCE heading "Source" format a20 column SNAME heading "Schema" format a8 column REQUEST heading "Request" format a22 column ONAME heading "Object" format a20 column ERRNUM heading "Error" format 99999 column MESSAGE heading "Message" format a74 SELECT id, status, sname, request, oname, errnum FROM dba_repcatlog WHERE status = 'ERROR' ORDER BY id / SELECT id, message FROM dba_repcatlog WHERE status = 'ERROR' ORDER BY id

287

Oracle Distributed Systems / set head off SELECT 'Run these commands to purge...' FROM dual / set head on SELECT 'EXECUTE dbms_repcat.purge_master_log('|| id ||', ' ||chr(39)||rtrim(source)||chr(39)||', ' ||chr(39)||gname||chr(39)||');' command FROM dba_repcatlog WHERE status = 'ERROR' / Sam ple out put : SQL> @repcaterr Id Status Schema Request Object Error ----- --------- -------- ---------------------- -------------- -----664 ERROR SPROCKET DROP_MASTER_REPOBJECT PRODUCTS -1013 1 row selected. Id Message ----- -------------------------------------------------------------------664 ORA-01013: user requested cancel of current operation 1 row selected. Run these commands to purge... 1 row selected. COMMAND -------------------------------------------------------------------------EXECUTE dbms_repcat.purge_master_log(664, 'LIVE.WORLD', 'RG_LIVESTK'); 1 row selected. The DBMS_REPCAT package does not include a procedure t o ret ry failed repcat log request s, so you m ust always delet e t he failed ent ry and ret ry t he request aft er t he underlying problem is correct ed.

You m ust issue a COMMI T aft er calling DMBS_REPCAT.PURGE_MASTER_LOG.

288

Oracle Distributed Systems

1 2 .7 Ta ble Re plica t ion Cert ainly t he m ost versat ile and int riguing com ponent of Oracle's advanced replicat ion facilit y is m ult i- m ast er t able replicat ion. Any replicat ed t able can be updat ed anywhere, and t he changes will appear in all part icipat ing m ast er sit es. However, as wit h any sophist icat ed t echnology, you m ust configure m ult i- m ast er replicat ion wit h great care in order t o avoid perils and pit falls. This sect ion describes t he API calls used t o creat e and t o m aint ain replicat ed t ables, point s out t echniques t o m ake t he adm inist rat ion j ob easier, and describes som e pract ices t hat will help you t o avoid t rouble.

1 2 .7 .1 API Ca lls The fundam ent al DBMS_REPCAT procedures for adm inist ering replicat ed t ables are as follows: DBMS_REPCAT. ADD_UNI QUE_RESOLUTI ON Adds a uniqueness conflict resolut ion handler t o t he t able. DBMS_REPCAT .ADD_UPDATE_RESOLUTI ON Adds an updat e conflict resolut ion handler t o t he t able. DBMS_REPCAT. DEFI NE_COLUMN_GROUP Creat es an em pt y colum n group. DBMS_REPCAT. DROP_COLUMN_GROUP Drops a colum n group. DBMS_REPCAT. DROP_UNI QUE_RESOLUTI ON Drops a uniqueness conflict handler. DBMS_REPCAT. DROP_UPDATE_RESOLUTI ON Drops an updat e conflict handler. DBMS_REPCAT. MAKE_COLUMN_GROUP Creat es a colum n group and assigns colum ns t o t he group. DBMS_REPCAT. SEND_AND_COMPARE_OLD_VALUES Specifies which colum ns should send t heir previous values t o rem ot e sit es for com parison during updat es and delet es.

289

Oracle Distributed Systems DBMS_REPCAT. SET_COLUMNS Specifies t he colum n( s) t o use t o uniquely ident ify records in t he t able. You m ay not ice t hat m any of t hese procedures are associat ed wit h configuring conflict resolut ion m et hods, which is a t est am ent t o t he fact t hat conflict det ect ion and resolut ion is a crucial com ponent of a m ult i- m ast er replicat ed environm ent . Chapt er 15 is devot ed t o conflict resolut ion t echniques.

1 2 .7 .2 Colu m n Gr ou ps I recom m end t hat you specifically define colum n groups for every replicat ed t able, as opposed t o allowing colum ns t o be assigned t o t he " shadow" colum n group t hat Oracle creat es by default . This way, it is easier t o adm inist er conflict resolut ion for t he t able. For t ables whose conflict resolut ion m et hods are not dict at ed by specific business rules or ot her requirem ent s, I suggest including a t im est am p and sit e_nam e field so t hat you can easily assign bot h a t im e- based and sit e- priorit y- based resolut ion m et hod t o t he t able, as follows. Consider t he t able REGI ONS: system@d8ca SQL> desc regions Name Null? Type ------------- ------------------REGION_ID NOT NULL NUMBER(6) COUNTRY_ID NOT NULL NUMBER(6) REGION_NAME NOT NULL VARCHAR2(15) AUDIT_DATE NOT NULL DATE AUDIT_USER NOT NULL VARCHAR2(30) GLOBAL_NAME NOT NULL VARCHAR2(20) The following procedure calls creat e a colum n group CG_REGI ONS and assign t im ebased and sit e- priorit y- based conflict resolut ion m et hods: -- Create the column group; include all columns. EXECUTE dbms_repcat.make_column_group( sname => 'SPROCKET',oname => 'REGIONS',column_group => 'CG_REGIONS',list_of_column_names => '*'); -- Add a site-priority-based resolution method. (This assumes the site -- priority group SP_SPROCKET_SITE has already been created.) EXECUTE dbms_repcat.add_update_resolution( sname => 'SPROCKET', oname => 'REGIONS', column_group => 'CG_REGIONS', sequence_no => 20, method => 'SITE PRIORITY', parameter_column_name => 'GLOBAL_NAME', priority_group => 'SP_SPROCKET_SITE', -

290

Oracle Distributed Systems comment

=> 'Added by '||user||' on '||sysdate);

-- Add a timestamp-based resolution method. EXECUTE dbms_repcat.add_update_resolution( sname => 'SPROCKET', oname => 'REGIONS', column_group => 'CG_REGIONS', sequence_no => 10, method => 'LATEST TIMESTAMP', parameter_column_name => 'AUDIT_DATE', comment => 'Added by '||user||' on '||sysdate);

The overhead of processing unresolved conflict s, while reduced in Oracle8, is st ill expensive, especially in an environm ent wit h a high t ransact ion volum e. I t is im perat ive t hat every replicat ed t able have at least one, and preferably t wo, conflict resolut ion m et hods defined. You will find t hat conflict s will arise no m at t er how carefully you design t he applicat ion. Chapt er 15 cont ains inform at ion about m ore advanced usages of colum n groups. For t ables t hat don't require advanced t echniques, you can use t he m et hod j ust described.

1 2 .7 .3 M in im u m Com m u n ica t ion a n d SEN D _ AN D _ COM PARE_ OLD _ VALUES When Oracle replicat es an updat e or delet e operat ion, it ensures t hat t he row it updat es or delet es in t he rem ot e dat abase( s) is t he sam e as t he record t hat it updat ed or delet ed in t he local dat abase. The default behavior is t o com pare t he current dat a in every field of t he rem ot e dat abase wit h t he prechange dat a in t he local dat abase. Needless t o say, t his com parison can lead t o a great deal of net work t raffic and subst ant ial processing overhead, part icularly for large VARCHAR fields. Ent er Oracle8 and t he m inim um com m unicat ion opt ion. This feat ure allows you t o specify t hat updat es com pare t he values of changed colum n groups only. The m in_com m unicat ion param et er in t he DBMS_REPCAT.GENERATE_REPLI CATI ON_SUPPORT procedure dict at es whet her t he m inim um com m unicat ion feat ure is act ivat ed. The param et er is set t o TRUE by default . The DBMS_REPCAT.SEND_AND_COMPARE_OLD_VALUES procedure, also new t o Oracle8, allows you t o t ake m inim um com m unicat ion t o an ext rem e by let t ing you define what colum ns t o com pare on updat es and delet es. I f you want t o, you can rest rict t he com parison of old and new values t o t he prim ary key colum ns only. Alt hough drast ic, t his m inim izat ion can be appropriat e for cert ain OLTP applicat ions and/ or for dat abases t hat are connect ed by an expensive and/ or inefficient int erface, such as a sat ellit e relay or t he I nt ernet . As a pract ical m at t er, t he m ost m inim izat ion

291

Oracle Distributed Systems t hat you should consider would include prim ary key colum ns and all colum ns used in conflict resolut ion m et hods.

I ndiscrim inat e use of SEND_AND_COMPARE_OLD_VALUES can effect ively disable all conflict resolut ion t echniques, result ing in divergent dat a. The specificat ion for DBMS_REPCAT.SEND_AND_COMPARE_OLD_VALUES is as follows: PROCEDURE send_and_compare_old_values( sname IN VARCHAR2, oname IN VARCHAR2, column_list IN VARCHAR2, operation IN VARCHAR2 := 'UPDATE', send IN BOOLEAN := TRUE); PROCEDURE send_and_compare_old_values( sname IN VARCHAR2, oname IN VARCHAR2, column_table IN dbms_repcat.varchar2s, operation IN VARCHAR2 := 'UPDATE', send IN BOOLEAN := TRUE); Table 12.4 describes t he usage of t hese param et ers in t he SEND_AND_COMPARE_OLD_VALUES procedure.

Table 12.4. Parameter Usage for SEND_AND_COMPARE_OLD_VALUES Parameter Name

Comments

snam e

The owner of t he replicat ed t able.

onam e

The nam e of t he replicat ed t able

colum n_list

A com m a- separat ed st ring of colum ns t o operat e on. An ast erisk ( * ) indicat es all nonkey colum ns. Use eit her colum n_list or colum n_t able.

colum n_t able

A PL/ SQL t able of colum ns t o operat e on. Use eit her colum n_list or colum n_t able.

operat ion

One of UPDATE, DELETE, or * , wit h * m eaning bot h UPDATE and DELETE.

send

I f send is TRUE, t he specified colum ns are sent . I f FALSE, t he specified colum ns are not sent . Unspecified colum ns are not affect ed.

Changes specified in calls t o SEND_AND_COMPARE_OLD_VALUES t ake effect t he next t im e you generat e replicat ion support for t he t able. Ret urning t o t he REGI ONS t able, you could m ake t he following call t o rest rict t he old values t hat Oracle sends t o rem ot e dat abases t o REGI ON_I D ( t he prim ary key) , AUDI T_DATE, and GLOBAL_NAME:

292

Oracle Distributed Systems EXECUTE dbms_repcat.send_and_compare_old_values( sname => 'SPROCKET', oname => 'REGIONS', column_list => 'COUNTRY_ID,REGION_NAME,AUDIT_USER', operation => '*', send => FALSE); EXECUTE dbms_repcat.generate_replication_support( sname => 'SPROCKET', oname => 'REGIONS', type => 'TABLE', distributed => TRUE, min_communication => TRUE);

1 2 .7 .4 Tr igge r s on Re plica t e d Ta ble s Triggers on replicat ed t ables m ust t ake int o account t hat DML act ivit y m ay be t he result of Oracle's replicat ing a rem ot e t ransact ion. For exam ple, if you have an I NSERT t rigger t hat populat es a t im est am p field, you would probably want t he t rigger t o fire when t he I NSERT occurs at t he original sit e, but not at all of t he ot her replicat ed m ast er sit es. You m ay also wish t o use t riggers t o populat e fields t hat Oracle uses for conflict resolut ion, such as t he AUDI T_DATE and GLOBAL_NAME fields. The exam ples in t he following sect ions dem onst rat e how t o writ e t riggers on replicat ed t ables.

1 2 .7 .4 .1 A t r igge r t o popu la t e fie lds a t t h e or igin a t in g sit e on ly Because of t he condit ion—I F ( dbm s_reput il.from _rem ot e ! = TRUE) —t his t rigger updat es t he AUDI T_DATE and GLOBAL_NAME fields only if t he DML is local, as opposed t o a deferred t ransact ion from a rem ot e dat abase: CREATE OR REPLACE TRIGGER t_br_iu_regions BEFORE INSERT OR UPDATE ON regions FOR EACH ROW BEGIN IF (dbms_reputil.from_remote != TRUE) THEN :new.audit_date := SYSDATE; :new.global_name := DBMS_REPUTIL.GLOBAL_NAME; END IF; END; /

1 2 .7 .4 .2 A t r igge r t o popu la t e a fie ld fr om a se qu e n ce on in se r t s a n d fie lds u se d for con flict r e solu t ion This t rigger illust rat es how t o populat e prim ary key fields from sequences for replicat ed t ables:

293

Oracle Distributed Systems CREATE OR REPLACE TRIGGER t_br_iu_regions BEFORE INSERT OR UPDATE ON regions FOR EACH ROW BEGIN IF (dbms_reputil.from_remote != TRUE) THEN IF INSERTING THEN SELECT seq_regions.nextval INTO :new.region_id FROM dual; END IF; :new.rectime := SYSDATE; :new.site := DBMS_REPUTIL.GLOBAL_NAME; END IF; END; /

All of t he t riggers t hat Oracle creat es t o support t he replicat ion of a t able are aft er- row t riggers. I t is best for applicat ions t o use before- row t riggers so t hat t hey are guarant eed t o fire before t he replicat ion t riggers.

1 2 .7 .4 .3 Re plica t in g t r igge r s t h e m se lve s You can use t he DBMS_REPCAT.CREATE_MASTER_REPOBJECT procedure if you wish, or you can sim ply build t he t riggers individually in each dat abase. I have found t he lat t e r m et hod t o be m ore efficient .

1 2 .7 .5 Usin g Offlin e I n st a n t ia t ion Suppose you want t o creat e replicat ed t ables at a new m ast er sit e. One way t o do so is t o quiesce t he replicat ion group, export t he t ables, im port t hem at t he new sit e, generat e replicat ion support for t hem at t he new sit e, and finally resum e norm al act ivit y for t he replicat ion group. Alt hough t his m et hodology ensures t hat t he new t ables will be in sync wit h t he original ones, t he durat ion of t he quiescence m ay be unaccept ably long. Offline inst ant iat ion is a t echnique you can use t o deploy replicat ed t ables at new sit es wit hout having t o quiesce t he t able's replicat ion group at t he m ast er sit e during t he ent ire dat a loading process. Table 12.5 describes how t o use DBMS_OFFLI NE_OG.

Table 12.5. Instantiating a Table at a New Site with DBMS_OFFLINE_OG Step

Where Performed

Activity

1

Mast er definit ion sit e

DBMS_REPCAT.ADD_MASTER_DATABASE

2

Mast er definit ion sit e

DBMS_REPCAT.SUSPEND_MASTER_ACTI VI TY

3

Mast er definit ion sit e

DBMS_OFFLI NE_OG.BEGI N_I NSTANTI ATI ON

294

Oracle Distributed Systems

4

Any exist ing m ast er sit e Export replicat ed schem a

5

Mast er definit ion sit e

DBMS_OFFLI NE_OG.RESUME_SUBSET_OF_MASTERS

6

New sit e

DBMS_OFFLI NE_OG.BEGI N_LOAD

7

New sit e

I m port dat a from St ep 4

8

New Sit e

DBMS_OFFLI NE_OG.END_LOAD

9

Mast er definit ion sit e

DBMS_OFFLI NE_OG.END_I NSTANTI ATI ON

The following scenario shows how you would inst ant iat e a new sit e. Here, t he sit e PFI N.BI GWHEEL.COM is added t o t he replicat ion group RG_SPROCKET using DBMS_OFFLI NE_OG. Assum e t hat t he m ast er definit ion sit e is PHQS.BI GWHEEL.COM. 1. From m ast er definit ion sit e PHQS.BI GWHEEL.COM, add t he new m ast er sit e, quiesce t he replicat ion group, and call DBMS_OFFLI NE_OG.BEGI N_I NSTANTI ATI ON: 2. EXECUTE DBMS_REPCAT.ADD_MASTER_DATABASE( 3. gname => 'RG_SPROCKET', 4. master => 'PFIN.BIGWHEEL.COM'); 5. 6. EXECUTE DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY(gname => 'RG_SPROCKET'); 7. 8. EXECUTE DBMS_OFFLINE_OG.BEGIN_INSTANTIATION( 9. gname => 'RG_SPROCKET', new_site => 'PFIN.BIGWHEEL.COM'); 10. Perform export of schem a SPROCKET from any exist ing m ast er sit e. 11. Call RESUME_SUBSET_OF_MASTERS at t he m ast er definit ion sit e. 12. Call BEGI N_LOAD from t he new m ast er sit e PFI N.BI GWHEEL.COM: 13. EXECUTE DBMS_OFFLINE_OG.BEGIN_LOAD( 14. gname => 'RG_SPROCKET', new_site => 'PFIN.BIGWHEEL.COM'); 15. I m port t he RG_SPROCKET schem a int o PFI N.BI GWHEEL.COM using t he export file creat ed in St ep 2. 16. Call END_LOAD from t he new m ast er sit e, PFI N.BI GWHEEL.COM: 17. EXECUTE DBMS_OFFLINE_OG.END_LOAD( 18. gname => 'RG_SPROCKET', new_site => 'PFIN.BIGWHEEL.COM'); 19. Call END_I NSTANTI ATI ON from t he m ast er definit ion sit e: 20. EXECUTE DBMS_OFFLINE_OG.END_INSTANTIATION( 21. gname => 'RG_SPROCKET', new_site => 'PFIN.BIGWHEEL.COM');

1 2 .7 .5 .1 Offlin e in st a n t ia t ion ca ve a t s Offline inst ant iat ion has one not iceable drawback, which is t hat Oracle queues all t ransact ions dest ined for new_sit e. Therefore, if you use t his t echnique t o add a t able t o a m ast er sit e t hat is already part icipat ing in t he replicat ion of ot her t ables, t ransact ions against t hose ot her t ables will not be delivered unt il t he call t o

295

Oracle Distributed Systems DBMS_OFFLI NE_OG.END_I NSTANTI ATI ON. I n ot her words, t he DBMS_OFFLI NE.BEGI N_I NSTANTI ATI ON call disables all pushes t o new_sit e. This behavior is generally not an issue if you are adding a brand new m ast er sit e, but if you're t rying t o roll out a new t able t o an exist ing sit e, you should be prepared t o queue t ransact ions t o t hat new sit e for as long as it t akes t o perform your export and im port .

As of t his writ ing, DBMS_OFFLI NE_OG does not support connect ion qualifiers ( bugs 659595 and 729672) ; see Bug Updat e, earlier in t his chapt er.

1 2 .7 .5 .2 An a lt e r n a t ive t o D BM S_ OFFLI N E_ OG I f you need t o add a replicat ed t able t o an exist ing m ast er dat abase wit h a m inim al am ount of t ransact ion queueing t o t he m ast er, you m ight consider t his procedure. The basic idea is t o creat e a t em porary replicat ion group t hat uses a connect ion qualifier t o ident ify t he m ast er. For purposes of illust rat ion, assum e t hat we wish t o add t he t able SPROCKET.PRODUCTS t o t he exist ing m ast er sit e PFI N.BI GWHEEL.COM. 1. Creat e a new dat abase link t o PFI N.BI GWHEEL.COM using connect ion qualifiers: 2. CREATE PUBLIC DATABASE LINK PFIN.BIGWHEEL.COM@TCP USING 'prodfinance' Not e t hat in addit ion t o t he public dat abase link, you also need t o creat e privat e links for your REPADMI N and PROGAGATOR account s. 3. Creat e a t em porary replicat ion group RG_SPROCKET_TEMP: 4. EXECUTE DBMS_REPCAT.CREATE_MASTER_REPGROUP(5. gname => 'RG_SPROCKET_TEMP', qualifier => '@TCP'); 6. Add t he PFI N.BI GWHEEL.COM dat abase t o t he t em porary group: 7. EXECUTE DBMS_REPCAT.ADD_MASTER_DATABASE( 8. gname => 'RG_SPROCKET_TEMP', master => 'PFIN.BIGWHEEL.COM@TCP' 9. Add t able SPROCKET.PRODUCTS t o t he replicat ion group RG_SPROCKET_TEMP and generat e replicat ion support : 10. EXECUTE DBMS_REPCAT.CREATE_MASTER_REPOBJECT( 11. sname => 'SPROCKET', 12. oname => 'PRODUCTS', 13. type => 'TABLE', 14. copy_rows => FALSE, 15. gname => 'RG_SPROCKET_TEMP'); 16. 17. EXECUTE DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT( 18. sname => 'SPROCKET', 19. oname => 'PRODUCTS', type => 'TABLE');

296

Oracle Distributed Systems You should also add conflict resolut ion t o t he t able at t his t im e. 20. Export t able SPROCKET.PRODUCTS. 21. Resum e m ast er act ivit y for t he replicat ion group RG_SPROCKET_TEMP: 22. EXECUTE DBMS_REPCAT.RESUME_MASTER_ACTIVITY( gname => 'RG_SPROCKET_TEMP'); 23. I m port SPROCKET.PRODUCTS at t he new m ast er sit e wit hout firing any of t he replicat ion t riggers ( disable all t riggers on t he t able first ) . 24. When t he im port is finished, push t he queued t ransact ions t o PFI N.BI GWHEEL.COM@TCP: 25. VARIABLE rc NUMBER 26. BEGIN 27. rc := EXECUTE DBMS_DEFER_SYS.PUSH( 28. destination := 'PFIN.BIGWHEEL.COM@TCP'); 29. END; / 30. Quiesce t he t em porary group RG_SPROCKET_TEMP: 31. EXECUTE DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY(gname => 'RG_SPROCKET_TEMP'); At t his point , t he PRODUCTS t able should be in sync at all sit es. 32. Rem ove SPROCKET.PRODUCTS from t he t em porary replicat ion group: 33. EXECUTE DBMS_REPCAT.DROP_MASTER_REPOBJECT( 34. sname => 'SPROCKET' 35. oname => 'PRODUCTS', 36. type => 'TABLE', drop_objects => FALSE); 37. Quiesce t he replicat ion group RG_SPROCKET and add t he t able SPROCKET.PRODUCTS t o it : 38. EXECUTE DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY( 39. gname => 'RG_SPROCKET'); 40. 41. EXECUTE DBMS_REPCAT.CREATE_MASTER_REPOBJECT( 42. sname => 'SPROCKET', 43. oname => 'PRODUCTS', 44. type => 'TABLE', 45. gname => 'RG_SPROCKET'); 46. 47. EXECUTE DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT( 48. sname => 'SPROCKET', 49. oname => 'PRODUCTS', 50. type => 'TABLE', distributed => TRUE); 51. Resum e m ast er act ivit y, wit h t he SPROCKET.PRODUCTS t able in replicat ion group RG_SPROCKET, inst ant iat ed at t he sit e PFI N.BI GWHEEL.COM: EXECUTE DBMS_REPCAT.RESUME_MASTER_ACTIVITY('RG_SPROCKET');

297

Oracle Distributed Systems

1 2 .7 .6 Addin g a n d Re m ovin g Ta ble s Use t he built - in package procedures DBMS_REPCAT.CREATE_MASTER_REPOBJECT and DBMS_REPCAT.REMOVE_MASTER_REPOBJECT t o add and rem ove t ables ( and any ot her replicat ed obj ect s) from a replicat ion group. The specificat ions for t hese packages are as follows: PROCEDURE create_master_repobject( sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, use_existing_object IN BOOLEAN := TRUE, ddl_text IN VARCHAR2 := NULL, comment IN VARCHAR2 := '', retry IN BOOLEAN := FALSE, copy_rows IN BOOLEAN := TRUE, gname IN VARCHAR2 := ''); PROCEDURE drop_master_repobject( sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, drop_objects IN BOOLEAN := FALSE); Not e t hat CREATE_MASTER_REPOBJECT requires t he quiescence of t he replicat ion group t o which t he t able belongs, while DROP_MASTER_REPOBJECT does not . Bot h procedures m ust be called from t he m ast er definit ion sit e.

1 2 .7 .6 .1 Addin g r e plica t e d t a ble s. The following exam ples illust rat e various st rat egies for adding a t able t o a replicat ion group. This call adds t able SPROCKET.PRODUCTS t o t he replicat ion group SPROCKET: EXECUTE sname oname type gname

DBMS_REPCAT.CREATE_MASTER_REPOBJECT( => 'SPROCKET', => 'PRODUCTS', => 'TABLE', => 'RG_SPROCKET');

Since we have not specified t he ddl_t ext param et er in t his exam ple, t he t able m ust already exist . I n t he next exam ple, CREATE_MASTER_REPOBJECT is used t o creat e an obj ect at t he m ast er definit ion sit e and sim ult aneously add it t o t he replicat ion group: EXECUTE DBMS_REPCAT.CREATE_MASTER_REPOBJECT( sname => 'SPROCKET', oname => 'STATES', type => 'TABLE' ddl_text => 'CREATE TABLE sprocket.states (state_id VARCHAR2(2),

298

Oracle Distributed Systems state_name VARCHAR2(20))', gname => 'RG_SPROCKET'); Not ice t hat t he CREATE TABLE st at em ent in t his exam ple specifies t he owner of t he t able. Typically, t he replicat ion adm inist rat or account uses DBMS_REPCAT, not t he schem a owner account . Therefore, when t he REPADMI N account is calling t he procedure, you m ust be sure t o specify t he schem a in which t o creat e obj ect s. One of t he privileges grant ed t hrough DBMS_REPCAT_ADMI N.GRANT_ADMI N_ANY_REPGROUP is CREATE ANY TABLE. I n all likelihood, you will not creat e obj ect s wit h t heCREATE_MASTER_REPOBJECT procedure very oft en because doing so is rat her clum sy for all but t he m ost sim ple obj ect s. But , it 's t here if you want it . By set t ing t he ret ry and use_exist ing_obj ect param et ers t o TRUE in t he following exam ple, Oracle creat es t he t able PRODUCTS at all m ast er sit es where it does not already exist and, by set t ing copy_rows t o TRUE, copies t he dat a from t he m ast er definit ion sit e t o t he m ast er sit es: EXECUTE DBMS_REPCAT.CREATE_MASTER_REPOBJECT( sname => 'SPROCKET', oname => 'PRODUCTS', type => 'TABLE', use_existing_object => TRUE, retry => TRUE, copy_rows => TRUE, gname => 'SPROCKET'); I f t ables exist at m ast er sit es, but do not have t he sam e shape as at t he m ast er definit ion sit e, Oracle ret urns an error.

I st rongly recom m end pre- creat ing and populat ing t ables at m ast er sit es as opposed t o relying on t he CREATE_MASTER_REPOBJECT procedure t o do it for you, especially if t he obj ect s have int erdependencies. At our sit es, we always run a cat alog script t o creat e all schem a obj ect s, including t riggers, prim ary and foreign key definit ions, check const raint s, and so on. We t hen let Oracle generat e t he replicat ion support obj ect s. This m et hodology gives us com plet e cont rol over how t he schem a is creat ed, and all environm ent s are easily reproduced.

1 2 .7 .6 .2 Re m ovin g r e plica t e d t a ble s The DBMS_REPCAT.DROP_MASTER_REPOBJECT procedure rem oves a t able ( or ot her replicat ed obj ect ) from a replicat ion group and opt ionally drops t he t able it self if t he

299

Oracle Distributed Systems DROP_OBJECTS param et er is set t o TRUE. Execut ing t his package is very st raight forward, as t he following exam ple shows. I n t his exam ple, we rem ove t he t able SPROCKET.PRODUCTS from it s replicat ion group while leaving t he t able and it s dat a int act : EXECUTE DBMS_REPCAT.DROP_MASTER_REPOBJECT( sname => 'SPROCKET', oname => 'PRODUCTS', type => 'TABLE', drop_objects => FALSE); Not ice t hat t his procedure does not have a gnam e param et er for specifying t he replicat ion group; since an obj ect can be a m em ber of exact ly one replicat ion group, ident ifying t he t able nam e and owner is sufficient .

1 2 .7 .6 .3 D r oppin g r e plica t e d t a ble s: ca ve a t s Before dropping a replicat ed t able, you should m ake every effort t o delet e all deferred t ransact ions t hat affect t he t able. Oracle m akes no effort t o check for or t o delet e t hese t ransact ions. Alt hough deferred t ransact ions against nonexist ent replicat ed t ables will not break or corrupt t he replicat ed environm ent , t hey will incur t he overhead of being logged as errors. To clear t he deferred t ransact ions associat ed wit h a t able, you need t o delet e t hem from t he originat ing sit e. To find t hese t ransact ions, you can query t he DEFTRAN and DEFCALL dat a dict ionary views, as illust rat ed in t he following exam ple. The query in t his exam ple generat es t he calls t o DBMS_DEFER_SYS.DELETE_TRAN required t o delet e all t ransact ions against t he PRODUCTS t able t hat originat ed at t his sit e: SELECT 'EXECUTE DBMS_DEFER_SYS.DELETE_TRAN('||chr(39)|| deferred_tran_id||chr(39)||', NULL);'||chr(10)||'COMMIT;' delete_command FROM deftran t WHERE EXISTS ( SELECT deferred_tran_id FROM defcall c WHERE c.deferred_tran_id = t.deferred_tran_id AND c.packagename = 'PRODUCTS$RP') / DELETE_COMMAND -----------------------------------------------------------------------EXECUTE DBMS_DEFER_SYS.DELETE_TRAN('16.67.151601', NULL); COMMIT; EXECUTE DBMS_DEFER_SYS.DELETE_TRAN('19.0.145356', NULL); COMMIT; EXECUTE DBMS_DEFER_SYS.DELETE_TRAN('19.75.145358', NULL);

300

Oracle Distributed Systems COMMIT; EXECUTE DBMS_DEFER_SYS.DELETE_TRAN('21.14.146003', NULL); COMMIT; EXECUTE DBMS_DEFER_SYS.DELETE_TRAN('21.35.146000', NULL); COMMIT;

1 2 .7 .6 .4 Pa r t ia lly dr oppe d t a ble s ( Or a cle 8 on ly) Anot her caveat t o consider when dropping replicat ed t ables is t hat t he call t o DBMS_REPCAT.DROP_MASTER_REPOBJECT m ay fail t o drop all of t he replicat ion support t riggers and packages associat ed wit h t he t arget t able. This part ial drop sit uat ion is a dist inct possibilit y if t he t able is an act ive one. The sym pt om s of an incom plet e execut ion of DBMS_REPCAT.DROP_MASTER_REPOBJECT include ret urning a lock t im eout error and t he cont inued queuing of t ransact ions against t he t able even t hough it no longer appears in t he DBA_REPOBJECT dat a dict ionary view. This scenario is part icularly vexing since replicat ion support t riggers are int ernalized and t herefore invisible in Oracle8. To recover from t his, you m ust call t he undocum ent ed package procedures: DBMS_REPCAT_CACHE.PURGE_OBJECT_GROUP DBMS_REPCAT_UTL.DESTROY_I NTERNAL_TRI GGER DBMS_REPCAT_UTL.REMOVE_REPOBJECT The specificat ions for t hese procedures are as follows: PROCEDURE destroy_internal_trigger( canon_sname IN VARCHAR2, /*--- the owner of the table ---*/ canon_oname IN VARCHAR2, /*--- the table name ---*/ type_id IN NUMBER); /*--- use 2 ---*/ PROCEDURE remove_repobject( canon_sname IN VARCHAR2, canon_oname IN VARCHAR2, type_id IN NUMBER); PROCEDURE purge_object_group( cannon_gname IN VARCHAR2 );

/*--- the owner of the table ---*/ /*--- the table name ---*/ /*--- use 2 ---*/

/*--- the replication group name ---*/

To use t hese procedures, follow t hese st eps: 1. I n each m ast er dat abase, log in t o t he SYS account and execut e t he procedures DBMS_REPCAT_UTL.DESTROY_I NTERNAL_TRI GGER and DBMS_REPCAT_UTL.REMOVE_REPOBJECT. For exam ple: 2. EXECUTE dbms_repcat_utl.destroy_internal_trigger( 3. canon_sname => 'SPROCKET', 4. canon_oname => 'PRODUCTS', 5. type_id => 2); 6. 7. EXECUTE dbms_repcat_utl.remove_object( 8. canon_sname => 'SPROCKET', 9. canon_oname => 'PRODUCTS', -

301

Oracle Distributed Systems 10. type_id 11. COMMIT;

=> 2);

Not e t hat t hese calls m ay result in lock t im eout errors. Cont inue at t em pt ing t hem unt il t hey com plet e successfully. 12. I n each m ast er dat abase, log in t o t he SYS account and execut e DBMS_REPCAT_CACHE.PURGE_OBJECT_GROUP. For exam ple: 13. EXECUTE dbms_repcat_cache.purge_object_group( 14. canon_gname => 'RG_SPROCKET' 15. COMMIT;

You should cont act Oracle Support before at t em pt ing t hese procedures. Since t he procedures are undocum ent ed, t hey m ay change in fut ure releases of t he dat abase. The procedure shown here works for Oracle 8.0.4.

1 2 .8 Re plica t in g D D L The advanced replicat ion facilit ies include support for replicat ing DDL com m ands t o all m ast er dat abases in a replicat ion group. The DBMS_REPCAT procedures t hat provide t his support are DBMS_REPCAT.ALTER_MASTER_REPOBJECT and DBMS_REPCAT.EXECUTE_DDL; t heir specificat ions follow: PROCEDURE alter_master_repobject( sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, ddl_text IN VARCHAR2, comment IN VARCHAR2 := '', retry IN BOOLEAN := FALSE); PROCEDURE execute_DDL( gname IN VARCHAR2, master_list IN VARCHAR2 := NULL, ddl_text IN VARCHAR2); PROCEDURE execute_DDL( gname IN VARCHAR2, master_table IN dbms_utility.dblink_array, ddl_text IN VARCHAR2);

Not ice t hat ALTER_MASTER_REPOBJECT does not allow you t o specify m ast er sit es, whereas EXECUTE_DDL does. ALTER_MASTER_REPOBJECT operat es only on exist ing replicat ed obj ect s and t herefore execut es at all m ast er sit es, whereas EXECUTE_DDL allows you t o perform DDL operat ions

302

Oracle Distributed Systems

independent of replicat ed obj ect s. For exam ple, you can use EXECUTE_DDL t o creat e users at a rem ot e sit e.

1 2 .8 .1 Re st r ict ion s Not e t he following rest rict ions on DDL replicat ion: •

•

•

Bot h DBMS_REPCAT.ALTER_MASTER_REPOBJECT and DBMS_REPCAT.EXECUTE_DDL m ust be called from t he m ast er definit ion sit e. DBMS_REPCAT.ALTER_MASTER_REPOBJECT requires t he replicat ion group t o be quiesced. You m ust call regenerat e replicat ion support for t ables t hat you alt er wit h a call t o DBMS_REPCAT.ALTER_MASTER_REPOBJECT.

1 2 .8 .2 Ex a m ple s The following exam ples dem onst rat e how t o use t heDDL replicat ion procedures.

1 2 .8 .2 .1 Cr e a t in g a n in de x This exam ple uses t he DBMS_REPCAT.EXECUTE_DDL procedure t o creat e an index on t he SPROCKET.STATES t able at sit es PFI N.BI GWHEEL.COM and PMFG.BI GWHEEL.COM. Not e t hat , as wit h CREATE_MASTER_REPOBJECT, we m ust specify t he schem a in which t o creat e t he index. DECLARE vMasters VARCHAR2(30); BEGIN vMasters := 'PFIN.BIGWHEEL.COM,PMFG.BIGWHEEL.COM'; DBMS_REPCAT.EXECUTE_DDL( gname => 'SPROCKET', master_list => vMasters, ddl_text => 'CREATE INDEX sprocket.i_state_id ON sprocket.tstates(state_id)', sname =>'SPROCKET'); END;

1 2 .8 .2 .2 Com pilin g a r e plica t e d pa ck a ge body I n t his exam ple, we use t he DBMS_REPCAT.ALTER_MASTER_REPOBJECT procedure t o set t he ret ry param et er t o TRUE so t hat ALTER_MASTER_REPOBJECT applies t he DDL only at sit es at which t he package body's st at us is I NVALI D. DBMS_REPCAT.ALTER_MASTER_REPOBJECT( sname => 'SPROCKET', oname => 'PRODUCTMAINT', type => 'PACKAGE BODY', ddl_text => 'ALTER PACKAGE SPROCKET.PRODUCTMAINT COMPILE BODY', -

303

Oracle Distributed Systems comment retry

=> 'Recompiled on '||sysdate|| ' by '||user, => TRUE );

Not ice t hat t he schem a is specified for t he obj ect being alt ered. As wit h DBMS_REPCAT.EXECUTE_DDL, t he ALTER_MASTER_REPOBJECT procedure operat es on obj ect s in t he caller's schem a by default , and t he caller is generally t he replicat ion adm inist rat or account , not t he schem a account .

1 2 .8 .2 .3 Alt e r in g a colu m n in a r e plica t e d t a ble This exam ple uses t he DBMS_REPCAT.ALTER_MASTER_REPOBJECT procedure t o alt er t he widt h of t he st at e_id colum n in t able SPROCKET.STATES at all sit es: DBMS_REPCAT.ALTER_MASTER_REPOBJECT( sname => 'SPROCKET', oname => 'STATES', type => 'TABLE', ddl_text=> 'ALTER TABLE SPROCKET.STATES MODIFY (STATE_ID NUMBER(10))' , comment => 'state_id widened on '||sysdate|| ' by '||user);

You m ay find it convenient t o creat e a special replicat ion group, RG_DBA, t o which you can use DBMS_REPCAT.EXCECUTE_DDL t o " broadcast " adm inist rat ive t asks such as creat ing users or coalescing t ablespaces t o all m ast er dat abases.

1 2 .8 .3 M a n u a lly Ex e cu t in g En t r ie s in t h e r e pca t log The procedures DBMS_REPCAT.ALTER_MASTER_REPOBJECT and DBMS_REPCAT.EXECUTE_DDL bot h put ent ries in t he local repcat log. These ent ries cause t he com m ands t o be execut ed at rem ot e sit es. By default , Oracle execut es ent ries in t he repcat log every 10 m inut es. However, if you wish, you can execut e repcat log ent ries m anually by calling DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMI N. For exam ple, t he following call execut es repcat log ent ries associat ed wit h t he replicat ion group RG_SPROCKET: EXECUTE DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN( gname => 'RG_SPROCKET');

1 2 .8 .4 D e le t in g Er r or s fr om t h e r e pca t log Use t he procedure D BMS_REPCAT.PURGE_MASTER_LOG t o delet e errors from t he repcat log. The DBA_REPCATLOG dat a dict ionary view ret ains ent ries for DDL propagat ions t hat have failed, and t hese ent ries are not rem oved when you resolve t he problem t hat caused t he failure. You m ay not ice ent ries such as t hese: SELECT source, status, request, to_char(timestamp, 'HH24:MI:SS') timestamp FROM dba_repcatlog ORDER BY id

304

Oracle Distributed Systems / Source ----------------D7CA.BIGWHEEL.COM D7CA.BIGWHEEL.COM D7CA.BIGWHEEL.COM D7CA.BIGWHEEL.COM D7CA.BIGWHEEL.COM D7CA.BIGWHEEL.COM D7CA.BIGWHEEL.COM D7CA.BIGWHEEL.COM

Status -----ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR

Request ----------------------CREATE_MASTER_REPOBJECT CREATE_MASTER_REPOBJECT CREATE_MASTER_REPOBJECT CREATE_MASTER_REPOBJECT CREATE_MASTER_REPOBJECT CREATE_MASTER_REPOBJECT DROP_MASTER_REPOBJECT DROP_MASTER_REPOBJECT

Time -----------23:13:07 23:13:07 23:25:20 23:25:20 23:26:53 23:26:53 14:03:27 14:03:27

8 rows selected. The PURGE_MASTER_LOG procedure rem oves t hese ent ries from DBA_REPCATLOG. You can specify records t o delet e by I D, originat ing m ast er, replicat ion group, and schem a. I f any of t he param et ers is NULL, it is t reat ed as a wildcard. Specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.PURGE_MASTER_LOG( id IN NATURAL, source IN VARCHAR2, gname IN VARCHAR2 := '', sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.PURGE_MASTER_LOG( id IN NATURAL, source IN VARCHAR2, gname IN VARCHAR2); The following call rem oves all ent ries associat ed wit h replicat ion group SPROCKET from t he DBA_REPCATLOG dat a dict ionary view: DBMS_REPCAT.PURGE_MASTER_LOG (gname => 'SPROCKET' );

To clear all ent ries from t he DBA_REPCATLOG dat a dict ionary view, set all param et ers t o NULL.

1 2 .9 You r Re plica t e d En vir on m e n t Once you have a replicat ed syst em up and running, you need t o m onit or it t o ensure t hat you det ect problem s early. The m ost im port ant t hings t o m onit or are: • • •

The num ber of t ransact ions queued at each originat ing sit e The num ber of unresolved errors at each dest inat ion sit e The num ber of ent ries in each snapshot log

305

Oracle Distributed Systems I f any of t hese t hree count s becom es t oo high, it can be very t im e- consum ing t o recover. By t he sam e t oken, all are usually easy t o correct if you cat ch t hem early.

1 2 .9 .1 M on it or in g Qu e u e d Tr a n sa ct ion s The following SQL query ret urns t he num ber of deferred t ransact ions t hat are current ly queued: SELECT FROM WHERE AND

count(*) deftrandest d, deftran t d.deferred_tran_id = t.deferred_tran_id d.delivery_order = t.delivery_order;

This query has been incorporat ed int o a Unix shell script , checklat ency , shown here, which sends em ail t o t he DBA when t he num ber of deferred t ransact ions exceeds 150: #! /bin/ksh #------------------------------------------------------------------------# Filename: checklatency # Purpose: Notifies the dba when more than 150 replicated transactions # are queued. # Author: Chas. Dye ([email protected]) # Date: 21-Oct-1998 # Remarks: Requires OPS$ account for whichever OS user crons this script. #------------------------------------------------------------------------HOST=`/bin/uname -n` MAIL=/bin/mailx DISTLIST="[email protected]" export HOST MAIL DISTLIST # ORACLE_HOME=/u/oracle/product/8.0.4.2 ; export ORACLE_HOME ORACLE_SID=PHQS ; export ORACLE_SID PATH=$ORACLE_HOME/bin:/bin:{PATH} ; export PATH LD_LIBRARY_PATH=$ORACLE_HOME/lib:${LD_LIBRARY_PATH}; export LD_LIBRARY_PATH # cd ${HOME}/bin # sqlplus -s / 150; spool off EOF #

306

Oracle Distributed Systems grep 1 latent.log > latent.err if [ -s latent.err ] then $MAIL -s"${ORACLE_SID}@${HOST} latency alert" $DISTLIST < latent.log fi # rm -f latent.err rm -f latent.log You m ay also be int erest ed in t he age and count of t ransact ions t o specific dest inat ions. This script , lat ent .sql, provides precisely t hat inform at ion. This is possibly t he single m ost valuable script for checking t he healt h of a replicat ed environm ent : --------------------------------------------------------------------------- Filename: latent.sql -- Purpose: Lists outstanding transactions by destination. -- Author: Chas. Dye ([email protected]) -- Date: 09-Jul-1996 -------------------------------------------------------------------------col dblink a16 col earliest a20 col latest a20 col out 999,999 col timenow col latency a12

heading "Destination"

format

heading "Least Recently|Queued Transaction"

format

heading "Most Recently|Queued Transaction"

format

heading "Total|Txns|Queued"

format

heading "Current|Time" heading "Maximum|Latency|dd:hh:mi:ss"

format a8 format

clear breaks clear computes set head off set feedback off select 'Propagation Latency Instance: '||name||'. to_char(sysdate, 'DD-Mon-YY HH24:mi:ss') from v$database / set head on set feedback on

Time: ' ||

compute sum of out on report break on report skip 1 SELECT

d.dblink, min(t.start_time) earliest, max(t.start_time) latest, count(*) out,

307

Oracle Distributed Systems ltrim(to_char(trunc(sysdate-( min(start_time)) ), '09')) || ':' || ltrim(to_char(trunc(24*((sysdate-min(start_time)) trunc(sysdate-min(start_time)))), '09'))||':' || ltrim(to_char(mod(trunc(1440*((sysdate-min(start_time)) trunc(sysdate-min(start_time)))), 60), '09')) ||':' || ltrim(to_char(mod(trunc(86400*((sysdate-min(start_time)) trunc(sysdate-min(start_time)))), 60), '09')) latency FROM deftrandest d, deftran t WHERE d.deferred_tran_id = t.deferred_tran_id AND d.delivery_order = t.delivery_order GROUP BY d.dblink / Sam ple out put follows: Propagation Latency Instance: PMFG.

Time: 22-Nov-98 10:06:09 Total

Maximum Latency Destination dd:hh:mi:ss -------------------PMFG.EXCITE.COM 00:00:00:04 PSLS.EXCITE.COM 00:00:01:33

Least Recently

Most Recently

Txns

Queued Transaction

Queued Transaction

Qud

--------------------

-------------------

---- -----

22-Nov-1998 10:06:05 22-Nov-1998 10:06:09

20

22-Nov-1998 10:04:52 22-Nov-1998 10:06:22

72 ---92

sum 1 row selected.

1 2 .9 .2 M on it or in g D e fe r r e d Tr a n sa ct ion Er r or s I f you allow errors t o accum ulat e at dest inat ion sit es, it can be very difficult t o clear t hem . I n an ideal world, your conflict resolut ion t echniques will det ect and resolve errors. However, experience has shown t hat it is best t o expect t he unexpect ed. The ut ilit ies in t his sect ion will help you t o keep t abs on deferred t ransact ion errors so t hat you can respond in a t im ely fashion. The first script , deferror.sql ( deferror8.sql for Oracle8) list s unresolved errors and generat es t he calls t o DBMS_DEFER_SYS.DELETE_ERROR t o delet e t he errors and DBMS_DEFER_SYS.EXECUTE_ERROR t o ret ry t he t ransact ion.

Due t o differences in t he Oracle7 and Oracle8 dat a dict ionaries, t he script s deferror.sql ( for Oracle7) and deferror8.sql ( for Oracle8) are slight ly different . We show only t he Oracle8 version of t he script here .

308

Oracle Distributed Systems --------------------------------------------------------------------------- Filename: deferror8.sql -- Purpose: Reports on deferred transactions with errors and generates -call to dbms_defer_sys.execute_error to clear them. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 --- Modification History -- --------------------- 13-Aug-1998 : Chas. : Updated for Oracle8; added commands to delete error. -- 09-Oct-1998 : Chas. : Added ORDER BY start_time -------------------------------------------------------------------------column column column column column column column

ORIGIN_TRAN_DB DEFERRED_TRAN_ID DESTINATION ERROR_TIME ERROR_NUMBER FIX DITCH

heading heading heading heading heading heading heading

"Origin|Tran|DB" "Deferred|Tran|ID" "Destination" "Error Time" "Error#" "Run This to Clear" "Run This to Delete"

format format format format format format format

a15 a15 a15 a22 999999 a80 a80

SELECT

deferred_tran_id, origin_tran_db, destination, to_char(start_time, 'DD-Mon-YYYY hh24:mi:ss') error_time, error_number FROM deferror ORDER BY start_time / SELECT

'EXECUTE dbms_defer_sys.execute_error(' || chr(39) || deferred_tran_id || chr(39) || ', '|| chr(39) || destination || chr(39) || ' )' fix FROM deferror ORDER BY start_time / SELECT

'EXECUTE dbms_defer_sys.delete_error(' || chr(39) || deferred_tran_id || chr(39) || ', '|| chr(39) || destination || chr(39) || ' )' ditch FROM deferror ORDER BY start_time / Sam ple out put follows: Deferred Tran ID Error#

Origin Tran DB

Destination

Error Time

309

Oracle Distributed Systems -----------6.19.63683

--------------- --------------- ---------------------- ---LIVE.WORLD

PLV2.EXCITE.COM 06-Nov-1998 15:33:50

1403

1 row selected.

Run This to Clear -------------------------------------------------------------------------EXECUTE dbms_defer_sys.execute_error('6.19.63683', 'PLV2.EXCITE.COM' ) 1 row selected.

Run This to Delete -------------------------------------------------------------------------EXECUTE dbms_defer_sys.delete_error('6.19.63683', 'PLV2.EXCITE.COM' ) 1 row selected. Before you delet e or reexecut e a t ransact ion t hat has result ed in an error, you will probably want t o know what operat ion t he t ransact ion was at t em pt ing against what t able. However, t hat inform at ion is not available in t he DEFERROR dat a dict ionary view. The script errorinfo.sql culls t he relevant inform at ion from DEFERROR and DEFCALL. --------------------------------------------------------------------------- Filename: errorinfo.sql -- Purpose: Reports on all errors. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 --- Modification History -- -------------------- 03-Jun-1998 : Chas. : Removed deferred_tran_db field (not in Oracle8) -- 09-Oct-1998 : Chas. : Added ORDER BY e.start_time -------------------------------------------------------------------------col col col col col col col

callno deferred_tran_id schemaname packagename procname argcount origin_tran_db

SELECT

heading heading heading heading heading heading heading

"Call|No" "Deferred|Tran|ID" "Schema|Name" "Package|Name" "Procedure|Name" "Arg|Count" "Origin"

format format format format format format format

9999 a12 a8 a25 a10 999 a17

c.callno, c.deferred_tran_id, c.packagename, c.procname, c.argcount, e.origin_tran_db

310

Oracle Distributed Systems FROM defcall c, deferror e WHERE c.deferred_tran_id = e.deferred_tran_id AND c.callno = e.callno ORDER BY e.start_time / Sam ple out put follows: Deferred Call Tran No ID ----- -------------0 4.38.5528 PTHA.EXCITE.COM 0 7.97.5526 PTHA.EXCITE.COM 12 6.68.7736 PTHA.EXCITE.COM

Package Procedure Arg Name Name Count Origin -------------------- ---------- ----- -------------COMM$RP

REP_INSERT

14

COMMPROPSWELCOME$RP

REP_UPDATE

33

CONTACT$RP

REP_DELETE

22

Finally, if you want t o find out exact ly what param et ers have been used in a given call, you can use t he script defcallinfo.sql t o find out : --------------------------------------------------------------------------- Filename: defcallinfo.sql -- Purpose: Lists information about deferred calls. -- Author: Chas. Dye ([email protected]) -- Date: 10-Jul-1998 -------------------------------------------------------------------------set serveroutput on size 100000 set verify off undef callno undef argcnt undef tran_db undef tran_id DECLARE vTypes vVals indx

dbms_defer_query.type_ary; dbms_defer_query.val_ary; NUMBER;

BEGIN dbms_defer_query.get_call_args( callno => '&&callno', startarg => 1, argcnt => &&argcnt, argsize => 128, tran_db => '&&tran_db', tran_id => '&&tran_id', date_fmt => 'DD-Mon-YYYY HH24:MI:SS', types => vTypes, vals => vVals ); FOR indx IN 1..&&argcnt LOOP

311

Oracle Distributed Systems dbms_output.put_line('Arg '|| indx || ' Value '|| vVals(indx)); END LOOP; END; / Sam ple out put follows: SQL> @defcallinfo Enter value for callno: 0 Enter value for argcnt: 14 Enter value for tran_db: PTHA.EXCITE.COM Enter value for tran_id: 4.38.5528 Arg 1 Value 42397 Arg 2 Value 16-Oct-1998 13:00:06 Arg 3 Value 79EA878A35EB4002 Arg 4 Value Cadillac Voodoo Choir Arg 5 Value 0 Arg 6 Value 16-Oct-1998 13:00:06 Arg 7 Value PTHA.EXCITE.COM Arg 8 Value NULL Arg 9 Value NULL Arg 10 Value NULL Arg 11 Value NULL Arg 12 Value 0 Arg 13 Value PTHA.EXCITE.COM Arg 14 Value N The argum ent s here refer t o t he old and new colum n values t hat Oracle sends t o t he dest inat ion sit e when it propagat es t he t ransact ion.

Au t om a t ic N ot ifica t ion M e ch a n ism I have developed a t ool t o send em ail t o appropriat e people and pagers when it det ect s errors in t he DEFERROR view. The t ool uses a PL/ SQL package t hat checks t he view at dest inat ion dat abases and t he DBMS_PI PE ut ilit y t o send t he em ail request . Please refer t o Appendix B for t he inst allat ion inst ruct ions .

1 2 .9 .3 M on it or in g Sn a psh ot Logs I f you have creat ed snapshot logs on m ast er t ables, you should check t he size of t he snapshot logs periodically t o ensure t hat t hey are not growing t oo large. I f you not ice t hat a snapshot log has m any ent ries ( i.e., t housands) , it m ay be because eit her not all snapshot s t hat are m ast ered t o t he m ast er t able are firing or because t heir refresh int erval is t oo long. The script m logs.sql generat es t he SQL st at em ent s t o select t he record count for all snapshot logs in t he dat abase:

312

Oracle Distributed Systems --------------------------------------------------------------------------- Filename: mlogs.sql -- Purpose: Generates SELECT statements to find the count of entries in -all snapshot logs. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------SELECT 'SELECT count(*) FROM '||lower(owner)||'.'||lower(table_name)||';' FROM dba_tables WHERE table_name like 'MLOG$_%' AND owner not like 'SYS%' ORDER BY owner, table_name /

1 2 .9 .4 M on it or in g: Su m m a r y I have found t he script s described in t he preceding sect ion t o be invaluable in helping t o m aint ain a replicat ed environm ent . I f you are responsible for m ore t han t wo or t hree replicat ed applicat ions, I st rongly encourage you t o aut om at e as m uch of t he m onit oring as possible. As m ent ioned, m ost problem s are easy t o resolve if you spot t hem early but becom e exponent ially m ore difficult t o correct if t hey are allowed t o persist unchecked.

1 2 .1 0 Adva n ce d Re plica t ion Lim it a t ion s Finally, not e t hat t here are som e rest rict ions on what you can and cannot do in a replicat ed environm ent : •

• •

•

There is no support for cascading delet es. As an alt ernat ive, you m ay consider writ ing a t rigger on t he m ast er t able t o delet e child records. Sequences do not replicat e. I f you use sequences t o populat e key fields, be sure t o designat e a range of sequence values in each m ast er dat abase t hat is large enough t o avoid key collisions for t he life of t he applicat ion. There is no support for local cust om izat ion of replicat ed t ables. I n ot her words, replicat ed t ables m ust have an ident ical shape in each m ast er dat abase. The dat at ypes LONG, LONG RAW, and HHCODE do not replicat e. You m ay replicat e t ables cont aining colum ns of t hese dat at ypes, but DML t o t hese colum ns will not propagat e t o ot her m ast er sit es. I recom m end using t he CLOB and LOB dat at ypes available in Oracle8.

313

Oracle Distributed Systems

Ch a pt e r 1 3 . Upda t e a ble Sn a psh ot s Updat eable snapshot s offer a m eans of deploying updat eable copies of dat a at m ult iple sit es. Unlike m ult i- m ast er replicat ion, which m aint ains copies of all records in a t able at m ult iple sit es, updat eable snapshot s m ay be part it ioned horizont ally. Anot her key difference bet ween updat eable snapshot s and m ult i- m ast er t able replicat ion is t hat updat eable snapshot sit es need not be in const ant com m unicat ion wit h t he m ast er sit e. Com m on usages of updat eable snapshot s include sales lead dat a on a salesperson's lapt op com put er or grocery regist er receipt dat a. I n bot h cases, t he m ast er dat a would reside at a headquart ers sit e, and t he updat eable snapshot m ight push dat a back t o t he headquart ers sit e at t he end of t he business day.

1 3 .1 Abou t Upda t e a ble Sn a psh ot s As described in Chapt er 11, updat eable snapshot s funct ion by placing t riggers on t he m ast er and snapshot t ables. Thet rigger on t he m ast er t able ( TLOG$_t able_nam e) populat es t he snapshot log t able ( MLOG$_t able_nam e) at t he m ast er sit e. Sim ilarly, t he t rigger on t he snapshot base t able ( USTRG$_m ast er_t able_nam e ) populat es t he snapshot log t able ( USLOG$_t able_nam e) at t he snapshot sit e. Like t heir read- only count erpart s, updat eable snapshot s m ust be refreshed in order t o reflect changes t hat have occurred t o t he m ast er t able. I n addit ion, updat eable snapshot s m ust propagat e changes from t he snapshot sit e back t o t he m ast er t able. This propagat ion can happen eit her at t he sam e t im e as t he snapshot refresh or at a different scheduled int erval. My recom m endat ion is t o propagat e changes from t he snapshot sit e t o t he m ast er sit e during t he sam e " conversat ion" as t he snapshot refresh. This recom m endat ion is part icularly relevant if t he snapshot sit e is not in const ant cont act wit h t he m ast er sit e.

1 3 .1 .1 Re st r ict ion s As wit h read- only snapshot s, Oracle im poses cert ain rest rict ions on updat eable snapshot s: • • •

•

Updat eable snapshot s m ust be sim ple snapshot s. That is, t hey m ust be snapshot s against a single t able wit hout DI STI NCT, GROUP BY, or CONNECT BY operat ors or any subqueries. Colum ns of t ype LONG and LONG RAW cannot be used. Updat eable snapshot s m ust include all colum ns of t he m ast er t able. Therefore, vert ical part it ioning is not possible. I n Oracle7, updat eable snapshot s m ust have t he sam e nam e as t he m ast er t able.

1 3 .2 Cr e a t in g Upda t e a ble Sn a psh ot s Updat eable snapshot s require com ponent s at bot h t he m ast er sit e and t he snapshot sit e. To illust rat e t he procedure, I 'll t race t he st eps required t o creat e an updat eable snapshot on t he t able SPROCKET.DAI LY_SALES defined as follows:

314

Oracle Distributed Systems SQL> desc daily_sales Name Null? ---------------- -------SALES_ID NOT NULL DISTRIBUTOR_ID NOT NULL PRODUCT_ID NOT NULL UNITS NOT NULL REGION NOT NULL AUDIT_DATE NOT NULL AUDIT_USER NOT NULL GLOBAL_NAME NOT NULL

Type ---NUMBER(9) NUMBER(6) NUMBER(9) NUMBER(9,2) VARCHAR2(3) DATE VARCHAR2(30) VARCHAR2(20)

Each ret ail out let of t he fict it ious Bigwheel Bicycle com pany updat es a local snapshot of t his t able wit h each cust om er purchase. The out let st ores send t heir dat a back t o t he headquart ers dat abase each evening. For t he purposes of our exam ple, suppose t hat t he headquart ers dat abase is nam ed PHQS.BI GWHEEL.COM and t hat t he ret ail st ore's dat abase is nam ed PSFO.BI GWHEEL.COM.

1 3 .2 .1 Pr e lim in a r y St e ps Before creat ingupdat eable snapshot s, t he m ast er and snapshot dat abases m ust be configured for replicat ion as described in Chapt er 12. I n addit ion t o running t he cat proc.sql and cat rep.sql script s at bot h sit es, you m ust ensure t he following: • •

•

•

•

Replicat ion adm inist rat or account s exist wit h proper privileges at t he m ast er and all snapshot sit es. ( Typically, t he replicat ion adm inist rat or account is REPADMI N.) Dat abase links m ust be in place. The links from t he snapshot sit e t o t he m ast er sit e m ust connect t o an account t hat eit her is t he owner of t he m ast er t able or has replicat ion adm inist rat or privileges. I n addit ion, t he account at t he m ast er sit e m ust have EXECUTE privileges on t he package SYS.DBMSOBJGWRAPPER. The t able t o be replicat ed exist s at t he m ast er sit e and has a prim ary key defined. The account t hat creat es t he updat eable snapshot m ust have t he privileges CREATE SNAPSHOT, CREATE TABLE, CREATE TRI GGER, and CREATE VI EW. I f t he snapshot is t o be creat ed in a different schem a ( i.e., owned by a different Oracle account from t he one issuing t he CREATE SNAPSHOT st at em ent ) , t hen t he account m ust have t he CREATE ANY SNAPSHOT privilege.

1 3 .2 .2 Pr e pa r in g t h e M a st e r Ta ble An im port ant difference bet ween read- only snapshot s andupdat eable snapshot s is t hat t he m ast er t able for t he lat t er m ust be defined as a replicat ed obj ect . The m ast er t able also m ust have a snapshot log. Follow t hese st eps: 1. Make t he t able a replicat ed obj ect ; run t he following from t he replicat ion adm inist rat or account : 2. EXECUTE dbms_repcat.create_master_repgroup( 3. gname=>'RG_SPROCKET', 4. group_comment=>'Created by '||user||' on '||sysdate);

315

Oracle Distributed Systems 5. 6. EXECUTE dbms_repcat.create_master_repobject( 7. sname => 'SPROCKET', 8. oname => 'DAILY_SALES', 9. type => 'TABLE', 10. use_existing_object => TRUE, 11. comment => 'Added by '||lower(user)||' on '||sysdate, 12. copy_rows => FALSE, 13. gname => 'RG_SPROCKET'); 14. 15. EXECUTE dbms_repcat.generate_replication_support( 16. sname => 'SPROCKET', 17. oname => 'DAILY_SALES', 18. type => 'TABLE', 19. distributed => TRUE); 20. EXECUTE dbms_repcat.resume_master_activity('RG_SPROCKET'); 21. Creat e a snapshot log on t he m ast er t able; run t he following from t he account t hat owns t he m ast er t able: 22. CREATE SNAPSHOT LOG ON daily_sales 23. PCTFREE 5 PCTUSED 90 24. TABLESPACE sprocket_data STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0) WITH PRIMARY KEY Oracle8 only /

Prior t o Oracle8, Oracle recorded a row's ROWI D in t he snapshot log t o ident ify it as having been changed. Since ROWI Ds can change if a t able is m oved, or export ed and im port ed, t his m eant t hat t ables wit h snapshot logs could not be rebuilt wit hout rebuilding t he snapshot log and t herefore requiring a com plet e refresh of all snapshot s. Oracle8, on t he ot her hand, allows you t o ident ify changed records in t he snapshot log by t heir prim ary key, affording you t he flexibilit y of rebuilding a m ast er t able wit hout being forced t o perform a com plet e refresh of all of it s snapshot s.

1 3 .2 .3 Pr e pa r in g t h e Sn a psh ot Sit e At t hesnapshot sit e, we m ust first creat e t he act ual snapshot , eit her wit h t he CREATE SNAPSHOT st at em ent or by supplying t he DDL in t he call t o DBMS_REPCAT.CREATE_SNAPSHOT_REPOBJECT. Also, not e t hat in t he CREATE SNAPSHOT st at em ent , we do not specify a NEXT t im e for t he refreshes. We om it t his com ponent because we will put t he updat eable snapshot int o a refresh group which cont rols t he refresh schedule. By default , Oracle

316

Oracle Distributed Systems creat es a refresh group wit h t he sam e nam e as t he snapshot it self when you issue a CREATE SNAPSHOT st at em ent . Finally, not ice t hat t he defining query of t he CREATE SNAPSHOT st at em ent uses " SELECT * " inst ead of specifying field nam es. Updat eable snapshot s m ust cont ain every field in t he t able, and t he SELECT * synt ax is t he only m et hod Oracle support s. Follow t hese st eps: 1. Creat e t he snapshot using t he FOR UPDATE clause in t he CREATE SNAPSHOT st at em ent . Creat e t he snapshot when logged in t o t he schem a owner account , preferably wit h t he sam e account nam e as t he owner of t he m ast er t able. Oracle8 synt ax: CREATE SNAPSHOT daily_sales TABLESPACE sprocket_data STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0) USING INDEX TABLESPACE sprocket_indx STORAGE (INITIAL 128K NEXT 128K PCTINCREASE 0) REFRESH FAST START WITH sysdate WITH PRIMARY KEY FOR UPDATE AS SELECT * FROM [email protected] WHERE region = 'SFO'; Oracle7 synt ax: CREATE SNAPSHOT daily_sales TABLESPACE sprocket_data STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0) REFRESH FAST START WITH sysdate FOR UPDATE AS SELECT * FROM [email protected]; 2. Creat e a snapshot replicat ion group. Run t hese com m ands under t he replicat ion adm inist rat or account : 3. EXECUTE dbms_repcat.create_snapshot_repgroup( 4. gname => 'RG_SPROCKET', 5. master => 'PHQS.BIGWHEEL.COM', 6. comment => 'Created on '||sysdate||' by '||user, propagation_mode=> 'ASYNCHRONOUS'); The nam e of t he snapshot replicat ion group m ust be t he sam e as t he nam e of t he m ast er replicat ion group t o which t he m ast er t able belongs.

317

Oracle Distributed Systems 7. Add t he snapshot t o t he snapshot group from t he replicat ion adm inist rat or account : 8. EXECUTE dbms_repcat.create_snapshot_repobject( 9. sname => 'SPROCKET', 10. oname => 'DAILY_SALES', 11. type => 'SNAPSHOT', 12. comment => 'Created on '||sysdate||' by '||user, gen_objs_owner => 'REPADMIN'); 13. Creat e a snapshot refresh group, and add t he snapshot t o t he group ( opt ional, but recom m ended) : 14. EXECUTE dbms_refresh.make( 15. name => 'RG_SPROCKET', 16. list =>'SPROCKET.DAILY_SALES', 17. next_date => SYSDATE, 18. interval => 'TRUNC(SYSDATE+1)+23/24', 19. push_deferred_rpc => TRUE, purge_option => 1, Oracle8 only parallelism => 4, Oracle8 only lax => TRUE); EXECUTE dbms_refresh.add( name => 'RG_SPROCKET', list => 'SPROCKET.DAILY_SALES', lax => TRUE ); At t his point , we have creat ed an updat eable snapshot on SPROCKET.DAI LY_SALES, which refreshes once a day at 11: 00 P.M.

1 3 .2 .4 Use r - D e fin e d Tr igge r s on Upda t e a ble Sn a psh ot s You m ayhave not iced t he fields audit _dat e, audit _user, and global_nam e in t he t able SPROCKET.DAI LY_SALES. These fields are int ended t o t rack t he t im e t hat records are insert ed or delet ed, who perform ed t he operat ion, and in which dat abase. You can use t riggers t o populat e t hese fields, but you m ust m ake sure t hat t hey fire for local DML only; t hey m ust not fire because of t he DML associat ed wit h a snapshot refresh. Use t he Oracle built - in package funct ion DBMS_SNAPSHOT.I _AM_A_REFRESH t o det erm ine whet her t he t rigger should fire. The following code creat es t he audit t rigger on t he SPROCKET.DAI LY_SALES updat eable snapshot : CREATE OR REPLACE TRIGGER t_iu_snap$_daily_sales BEFORE INSERT OR UPDATE ON snap$_daily_sales FOR EACH ROW BEGIN IF (dbms_snapshot.i_am_a_refresh != TRUE) THEN :new.audit_date := SYSDATE;

318

Oracle Distributed Systems :new.audit_user :new.global_name END IF; END; /

:= USER; := DBMS_REPUTIL.GLOBAL_NAME;

Not ice t hat t he t rigger is defined on t he snapshot base t able SNAP$_DAI LY_SALES.

1 3 .3 Com m u n ica t ion Flow Yourreplicat ed environm ent is probably not as sim ple as a m ast er sit e and a snapshot sit e. Oracle allows you t o m ix and m at ch endless perm ut at ions of m ast ers and snapshot s. A sit e can even be a snapshot sit e for one set of t ables and a m ast er sit e for anot her. Som ehow, all of t he dat a get s t o it s dest inat ion. The m ost com plex configurat ion for updat eable snapshot s is one in which t wo or m ore m ult i- m ast er sit es have t heir own snapshot sit es, as shown in Figure 13.1.

Figu r e 1 3 .1 . Upda t e a ble sn a psh ot s w h e r e m u lt i- m a st e r s h a ve t h e ir ow n sn a psh ot sit e s

Suppose t hat a user at t he snapshot sit e PSLS.BI GWHEEL.COM m akes an updat e t o t he SALES_LEADS t able. How does t hat change propagat e t o t he updat eable snapshot of t he sam e nam e at sit e PSFO.BI GWHEEL.COM? The process is as follows:

319

Oracle Distributed Systems 1. The user updat es t he snapshot SALES_LEADS. 2. The t rigger USTRG$_SALES_LEADS creat es an ent ry in t he snapshot log USLOG$_SALES_LEADS. ( I n Oracle8, t his t rigger is int ernalized and t herefore not visible in t he dat a dict ionary.) 3. The snapshot refresh updat es m ast er t able in PHQS.BI GWHEEL.COM. 4. The replicat ion t rigger SALES_LEADS$RT in PHQS.BI GWHEEL.COM queues t he updat e for propagat ion t o it s com panion m ast er, PCAL.BI GWHEEL.COM. ( I n Oracle8, t his t rigger is int ernalized and t herefore not visible in t he dat a dict ionary.) 5. When t he updat e is applied at PCAL.BI GWHEEL.COM, t he t rigger TLOG$_SALES_LEADS creat es an ent ry in t he snapshot log MLOG$_SALES_LEADS. ( I n Oracle8, t his t rigger is int ernalized and t herefore not visible in t he dat a dict ionary.) 6. The refresh from PSFO.BI GWHEEL.COM t o PCAL.BI GWHEEL.COM reads t he snapshot log and applies t he change. Figure 13.2 depict s t his chain of event s.

Figu r e 1 3 .2 . Pr opa ga t in g a sn a psh ot t o a n ot h e r sit e

320

Oracle Distributed Systems

1 3 .4 Con t r ollin g Pr opa ga t ion a n d Re fr e sh e s As wit h m ult i- m ast er t able replicat ion,updat eable snapshot s can propagat e t heir changes back t o t he m ast er t able eit her synchronously or asynchronously. Unlike m ult i- m ast er t able replicat ion, you can cont rol asynchronous propagat ion so t hat DML is sent back t o t he m ast er t able eit her at t he t im e of snapshot refreshes or at som e ot her scheduled int erval. You should evaluat e your dat a flow requirem ent s t o det erm ine what best suit s your needs. This sect ion present s recom m endat ions for som e com m on scenarios.

Alt hough updat eable snapshot s can propagat e changes back t o t he m ast er t able synchronously, snapshot refreshes ( propagat ion of changes from t he m ast er t able t o t he snapshot ) are always asynchronous; t he snapshot sit e always polls t he m ast er sit e for refreshes.

1 3 .4 .1 Re a l- Tim e ( Syn ch r on ou s) Pr opa ga t ion You can specify synchronous propagat ion eit her by specifying propagat ion_m ode = > 'SYNCHRONOUS' in t he call t o DBMS_REPCAT.CREATE_SNAPSHOT_REPGROUP or by using DBMS_REPCAT.ALTER_SNAPSHOT_PROPAGATI ON t o change t he propagat ion m ode if t he snapshot replicat ion group already exist s. I f you elect t o use synchronous propagat ion, Oracle follows t hese st eps t o forward updat eable snapshot DML back t o t he m ast er sit e: 1. Oracle locks t he record in t he snapshot base t able and perform s t he updat e. 2. Oracle fires t he USTRG$_snapshot _nam e t rigger which invokes t he t able_nam e$RP package at t he m ast er sit e. 3. The t able_nam e$RP package at t he m ast er sit e locks and updat es t he record in t he m ast er t able. 4. I f an unresolvable conflict arises at t he m ast er sit e, t he t able_nam e$RP package raises an except ion. 5. Oracle com m it s t he t ransact ion ( or rolls back in t he event of an error) using t he t wo- phase com m it prot ocol. All locks are t hen released.

You should not use synchronous propagat ion unless you are cert ain t hat t he net work connect ion bet ween t he t wo dat abases will not go down, or you can t olerat e int errupt ions in service if t he connect ion is unavailable.

321

Oracle Distributed Systems

1 3 .4 .2 On ce - a - D a y Pr opa ga t ion Applicat ions t hat accum ulat e dat a t hrough t he course of t he day and feed it t o t he m ast er dat abase are candidat es for a once- per- day propagat ion scenario. Typically, t he only t im e when t he snapshot and m ast er dat abase are in cont act is during t his dat a upload period. Therefore, t he snapshot sit e should not only upload t he local changes but also refresh snapshot s wit h new dat a from t he m ast er. We can force Oracle t o push queued DML from t he updat eable snapshot in t he course of perform ing refreshes by set t ing t he param et er push_deferred_rpc t o TRUE in t he call t o DBMS_REFRESH.MAKE: EXECUTE dbms_refresh.make( name => list => next_date => interval => push_deferred_rpc => lax =>

'RG_SPROCKET', 'SPROCKET.DAILY_SALES', TRUNC(SYSDATE+1) + 1/24, 'TRUNC(SYSDATE+1)+23/24', TRUE, TRUE);

This call adds t he snapshot t o t he RG_SPROCKET snapshot refresh group and schedules it for it s init ial refresh t om orrow at 1: 00 A.M.: next_date

=> TRUNC(SYSDATE+1) + 1/24, -

The call also schedules a j ob queue ent ry which perform s all fut ure refreshes for 11: 00 P.M. night ly ( by a call t o DBMS_REFRESH.REFRESH) : interval

=> 'TRUNC(SYSDATE+1)+23/24', -

1 3 .4 .3 Pr opa ga t ion on D e m a n d Anot her scenario calling for an updat eable snapshot involves t he t raveling salesperson who ent ers sales leads and cust om er inform at ion int o a lapt op com put er and who dials in t o t he headquart ers sit e at unpredict able t im es. This person needs t o upload t he inform at ion from t he lapt op t o t he headquart ers sit e and refresh snapshot s on dem and. I t does not really m ake sense t o schedule a j ob on t he lapt op m achine because t here is no guarant ee t hat t he m ast er dat abase will be reachable when t he j ob runs. I nst ead, we creat e t he snapshot refresh group wit hout specifying a refresh int erval. We do, however, specify next _dat e t o be SYSDATE because we want t o populat e t he snapshot s when t he refresh group is originally creat ed: EXECUTE dbms_refresh.make( name => list => next_date => push_deferred_rpc => lax =>

'RG_SPROCKET', 'SPROCKET.DAILY_SALES', SYSDATE, TRUE, TRUE);

To perform t he dat a upload and snapshot refresh on dem and, t he salesperson sim ply calls DBMS_REFRESH.REFRESH:

322

Oracle Distributed Systems EXECUTE dbms_refresh.refresh('RG_SPROCKET') Of course, you m ay wish t o creat e a script t hat allows t he salesperson t o perform t he refresh by clicking on an icon rat her t han having t o use SQL* Plus!

D BM S_ SN APSH OT.REFRESH You m ay have not iced t hat Oracle provides t wo different REFRESH procedures, one in DBMS_REFRESH and t he ot her in DBMS_SNAPSHOT. Why? The DBMS_REFRESH version of REFRESH operat es on all snapshot s in a single refresh group, and t his m et hodology is t he direct ion in which t he replicat ion t echnology is m oving. The DBMS_SNAPSHOT version of REFRESH allows you do refresh snapshot s t hat are not m em bers of a refresh group or a set of snapshot s t hat are m em bers of different refresh groups. The DBMS_SNAPSHOT version also allows you t o specify various param et ers, such as rollback_segs, whereas snapshot refresh groups have t hese set t ings defined in t he call t o DBMS_REFRESH.MAKE. Snapshot refresh groups are generally m uch easier t o m aint ain t han m ult iple ungrouped snapshot s. Our recom m endat ion is t o group all snapshot s so you will be able t o use DBMS_REFRESH.REFRESH.

1 3 .5 M a int e na nce I n addit ion t o t he adm inist rat ive t asks associat ed wit h read- only snapshot s, updat eable snapshot s require t he dat abase adm inist rat or t o perform a num ber of m aint enance t asks.

1 3 .5 .1 Alt e r in g t h e M a st e r Ta ble I f t he st ruct ure of t heupdat eable snapshot 's m ast er t able changes, t he updat eable snapshot m ust reflect t he m odificat ion. Since updat eable snapshot s are regist ered as replicat ed obj ect s, a change t o a m ast er t able will generat e appropriat e DDL calls for all snapshot sit es. However, unlike DDL changes in a m ult i- m ast er replicat ed environm ent t hat Oracle propagat es when you call DBMS_REPCAT.GENERATE_REPLI CATI ON_SUPPORT, t he snapshot sit e m ust request t he DDL changes from t he m ast er. The built - in package procedure DBMS_REPCAT.REFRESH_SNAPSHOT_REPGROUP m akes t his request . Suppose you wish t o m ake t he dist ribut or_id colum n nullable in t he t able SPROCKET.DAI LY_SALES. You would follow t hese st eps:

323

Oracle Distributed Systems 1. Alt er t he t able at t he m ast er sit e, connect ed t o t he replicat ion adm inist rat or account at t he m ast er sit e: 2. EXECUTE dbms_repcat.suspend_master_activity('RG_SPROCKET'); 3. 4. EXECUTE dbms_repcat.alter_master_repobject( 5. sname => 'SPROCKET', 6. oname => 'DAILY_SALES', 7. type => 'TABLE', 8. ddl_text => 'ALTER TABLE SPROCKET.DAILY_SALES 9. MODIFY (DISTRIBUTOR_ID NULL)'); 10. 11. EXECUTE dbms_repcat.generate_replication_support( 12. sname => 'SPROCKET', 13. oname => 'DAILY_SALES', 14. type => 'TABLE'); 15. EXECUTE dbms_repcat.resume_master_activity('RG_SPROCKET'); 16. At t he snapshot sit e, request t he changes. Connect t o t he replicat ion adm inist rat or account at t he snapshot sit e: 17. EXECUTE dbms_repcat.refresh_snapshot_repgroup( 18. gname => 'RG_SPROCKET' refresh_snapshots => TRUE); Refer t o Appendix A, for a com plet e descript ion of t he param et ers in t he DBMS_REPCAT.REFRESH_SNAPSHOT_REPGROUP procedure.

I f you change t he shape of a m ast er t able by adding colum ns or changing t he size of colum ns, you are required t o drop and re- creat e t he snapshot .

1 3 .5 .2 D r oppin g a Re plica t e d Sn a psh ot Obj e ct You m ay wish t o drop a snapshot , eit her because it is no longer required at t he snapshot sit e or because t he m ast er t able no longer exist s. Here we describe how t o approach bot h scenarios.

1 3 .5 .2 .1 M a st e r t a ble st ill e x ist s Use DBMS_REPCAT.DROP_SNAPSHOT_REPOBJECT t o drop a specific snapshot from a snapshot refresh group or DBMS_REPCAT.DROP_SNAPSHOT_REPGROUP t o drop t he ent ire group. The first exam ple drops an updat eable snapshot from a snapshot refresh group: EXECUTE dbms_repcat.drop_snapshot_repobject( sname => 'RG_SPROCKET', oname => 'DAILY_SALES', type => 'SNAPSHOT' drop_objects => TRUE);

324

Oracle Distributed Systems The next exam ple drops t he snapshot replicat ion group: EXCUTE dbms_repcat.drop_snapshot_repgroup( gname => 'RG_SPROCKET', drop_contents => TRUE)' Refer t o Appendix A for a com plet e descript ion of t he param et ers t o t hese procedures.

1 3 .5 .2 .2 Re m a st e r in g a sn a psh ot I f a snapshot 's m ast er t able is part of a m ult i- m ast er replicat ed environm ent , you can " rem ast er" your snapshot t o any of t he ot her m ast er sit es if t he original m ast er becom es unavailable or ot herwise irrelevant . The built - in package procedure t o use is DBMS_REPCAT.SWI TCH_SNAPSHOT_MASTER: EXECUTE dbms_repcat.switch_snapshot_master( gname => 'RG_SPROCKET' master => 'PHKG.BIGWHEEL.COM); Not e t he following when using t his procedure: • •

•

•

You m ust call t his procedure from t he snapshot sit e. At t he t im e of t he swit ch, Oracle will perform a com plet e refresh of t he snapshot s in t he refresh group using m ast er t ables at t he new m ast er t able. You are encouraged t o build snapshot logs on t he m ast er t ables at t he new sit e if t hey do not already exist . I f t he original m ast er sit e is not available when SWI TCH_SNAPSHOT_MASTER is called, t he original m ast er sit e does not receive not ificat ion t hat it is no longer t he m ast er. Therefore, you should purge or drop t he m ast er log, if one exist s; if you are using Oracle8, you should call DBMS_REPCAT.UNREGI STER_SNAPSHOT_REPGROUP at t he original m ast er sit e.

325

Oracle Distributed Systems

Ch a pt e r 1 4 . Pr oce du r a l Re plica t ion The row- level, or m ult i- m ast er, com ponent of Oracle's advanced replicat ion facilit ies were never int ended t o support t ransact ions t hat m odify num erous records. I nst ead, using procedural replicat ion you can writ e PL/ SQL procedures around such operat ions and replicat e calls t o t he procedures inst ead of t o t he row- level t ransact ions.

1 4 .1 W h e n t o Use Pr oce du r a l Re plica t ion There is no hard lim it on how m any records a single t ransact ion can m odify in a t able t hat is undergoing row- level replicat ion, but as a general rule, m odifying m ore t han about 100 records in a single t ransact ion is not advisable, at least not on a regular basis. Bear in m ind t hat even t hough you m ay use a single t ransact ion t o m odify m ult iple records, Oracle queues an RPC for each m odified record. Before you know it , t he deferred t ransact ion queue m ay have t housands of ent ries. Typical operat ions t hat are ideal candidat es for procedural replicat ion include t he following: Bat ch updat es For exam ple, a t ransact ion t hat adj ust s t he price of all it em s in a cat alog Dat a purging For exam ple, delet ing all records t hat are older t han a cert ain dat e Dat a archiving For exam ple, m oving sales records from t he previous quart er int o an archive t able Specialt y operat ions For exam ple, creat ing or dropping a user in m ult iple dat abases ( see t he exam ple in t his chapt er) This list is by no m eans exhaust ive. Row- level replicat ion is best suit ed for t ransact ions t hat m odify a single record. Consider procedural replicat ion for everyt hing else.

1 4 .2 H ow Pr oce du r a l Re plica t ion W or k s Procedural replicat ion execut es your procedure call in t he local dat abase and queues a call t o t he procedure in all ot her m ast er dat abases in t he replicat ion group, using what ever param et ers you pass. This m echanism requires a " wrapper" procedure t hat calls t he procedure t hat locally does t he queueing. I t also requires t hat t he procedure be regist ered as a replicat ed obj ect in all dat abases in t he replicat ion group.

326

Oracle Distributed Systems As an exam ple, suppose t hat we have a package procedure USER_ADMI N.CREATE_USER and a replicat ed wrapper package DEFER_USER_ADMI N. A call t o t he wrapper package result s in t he following chain of event s: 1. 2. 3. 4.

Call t o DEFER_USER_ADMI N.CREATE_USER( 'SCOTT', 'TI GER') . DEFER_USER_ADMI N calls USER_ADMI N.CREATE_USER( 'SCOTT', 'TI GER') . Procedure USER_ADMI N.CREATE_USER execut es locally. DEFER_USER_ADMI N builds a rem ot e call t o USER_ADMI N.CREATE_USER in ot her m ast er dat abases in t he sam e replicat ion group. The rem ot e call is placed in t he deferred t ransact ion queue. 5. Procedure USER_ADMI N.CREATE_USER execut es at rem ot e dat abases. Figure 14.1 depict s t hese event s.

Figu r e 1 4 .1 . H ow pr oce du r a l r e plica t ion w or k s

1 4 .3 Cr e a t in g a Re plica t e d Pa ck a ge Pr oce du r e Creat ing a replicat ed package procedure is easy. Sim ply regist er an exist ing package as a replicat ed obj ect wit h DBMS_REPCAT.CREATE_MASTER_REPOBJECT and t hen generat e replicat ion support for it . I recom m end t hat you pre- creat e your packages in all m ast er dat abases before regist ering t hem for replicat ion.

I f your replicat ed procedure m odifies a t able t hat is undergoing row- level replicat ion, you should disable replicat ion wit hin t he procedure by calling DBMS_REPUTI L.REPLI CATI ON_OFF before any SQL st at em ent s t hat perform DML on t he t able. Be sure t o call DBMS_REPUTI L.REPLI CATI ON_ON aft er t hese SQL st at em ent s.

327

Oracle Distributed Systems

To enable replicat ed calls t o t he package USERADMI N, we would m ake t hese DBMS_REPCAT calls: EXECUTE dbms_repcat.create_master_repobject( sname => 'SYSTEM', oname => 'USER_ADMIN', type => 'PACKAGE', use_existing_object => TRUE, retry => FALSE, gname => 'RG_SPROCKET'); EXECUTE dbms_repcat.create_master_repobject( sname => 'SYSTEM', oname => 'USER_ADMIN', type => 'PACKAGE BODY', use_existing_object => TRUE, retry => FALSE, gname => 'RG_SPROCKET'); EXECUTE dbms_repcat.generate_replication_support( name => 'SYSTEM', oname => 'USER_ADMIN', type => 'PACKAGE', package_prefix => 'DEFER_'); EXECUTE dbms_repcat.generate_replication_support( sname => 'SYSTEM', oname => 'USER_ADMIN', type => 'PACKAGE BODY', package_prefix => 'DEFER_'); Not e t hat we m ust call t he CREATE_MASTER_REPOBJECT and GENERATE_REPLI CATI ON_SUPPORT packages for t he package as well as t he package body. The net result of t hese calls is t he creat ion of a wrapper package called DEFER_USER_ADMI N. This package is t he one t o invoke if you want calls t o USER_ADMI N t o be replicat ed; it builds t he RPCs required t o replicat e t he call. You can also use t he wrapper t o execut e USER_ADMI N at rem ot e sit es only or at t he local sit e only, because it adds t he param et ers CALL_LOCAL and CALL_REMOTE t o each procedure wit hin t he original package. The specificat ion for t he generat ed package DEFER_USER_ADMI N is as follows: package DEFER_USER_ADMIN as I_am_a_snapshot CHAR; procedure CHANGEPASS( IN_USERNAME IN varchar2, IN_PASSWORD IN varchar2, call_local IN char := 'N', call_remote IN char := 'Y'); procedure CREATEUSER(

328

Oracle Distributed Systems IN_USERNAME IN varchar2, IN_PASSWORD IN varchar2, call_local IN char := 'N', call_remote IN char := 'Y'); procedure DROPUSER( IN_USERNAME IN varchar2, call_local IN char := 'N', call_remote IN char := 'Y'); procedure GRANTROLE( IN_USERNAME IN varchar2, IN_ROLE IN varchar2, IN_DEFAULTYN IN varchar2, call_local IN char := 'N', call_remote IN char := 'Y'); procedure REVOKEROLE( IN_USERNAME IN varchar2, IN_ROLE IN varchar2, call_local IN char := 'N', call_remote IN char := 'Y'); end DEFER_USER_ADMIN;

I n Oracle8 t he wrapper package is owned by t he replicat ion propagat or account ( t ypically PROPREP) . I f you unregist er t he propagat or account , all wrapper procedures will be dropped.1 Each of t he procedures in DEFER_USER_ADMI N builds a deferred call t o t he corresponding call in USER_ADMI N if t he call_rem ot e param et er is set t o 'Y'. For exam ple, t he procedure DEFER_USER_ADMI N.CREATE_USER builds a deferred call t o USER_ADMI N.CREATE_USER: procedure "CREATE_USER"( "IN_USERNAME" IN VARCHAR2, "IN_PASSWORD" IN VARCHAR2, call_local IN char := 'N', call_remote IN char := 'Y') is begin select decode(master, 'N', 'Y', 'N') into I_am_a_snapshot from all_repcat where gname = 'RG_SPROCKET'; if call_local = 'Y' then "SYSTEM"."USER_ADMIN"."CREATE_USER"( "IN_USERNAME", "IN_PASSWORD"); end if; if call_remote = 'Y' then dbms_defer.call('SYSTEM', 'USER_ADMIN', 'CREATE_USER', 2, 'RG_LIVE'); dbms_defer.varchar2_arg("IN_USERNAME"); dbms_defer.varchar2_arg("IN_PASSWORD"); end if; end "CRE ATE_USER";

329

Oracle Distributed Systems

1 4 .4 Re st r ict ion s on Pr oce du r a l Re plica t ion Oracle im poses various rest rict ions on replicat ed procedures, as follows: • • • • • • •

All replicat ed procedures m ust be package procedures. Replicat ion of funct ions is not support ed. All procedure param et ers m ust be I N param et ers; OUT and I N OUT param et ers are not support ed. Param et ers of t ype BOOLEAN are not support ed. Oracle supplies no conflict resolut ion t echniques for procedural replicat ion. Replicat ed procedures should not m anipulat e rem ot e dat a. All replicat ion groups m ust be in NORMAL m ode when m aking a replicat ed procedure call ( i.e., no replicat ion groups can be quiesced) .

1 4 .5 An Ex a m ple Since dat a dict ionary t ables cannot be replicat ed, t he DBA m ust perform various adm inist rat ive t asks in m ult iple sit es. One part icular t ask t hat I have found t o be a needless nuisance is user adm inist rat ion, so I have creat ed t he package USERADMI N t o replicat e calls t o creat e and drop users and t o grant and revoke roles. The script s t o creat e t he package are: cr_seq_audit _adm in.sql Creat es t he sequence SEQ_AUDI T_ADMI N which is used t o populat e t he I D field in t he t able AUDI T_ADMI N. cr_audit _adm in.sql Creat es t he t able AUDI T_ADMI N, which logs usage of t he USERADMI N package. pl_useradm in.sql Calls t he script s cr_seq_audit _adm in.sql and cr_audit _adm in.sql and creat es t he package USERADMI N. This script should be run by user SYSTEM. These script s are included here .

1 4 .5 .1 cr _ se q_ a u dit _ a dm in .sql --------------------------------------------------------------------------- Filename: cr_seq_audit_admin.sql -- Purpose: Creates SEQ_AUDIT_ADMIN used by USER_ADMIN procedure -- Author: Chas. Dye ([email protected]) -- Date: 5-Mar-1998 -------------------------------------------------------------------------set echo on

330

Oracle Distributed Systems set termout on spool seq_audit_admin.log DROP PUBLIC SYNONYM seq_audit_admin / DROP SEQUENCE seq_audit_admin / CREATE SEQUENCE seq_audit_admin START WITH 1 / CREATE PUBLIC SYNONYM seq_audit_admin FOR seq_audit_admin / spool off

1 4 .5 .2 cr _ a u dit _ a dm in .sql --------------------------------------------------------------------------- Filename: cr_audit_admin.sql -- Purpose: Creates table to be used by USER_ADMIN procedure. -- Author: Chas. Dye ([email protected]) -- Date: 5-Mar-1998 -------------------------------------------------------------------------set echo on set termout on spool audit_admin.log DROP PUBLIC SYNONYM audit_admin / DROP TABLE audit_admin CASCADE CONSTRAINTS / CREATE TABLE audit_admin ( audit_id NUMBER(10) NOT NULL, procname VARCHAR2(12), info VARCHAR2(40), errornum NUMBER(6), audit_user VARCHAR2(30), audit_date DATE ) / CREATE PUBLIC SYNONYM audit_admin FOR audit_admin / ALTER TABLE audit_admin ADD ( CONSTRAINT pk_audit_admin PRIMARY KEY (audit_id) ) / CREATE OR REPLACE TRIGGER t_brr_iu_audit_admin BEFORE INSERT OR UPDATE ON audit_admin FOR EACH ROW

331

Oracle Distributed Systems

BEGIN :new.audit_user := USER; :new.audit_date := SYSDATE; END; / spool off

1 4 .5 .3 pl_ u se r a dm in .sql ----------------------------------------------------------------------------- Filename: pl_useradmin.sql -- Purpose: Utility to perform user administration on multiple databases. -- Author: Chas. Dye ([email protected]) -- Date: 5-Mar-1998 ---------------------------------------------------------------------------set echo on set termout on @@cr_seq_audit_admin @@cr_audit_admin spool useradmin.log DROP PUBLIC SYNONYM UserAdmin /

1 4 .5 .4 r e p_ u se r a dm in .sql CREATE OR REPLACE PACKAGE UserAdmin IS PROCEDURE CreateUser(IN_Username VARCHAR2, IN_Password VARCHAR2 ); PROCEDURE DropUser(IN_Username VARCHAR2 ); PROCEDURE ChangePass(IN_Username VARCHAR2, IN_Password VARCHAR2 ); PROCEDURE GrantRole(IN_Username VARCHAR2, IN_Role VARCHAR2, IN_DefaultYN VARCHAR2 DEFAULT 'N' ); PROCEDURE RevokeRole(IN_Username VARCHAR2, IN_Role VARCHAR2 ); END UserAdmin; / CREATE OR REPLACE PACKAGE BODY

UserAdmin IS

----------------------------------------------------------------------------- Note: This package should be owned by SYSTEM because it must be owned -by an id that has CREATE SESSION privileges (schema IDs should -NOT).

332

Oracle Distributed Systems -Also, SYS must make the following explicit grants to SYSTEM: -GRANT ALTER USER TO system -GRANT CREATE USER TO system -GRANT CREATE SESSION TO system WITH ADMIN OPTION -GRANT DROP USER TO system -GRANT GRANT ANY ROLE TO system -GRANT SELECT ON DBA_ROLE_PRIVS TO system -GRANT SELECT ON DBA_SEGMENTS TO system -Optional Grants: -GRANT SELECT ON dba_role_privs TO access_admin -GRANT SELECT ON dba_roles TO access_admin ---------------------------------------------------------------------------PROCEDURE AuditUserAdmin

(IN_Proc VARCHAR2, IN_Info VARCHAR2 IN_Error NUMBER

DEFAULT NULL, DEFAULT NULL ) IS

BEGIN INSERT INTO audit_admin (audit_id, procname, info, errornum, audit_user, audit_date ) VALUES (seq_audit_admin.nextval, IN_Proc, IN_info, IN_Error, user, sysdate ); COMMIT; END AuditUserAdmin; --------------------------------------------------------------------------- PROCEDURE CreateUser creates a user and grants CREATE SESSION to him/her -------------------------------------------------------------------------PROCEDURE CreateUser( IN_Username VARCHAR2, IN_Password VARCHAR2 ) IS hCursor NUMBER; vProcName audit_admin.procname%TYPE := 'CreateUser'; vInfo audit_admin.info%TYPE := NULL; BadPassword EXCEPTION; UserExists EXCEPTION; NameTooLong EXCEPTION; BEGIN IF UPPER(IN_Username) = UPPER(IN_Password) THEN RAISE BadPassword; END IF;

333

Oracle Distributed Systems IF length(IN_Username) > 8 THEN RAISE NameTooLong; END IF; hCursor := dbms_sql.open_cursor; dbms_sql.parse( hCursor, 'CREATE USER ' || IN_Username || ' IDENTIFIED BY ' || IN_Password || ' DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp', dbms_sql.v7); dbms_sql.close_cursor( hCursor); hCursor := dbms_sql.open_cursor; dbms_sql.parse( hCursor, 'GRANT CREATE SESSION TO ' || IN_Username, dbms_sql.v7); dbms_sql.close_cursor( hCursor); vInfo := 'Created ' || IN_Username || ' Password ' || IN_Password; AuditUserAdmin( vProcName, vInfo ); EXCEPTION WHEN NameTooLong THEN vInfo := '!Bad Username: ' || IN_Username; AuditUserAdmin( vProcName, vInfo ); dbms_output.put_line( 'Username must be 8 chars or less.'); RAISE_APPLICATION_ERROR(-20010, 'CreateUser:Username too long'); WHEN BadPassword THEN vInfo := '!Bad Password for ' || IN_Username; AuditUserAdmin( vProcName, vInfo ); dbms_output.put_line( 'Username and Password must differ.'); RAISE_APPLICATION_ERROR(-20020, 'CreateUser:Username=Password'); WHEN OTHERS THEN vInfo := '!Create User ' || IN_Username; AuditUserAdmin( vProcName, vInfo , sqlcode); dbms_output.put_line('error ' || sqlerrm); RAISE_APPLICATION_ERROR(-20030, 'CreateUser:Error ' || sqlerrm); END CreateUser; --------------------------------------------------------------------------- PROCEDURE DropUser drops a user. -------------------------------------------------------------------------PROCEDURE DropUser( IN_Username VARCHAR2 ) IS hCursor NUMBER; vProcName audit_admin.procname%TYPE := 'DropUser'; vInfo audit_admin.info%TYPE := NULL; vSegCount NUMBER; UserHasObjects EXCEPTION; UserIsDBA EXCEPTION; BEGIN IF upper( IN_Username ) IN ('SYS', 'SYSTEM') THEN RAISE UserIsDBA; END IF;

334

Oracle Distributed Systems

SELECT INTO FROM WHERE

count(*) vSegCount dba_segments owner = UPPER( IN_Username );

IF vSegCount > 0 THEN RAISE UserHasObjects; END IF; hCursor := dbms_sql.open_cursor; dbms_sql.parse( hCursor, 'DROP USER ' || IN_Username || ' CASCADE', dbms_sql.v7); dbms_sql.close_cursor( hCursor); vInfo := 'Dropped ' || IN_Username; AuditUserAdmin( vProcName, vInfo ); EXCEPTION WHEN UserIsDBA THEN vInfo := '!DROP ' || IN_Username; AuditUserAdmin( vProcName, vInfo ); dbms_output.put_line('Cannot drop SYS or SYSTEM accounts.'); RAISE_APPLICATION_ERROR(-2110, 'DropUser: User is DBA'); WHEN UserHasObjects THEN vInfo := '!DROP ' || IN_Username; AuditUserAdmin( vProcName, vInfo ); RAISE_APPLICATION_ERROR(-20120, 'DropUser: User owns objects'); WHEN OTHERS THEN vInfo := '!DROP ' || IN_Username; AuditUserAdmin( vProcName, vInfo, sqlcode ); dbms_output.put_line('error ' || sqlerrm); RAISE_APPLICATION_ERROR(-20130, 'DropUser: Error ' || sqlerrm); END DropUser; --------------------------------------------------------------------------- PROCEDURE ChangePass changes a user's password. -------------------------------------------------------------------------PROCEDURE ChangePass(IN_Username VARCHAR2, IN_Password VARCHAR2 ) IS hCursor NUMBER; vProcName audit_admin.procname%TYPE := 'ChangePass'; vInfo audit_admin.info%TYPE := NULL; BadPassword EXCEPTION; PassTooLong EXCEPTION; UserIsDBA EXCEPTION; BEGIN IF upper( IN_Username ) IN ('SYS', 'SYSTEM') THEN RAISE UserIsDBA; END IF; IF UPPER(IN_Username) = UPPER(IN_Password) THEN

335

Oracle Distributed Systems RAISE BadPassword; END IF; IF length(IN_Password) > 30 THEN RAISE PassTooLong; END IF; hCursor := dbms_sql.open_cursor; dbms_sql.parse(hCursor, 'ALTER USER ' || IN_Username ' IDENTIFIED BY ' || IN_Password, dbms_sql.v7); dbms_sql.close_cursor( hCursor);

||

vInfo := 'Changed ' || IN_Username || ' Password ' || IN_Password; AuditUserAdmin( vProcName, vInfo ); EXCEPTION WHEN UserIsDBA THEN vInfo := '!DROP ' || IN_Username; AuditUserAdmin( vProcName, vInfo ); dbms_output.put_line('Cannot change SYS or SYSTEM passwords.'); RAISE_APPLICATION_ERROR(-20210, 'ChangePass:Cannot change DBA'); WHEN PassTooLong THEN vInfo := '!Bad Username: ' || IN_Username; AuditUserAdmin( vProcName, vInfo ); dbms_output.put_line( 'Password must be 30 chars or less.'); RAISE_APPLICATION_ERROR(-20220, 'ChangePass:password>30 chars'); WHEN BadPassword THEN vInfo := '!Bad Password for ' || IN_Username; AuditUserAdmin( vProcName, vInfo ); dbms_output.put_line( 'Username and Password must differ.'); RAISE_APPLICATION_ERROR(-20230, 'ChangePass:username=password'); WHEN OTHERS THEN vInfo := '!Create User ' || IN_Username; AuditUserAdmin( vProcName, vInfo , sqlcode); RAISE_APPLICATION_ERROR(-20240, 'ChangePass:Error ' || sqlerrm); END ChangePass; --------------------------------------------------------------------------- PROCEDURE GrantRole grants roles. -------------------------------------------------------------------------PROCEDURE GrantRole(IN_Username VARCHAR2, IN_Role VARCHAR2, IN_DefaultYN VARCHAR2 DEFAULT 'N') IS CURSOR cDefRole IS SELECT granted_role FROM dba_role_privs WHERE grantee = UPPER(IN_Username) AND default_role = 'YES'; hCursor vProcName vInfo

NUMBER; audit_admin.procname%TYPE audit_admin.info%TYPE

:= 'GrantRole'; := NULL;

336

Oracle Distributed Systems vRoleStr VARCHAR2(2000) := NULL; vDefRoleCount NUMBER := 0; vHasDefRoles BOOLEAN := FALSE; vRoleCheck NUMBER := 0; UserIsDBA EXCEPTION; NoPrivRoles EXCEPTION; RoleAlready EXCEPTION; BEGIN vInfo := 'Grant ' || IN_Role || ' to ' || IN_Username; IF UPPER(IN_Username) IN ('SYS', 'SYSTEM') THEN RAISE UserIsDBA; END IF; IF UPPER(IN_Role) IN ( THEN RAISE NoPrivRoles; END IF; SELECT INTO FROM WHERE AND

count(*) vRoleCheck dba_role_privs grantee granted_role

'DBA', 'CONNECT', 'RESOURCE')

= UPPER(IN_Username) = UPPER(IN_Role);

IF vRoleCheck > 0 THEN RAISE RoleAlready; END IF; FOR rDefRole IN cDefRole LOOP vRoleStr := vRoleStr || rDefRole.granted_role || ','; vDefRoleCount := vDefRoleCount + 1; END LOOP; IF ( vDefRoleCount > 0 ) OR ( IN_DefaultYN = 'Y' ) THEN vHasDefRoles := TRUE; IF ( vDefRoleCount > 0 ) AND ( IN_DefaultYN = 'N' ) THEN vRoleStr := substr(vRoleStr, 1, length(vRoleStr) - 1 ); ELSIF ( vDefRoleCount > 0 ) AND ( IN_DefaultYN = 'Y' ) THEN vRoleStr := vRoleStr || ' ' || IN_Role; ELSIF ( vDefRoleCount = 0 ) AND ( IN_DefaultYN = 'Y' ) THEN vRoleStr := IN_Role; END IF; END IF; ------------------------------- First grant the new role ------------------------------hCursor := dbms_sql.open_cursor; dbms_sql.parse (hCursor, 'GRANT ' || IN_Role || ' TO '|| IN_Username, dbms_sql.v7);

337

Oracle Distributed Systems dbms_sql.close_cursor( hCursor); --------------------------------------- Now set user to no default roles --------------------------------------hCursor := dbms_sql.open_cursor; dbms_sql.parse (hCursor, 'ALTER USER ' || IN_Username || ' DEFAULT ROLE NONE', dbms_sql.v7); dbms_sql.close_cursor( hCursor); ---------------------------------- Now grant any default roles ---------------------------------IF vHasDefRoles = TRUE THEN hCursor := dbms_sql.open_cursor; dbms_sql.parse( hCursor, 'ALTER USER ' ||IN_Username||' DEFAULT ROLE '||vRoleStr, dbms_sql.v7); dbms_sql.close_cursor( hCursor); END IF; AuditUserAdmin( vProcName, vInfo ); EXCEPTION WHEN UserIsDBA THEN vInfo := '!' || vInfo; AuditUserAdmin( vProcName, vInfo ); dbms_output.put_line('Cannot grant to SYS or SYSTEM accounts.'); RAISE_APPLICATION_ERROR(-2410, 'GrantRole: Cannot grant SYS'); WHEN RoleAlready THEN vInfo := '!' || vInfo; AuditUserAdmin( vProcName, vInfo ); dbms_output.put_line(IN_Username ||' already has ' || IN_Role); RAISE_APPLICATION_ERROR(-20420, 'GrantRole:Role already grntd'); WHEN NoPrivRoles THEN vInfo := '!' || vInfo; AuditUserAdmin( vProcName, vInfo ); dbms_output.put_line('Not authorized to grant ' || IN_Role); RAISE_APPLICATION_ERROR(-20430, 'GrantRole: Cannot grant DBA'); WHEN OTHERS THEN vInfo := '!' || vInfo; AuditUserAdmin( vProcName, vInfo, sqlcode ); dbms_output.put_line('error ' || sqlerrm); RAISE_APPLICATION_ERROR(-20440, 'GrantRole: Error ' || sqlerrm); END GrantRole; --------------------------------------------------------------------------- PROCEDURE RevokeRole revokes roles. -------------------------------------------------------------------------PROCEDURE RevokeRole( IN_Username VARCHAR2, IN_Role VARCHAR2 ) IS hCursor NUMBER;

338

Oracle Distributed Systems vProcName vInfo UserIsDBA

audit_admin.procname%TYPE audit_admin.info%TYPE EXCEPTION;

:= 'RevokeRole'; := NULL;

BEGIN IF UPPER(IN_Username) IN ('SYS', 'SYSTEM') THEN RAISE UserIsDBA; END IF; hCursor := dbms_sql.open_cursor; dbms_sql.parse( hCursor, 'REVOKE ' || IN_Role || ' FROM ' || IN_Username, dbms_sql.v7); dbms_sql.close_cursor( hCursor); vInfo := 'Revoke ' || IN_Role || ' from ' || IN_Username; AuditUserAdmin( vProcName, vInfo ); EXCEPTION WHEN UserIsDBA THEN vInfo := '!Revoke ' || IN_Role || ' FROM ' || IN_Username; AuditUserAdmin( vProcName, vInfo ); dbms_output.put_line('Cannot revoke from SYS or SYSTEM.'); RAISE_APPLICATION_ERROR(-20510, 'RevokeRole:Cannot revoke SYS'); WHEN OTHERS THEN vInfo := '!Revoke ' || IN_Role || ' FROM ' || IN_Username; AuditUserAdmin( vProcName, vInfo, sqlcode ); dbms_output.put_line('error ' || sqlerrm); RAISE_APPLICATION_ERROR(-20520, 'RevokeRole:Error ' || sqlerrm); END RevokeRole; END UserAdmin; / CREATE PUBLIC SYNONYM UserAdmin FOR UserAdmin / CREATE ROLE access_admin / GRANT EXECUTE ON useradmin TO access_admin / spool off

339

Oracle Distributed Systems

340

Oracle Distributed Systems

Ch a pt e r 1 5 . Con flict Avoida n ce a n d Re solu t ion Te ch n iqu e s Dat a int egrit y and consist ency are perhaps t he m ost significant challenges for t he adm inist rat or of an advanced replicat ion environm ent . Since users can perform DML on a given t able in m ult iple Oracle inst ances, t he adm inist rat or's responsibilit y expands from guarant eeing dat a int egrit y locally t o ensuring dat a convergence globally. For exam ple, if t wo users at t wo sit es updat e an em ployee's salary t o t wo different values, how do we det erm ine which value t o accept and how do we ensure t hat t he correct value is propagat ed t o all sit es t hat have t he replicat ed t able? I t can be done, and Oracle provides a variet y of built - in conflict resolut ion handlers, but t o use t hese t echniques successfully, developers and adm inist rat ors m ust underst and and ant icipat e all likely scenarios t hat would result in conflict s. They also m ust underst and how Oracle replicat es DML and consider t he lim it at ions of t he conflict handlers.

1 5 .1 D a t a I n t e gr it y Ve r su s D a t a Con ve r ge n ce Dat a int egrit y refers t o dat a t hat is consist ent wit h t he const raint s t hat are defined for it . These const raint s m ay be referent ial int egrit y const raint s. For exam ple, t he value of t he Po_Num field for records in t able LI NE_I TEMS m ight be rest rict ed t o values of Po_Num t hat exist in t he PURCHASE_ORDERS t able. Dat a also m ay be rest rict ed t o ranges t hat are independent of ot her t ables; a gender field m ay be rest rict ed t o t he values M and F. Ot her exam ples of int egrit y const raint s include NOT NULL fields and UNI QUE const raint s. I f you design a schem a using t he const raint - checking funct ionalit y t hat is built int o t he dat abase ( prim ary keys, foreign keys, check const raint s, et c.) , you are guarant eed t hat t he dat a wit hin t hat schem a will always adhere t o t he rules you have defined. I f your schem a exist s in only one dat abase inst ance, your concerns about dat a int egrit y should be few, and your concerns about dat a convergence should be none. However, if you are responsible for a replicat ed environm ent , you m ust ensure t hat dat a is consist ent wit hin and am ong dat abase inst ances. Dat a convergence refers t o t he scenario in which all replicat ed t ables cont ain ident ical dat a t hat is consist ent wit h t he const raint s defined in each dat abase. Oracle does not provide a m eans t o enforce referent ial int egrit y am ong dat abases, nor should it ; t he m odel of advanced replicat ion is t hat local t ransact ions succeed regardless of problem s t hat m ay occur at ot her sit es. Therefore, DML t hat result s in a conflict at t he dest inat ion sit e m ust be resolved at t he dest inat ion sit e. Since t he obj ect ive is for dat a t o converge, t he conflict resolut ion could ult im at ely result in overwrit ing t he change at t he originat ing sit e. For exam ple, an opt im ist ic user of an order ent ry syst em m ay process an order and updat e it s st at us t o SHI PPED in her dat abase, which is replicat ed t o t he order fulfillm ent dat abase. The user at t he order fulfillm ent sit e sees t hat t he it em is out of st ock and updat es t he st at us t o BACKORDERED. Ult im at ely, t he order should have a st at us of BACKORDERED in bot h dat abases.

341

Oracle Distributed Systems

1 5 .2 Applica t ions Th a t Avoid Con flict s I deally, applicat ions never have conflict s, cert ainly never any unresolved conflict s. Alt hough it is highly unlikely t hat any significant applicat ion can avoid conflict s ent irely, such conflict s can cert ainly be kept t o a m inim um by observing som e com m on sense and by t aking advant age of t he t echniques t hat are available wit h t he advanced replicat ion facilit ies. The t im e you spend during t he design phase t o m ake your applicat ion " replicat ion ready" will save considerable frust rat ion lat er.

1 5 .2 .1 N or m a lize Yes, once again, som ebody is t elling you t o norm alize your schem a. I n addit ion t o t he benefit s of norm alizat ion t hat are ext olled elsewhere, a norm alized schem a is far easier t o replicat e. Why? Consider a schem a t hat is in first norm al form ( 1NF) —t hat is, it s t ables cont ain redundant dat a. For exam ple, a CUSTOMER t able m ight have a colum n com pany_nam e. I f t his t able cont ains 1000 records for cust om ers who work for Acm e Tire and Rubber, t hen 1000 records will have t o be updat ed when Acm e Tire and Rubber changes it s nam e t o Acm e Tire and Rubber and Lawn Furnit ure. Since every updat e is a pot ent ial conflict , updat es should be kept t o a m inim um . I n addit ion, if a field such as com pany_nam e appears in num erous t ables, you will have t o devot e significant effort t o devising m et hods t o ensure t hat an updat e t o t he field in one t able affect s t he appropriat e updat es in t he ot her t ables not only locally, but also globally. A m ore pract ical concern wit h a denorm alized schem a is t hat such schem as are t ypically charact erized by t ables wit h m any ( i.e., t ens of) colum ns. Since replicat ed DML m ust com pare t he old and new values of every colum n of every changed row, perform ance will suffer. An unfort unat e m yt h am ong dat abase designers is t hat norm alizat ion reduces perform ance. The t hinking is t hat since a denorm alizat ion can lead t o a perform ance gain, any st eps in t he opposit e direct ion m ust lead t o perform ance losses. This conclusion is far from accurat e; do not denorm alize for perform ance wit hout t he m et rics t o j ust ify it .

1 5 .2 .2 D e sign a t e a Gove r n in g Colu m n for Colu m n Gr ou ps Replicat ed applicat ions invariably use built - in resolut ion t echniques based on colum n groups. To m ake colum n groups work m ost efficient ly, you should design t ables in such a way t hat one colum n is t he " governing" colum n for each group. For exam ple, in a t able wit h t wo colum n groups, t he t im est am p field m ight govern a Lat est Tim est am p resolut ion m et hod t hat is associat ed wit h one group, while a global_nam e field governs t he second group whose resolut ion m et hod is Sit e Priorit y. I t is quit e conceivable t hat a t able could have t wo colum n groups which bot h use Lat est Tim est am p as a resolut ion m et hod, which would m ean having t wo t im est am p fields in t he t able ( wit h different nam es, of course) . The m ain point t o rem em ber is t hat you m ust have a governing field for each colum n group t hat uses any of t he following resolut ion m et hods:

342

Oracle Distributed Systems • • •

Earliest / Lat est Tim est am p Priorit y Group Sit e Priorit y

1 5 .2 .3 St a n da r dize on a Tim e Zon e I f you plan t o use t im est am ps t o resolve conflict s, it is vit al t hat t he t im est am ps from t he various sit es part icipat ing in replicat ion are based on t he sam e t im e zone; t im est am ps in t he Oracle RDBMS do not include a t im e zone com ponent . Therefore, you are st rongly encouraged t o put your dat abase servers on Greenwich Mean Tim e ( GMT) or som e ot her m ut ually accept able t im e zone, preferably one t hat does not observe daylight savings t im e. This is t he only way t o guarant ee t hat t im est am ps are perform ed correct ly. Of course, t here is som e inconvenience if your applicat ion cont ains dat a t hat is t im e crit ical, such as a t im e and at t endance syst em . However, it is far sim pler t o have t he applicat ion perform t im e arit hm et ic for display and report ing purposes t han t o rewrit e t he t im est am p conflict resolut ion rout ines t o calculat e t he t im e differences am ong your sit es.

1 5 .2 .4 I de n t ify W or k flow The workflow of a replicat ed applicat ion should be well defined and well underst ood. The m ore oft en a row is updat ed during it s lifet im e, t he m ore challenging it is for m ult iple sit es t o converge on t he " correct " values for t hat row, especially if m ult iple sit es are able t o perform updat es sim ult aneously. To t he great est ext ent possible, t he applicat ion should associat e cert ain t ypes of act ivit ies wit h cert ain sit es. For exam ple, updat es associat ed wit h credit card inform at ion should occur at t he billing locat ion, and updat es associat ed wit h shipm ent s should happen at t he shipping locat ion. Such rest rict ions are known as workflow part it ioning or dynam ic ownership. Workflow part it ioning is possible only if it is designed int o t he applicat ion from t he beginning; im posing it lat er is generally not an opt ion. This approach avoids conflict s by associat ing dat a wit h a cert ain sit e when it is in a cert ain st at e ( i.e., when a specific WHERE clause is t rue) . I n t he preceding exam ple, t he billing locat ion owns rows WHERE locat ion = 'BI LLI NG'. The applicat ion does not allow sit es t o updat e rows unless t hey own t hem . Ownership of t he row can change but only if t he sit e t hat current ly owns t he row changes it or " pushes" it t o t he next sit e. The classic exam ple is t he m anufact uring applicat ion in which orders wit h a st at us of ORDERED can be m odified only at t he order ent ry sit e, which updat es records t o SHI P. Then ownership t ransfers t o t he order fulfillm ent sit e, which updat es t he st at us t o BI LL, t hereby t ransferring ownership t o t he account s receivable sit e. You m ust designat e a colum n t o hold st at us values t hat det erm ine row ownership. Any conflict s t hat arise in such an applicat ion can be resolved wit h t he Priorit y Group m et hod, as we shall see lat er.

343

Oracle Distributed Systems

1 5 .2 .5 Con side r Tok e n Pa ssin g I f t he dynam ic dat a ownership m odel does not m at ch your applicat ion's business rules, you can achieve sim ilar result s by using t he t echnique known as t oken passing. As wit h t he workflow part it ioning m et hod, t oken passing associat es row ownership wit h a single sit e at any one t im e. But unlike workflow part it ioning, t oken passing allows any sit e t o t ake ownership of t he row. You m ust add t wo colum ns t o any t able t hat is t o use t oken passing: epoch and global_nam e. The epoch field holds a num ber t hat is increased whenever ownership of t he row changes, and t he global_nam e field holds t he global nam e of t he dat abase t hat owns t he row for t hat value of epoch. The current owner of t he row is t he sit e associat ed wit h t he highest value of t he epoch field. To obt ain ownership of a row, your applicat ion m ust : 1. Find t he highest value in t he epoch colum n and t he associat ed global_nam e for t hat row. 2. Lock t he row. 3. Updat e t he global_nam e of t he row t o t he local global nam e and perform t he sam e updat e at t he previous owner sit e. Turn replicat ion off when updat ing t he previous owner sit e by calling t he DBMS_REPUTI L.REPLI CATI ON_OFF procedure. 4. Turn replicat ion off at t he local sit e and updat e t he row wit h dat a from t he previous owner sit e. 5. Turn replicat ion back on ( DBMS_REPUTI L.REPLI CATI ON_ON) , increm ent t he epoch field at t he local sit e, and perform t he rest of t he int ended updat e. I n order for t oken passing t o work, you m ust include a Maxim um Value resolut ion handler so t hat updat es wit h t he highest epoch value always t ake precedence.

1 5 .2 .6 Pe r for m St r a t e gic Adm in ist r a t ion Ot her t echniques for avoiding conflict s include t he j udicious t im ing of RPC pushes and t he consist ent use of secondary resolut ion m et hods t o handle unusual or unforeseen sit uat ions. Every replicat ed t able should have at least t wo conflict handlers. Alt hough it is generally not advisable t o push t ransact ions m ore t han once every five m inut es or so, t he longer you wait , t he m ore likely it is t hat conflict s will arise when you finally perform t he push, since users at t he dest inat ion sit es have been perform ing t heir own updat es for a longer t im e. You also should im plem ent aut om at ed not ificat ion m echanism s so t hat you receive a page or em ail t o alert you t o conflict s t hat have m anaged t o escape resolut ion, as well as any ot her except ions.

1 5 .3 Type s of Con flict s D e t e ct e d Oracle det ect s conflict s based on PL/ SQL except ions, as sum m arized in Table 15.1, only at t he dest inat ion sit e. Not e t hat conflict det ect ion does not im ply conflict resolut ion.

344

Oracle Distributed Systems

Table 15.1. Detectable PL/SQL Exceptions Type of DML I NSERT

Potential Conflicts DUP_VAL_ON_I NDEX SQL% ROWCOUNT = 0 ( NO_DATA_FOUND)

UPDATE

SQL% ROWCOUNT > 1 ( TOO_MANY_ROWS) DUP_VAL_ON_I NDEX SQL% ROWCOUNT = 0 ( NO_DATA_FOUND)

DELETE SQL% ROWCOUNT > 1 ( TOO_MANY_ROWS) The sit uat ions for which Oracle does not resolve conflict s include: • • • • •

Delet es t hat raise NO_DATA_FOUND errors ( even t hough t hey are det ect ed) Delet es t hat raise TOO_MANY_ROWS errors Use of NULL values in colum ns used for conflict resolut ion DML t hat violat es referent ial int egrit y const raint s Conflict s arising from procedural replicat ion

Why not ? A brief analysis of Oracle's im plem ent at ion reveals why t hese rest rict ions m ust exist .

1 5 .3 .1 Lim it a t ion s of D e le t e Con flict Re solu t ion Because of t he difficult ies of processing delet e conflict s, Oracle's recom m endat ion is t o design replicat ed applicat ions t o flag records as delet ed. I nclude a STATUS colum n in t he t able and updat e it t o D, for exam ple, inst ead of act ually delet ing t he row. This way, you can avoid all pot ent ial delet e conflict s and avoid t he t ask of writ ing your own delet e conflict handling procedure. You can perform t he act ual delet e at scheduled int ervals using procedural replicat ion. I f t his is not an opt ion for your applicat ion, t hen consider t he following alt ernat ives. I f a row delet ed at one sit e m aps t o m ore t han one row at t he dest inat ion sit e ( i.e., t he delet e raises TOO_MANY_ROWS at t he dest inat ion sit e) , t here is no general algorit hm t hat can det erm ine which of t he rows should really be delet ed at t he dest inat ion sit e. Alt hough Oracle det ect s t he condit ion, it is not possible t o pass it t o an except ion handler wit hout m odifying t he code generat ed from t he DBMS_REPCAT.GENERATE_REPLI CATI ON_SUPPORT procedure. Rem em ber, t hough, t hat all replicat ed t ables m ust have prim ary keys. Therefore, if such a conflict ever did arise, it would indicat e t hat t he prim ary key on t he t able has been dropped or disabled, which is cert ainly an avoidable scenario. The scenario of a delet e t hat cannot find t he m at ching row at t he dest inat ion sit e, however, is quit e plausible and should be ant icipat ed. The DBMS_REPCAT.ADD_DELETE_RESOLUTI ON procedure associat es a user- defined conflict handler package wit h delet es t hat raise NO_DATA_FOUND. Again, t here is no general algorit hm t o det erm ine what t o do if t he row t o be delet ed does not exist at

345

Oracle Distributed Systems t he dest inat ion sit e. This could happen if t he row were delet ed or updat ed at t he dest inat ion sit e. Should it be delet ed from t he originat ing sit e? Perhaps, but t hat is a decision for you t o m ake during t he design phase. But no m at t er what , any applicat ion t hat allows delet es from replicat ed t ables m ust include a conflict handler package t hat resolves delet es t hat raise a NO_DATA_FOUND except ion because Oracle will at t em pt t o invoke it .

1 5 .3 .1 .1 D e fin in g a de le t e con flict h a n dle r You should define a conflict handler for every t able for which your applicat ion allows delet es. Rem em ber, t his conflict handler will be invoked only if t he delet e raises t he NO_DATA_FOUND except ion—t hat is, t he row t o be delet ed does not exist at t he dest inat ion sit e. A reasonable course of act ion under t hese circum st ances is t o insert t he row int o a log t able, which t he DBA can review. Suppose you are replicat ing t he t able DEPT, as defined in t he following t able: Column Name

Type

dept no

NUMBER( 2)

dnam e

VARCHAR2( 13)

loc

VARCHAR2( 14)

You would writ e a funct ion t hat insert s t he record int o t able DEPT_DEL_ERR, as defined in t he next t able: Column Name

Type

dept no

NUMBER( 2)

dnam e

VARCHAR2( 13)

loc

VARCHAR2( 14)

t im e st a m p

D ATE

use r na m e

VARCH AR2 ( 3 0 )

The funct ion is defined as follows: CREATE OR REPLACE FUNCTION resolve_dept_delete( io_deptno IN OUT dept.deptno%TYPE, io_dname IN OUT dept.dname%TYPE, io_loc IN OUT dept.loc%TYPE, io_ignore_discard_flag IN OUT BOOLEAN) RETURN BOOLEAN IS vRowCount NUMBER := 0; BEGIN ------------------------------------------------------------------------ See if the row exists based on the primary key (deptno). -- This finds rows that have been updated at this site. ----------------------------------------------------------------------SELECT count(*) INTO vRowCount FROM dept

346

Oracle Distributed Systems WHERE

deptno = io_deptno;

------------------------------------------------------------------------ If the record exists, delete it, and return success; otherwise, put -- the info from the passed parameters row in the DEPT_DEL_ERR table. ----------------------------------------------------------------------IF vRowCount = 1 THEN DELETE FROM dept WHERE deptno = io_deptno; ELSE INSERT INTO dept_del_err( deptno, dname, loc, timestamp, username ) VALUES (io_deptno, io_dname, io_loc, sysdate, user ); END IF; COMMIT; RETURN (TRUE); END resolve_dept_delete; / Not e t hat t he param et ers t o t his funct ion call are t he colum ns of t he DEPT t able and t hat t hey are all I N OUT param et ers; delet e handlers m ust accept all colum ns as param et ers, and t hey all m ust be in I N OUT m ode. You will also not ice t hat t his funct ion always ret urns TRUE. There is no way t hat delet es on t his t able will fail t o replicat e, but t he DBA st ill has t o m onit or t he DEPT_DEL_ERR t able for errors. Obviously, your applicat ion's requirem ent s m ay dict at e different behavior. To designat e RESOLVE_DEPT_DELETE as t he handler for t he DEPT t able, you m ust quiesce t he replicat ion group: EXECUTE dbms_repcat.suspend_master_activity('MOSS') The required procedure calls t o m ake RESOLVE_DEPT_DELETE t he delet e conflict handler for t he DEPT t able are as follows: -- Make RESOLVE_DEPT_DELETE a replicated object. EXECUTE dbms_repcat.create_master_repobject( sname => 'CDYE', oname => 'RESOLVE_DEPT_DELETE',type => 'FUNCTION', use_existing_object => FALSE, gname => 'CDYE') -- Designate RESOLVE_DEPT_DELETE as the DELETE handler for DEPT. EXECUTE dbms_repcat.add_delete_resolution( sname => 'CDYE', -

347

Oracle Distributed Systems oname sequence_no parameter_column_name function_name comment

=> => => => =>

'DEPT', 1, 'DEPTNO, DNAME, LOC', 'RESOLVE_DEPT_DELETE', 'Added on '|| sysdate )

-

-- Generate replication support for the function. EXECUTE dbms_repcat.generate_replication_package( sname => 'CDYE', oname => 'RESOLVE_DEPT_DELETE') Because of t he com plicat ions of avoiding and resolving delet e conflict s, t he best policy is not t o perform delet es at all. I nst ead, include a STATUS field in your replicat ed t ables t hat designat es a row as delet ed. This way, your applicat ion only insert s and updat es records. Conflict avoidance and resolut ion for insert s and updat es are significant ly easier t o im plem ent .

1 5 .3 .2 Lim it a t ion s of N ULL Va lu e s in Con flict Re solu t ion When you designat e one of t he built - in conflict resolut ion m et hods wit h your t able, such as Sit e Priorit y, Oracle depends on t he values in t he relevant colum ns and assum es t hat t hese colum ns are NOT NULL. I f, for exam ple, t he global_nam e field used for Sit e Priorit y is NULL when t he conflict handler execut es, t he conflict will go unresolved and Oracle will m ake an ent ry in t he DEFERROR dat a dict ionary view. The reason for t his rest rict ion should be rat her obvious: NULL values cannot be used in com parisons! The m oral is t hat you should design your replicat ed t ables so t hat colum ns used in conflict resolut ion always have t he NOT NULL at t ribut e.

1 5 .3 .3 Re fe r e n t ia l I n t e gr it y Viola t ion s a n d Con flict Re solu t ion As discussed earlier, t here is a dist inct ion bet ween dat a int egrit y and dat a convergence, and t he m eans of ensuring bot h are also dist inct . Dat a int egrit y is enforced by m echanism s t hat are built int o t he RDBMS, such as referent ial int egrit y const raint s. Unlike dat a int egrit y, which Oracle guarant ees if you use t hese m echanism s, t here is no m echanism t o guarant ee dat a convergence. I nt egrit y const raint s are neit her designed for nor int ended t o enforce dat a int egrit y bet ween dat abases. And it is possible t hat a replicat ed t ransact ion m ay violat e an int egrit y const raint at t he dest inat ion dat abase, even t hough it was perm it t ed locally. The best policy is t o m aint ain ident ical int egrit y const raint s am ong all sit es part icipat ing in replicat ion and t o replicat e t ables whose prim ary keys are foreign keys of any replicat ed t able. For exam ple, if you have a COUNTRY t able whose prim ary key ( e.g., count ry_code) is a foreign key t o t he count ry_code in your replicat ed ADDRESS t able, t hen you should also replicat e t he COUNTRY t able. Do not be fooled by claim s such as " The COUNTRY t able never changes; we don't need t o

348

Oracle Distributed Systems worry about replicat ing it ." Such assum pt ions invariably lead t o conflict s, which are quit e easy t o avoid.

1 5 .3 .4 Con flict s Ar isin g fr om Pr oce du r a l Re plica t ion Oracle does not provide any m eans of resolving conflict s t hat arise from procedural replicat ion. All resolut ion m et hods are for row- level replicat ion. Therefore, any replicat ed procedures you writ e m ust include logic t o det ect and resolve conflict s. To avoid conflict s in your replicat ed procedures, Oracle Corporat ion recom m ends t hese guidelines: • • •

• • •

Disable row- level replicat ion in t he procedure by calling t he DBMS_REPUTI L.REPLI CATI ON_OFF procedure. Be sure t o re- enable replicat ion by calling DBMS_REPUTI L.REPLI CATI ON_ON before t he procedure exit s. Do not call m ore t han one replicat ed procedure at a t im e. Replicat ed procedures m ust be wit hin a package t hat does not cont ain any funct ions. Do not reference rem ot e obj ect s in a replicat ed procedure. Avoid references t o values det erm ined locally, such as SYSDATE. I f you are using t oken passing, do not change t he ownership of rows.

1 5 .4 H ow Or a cle D e t e ct s a n d Re solve s Con flict s The package procedure t able_nam e$RP is t he package t hat det ect s conflict s as it applies DML at t he dest inat ion sit e. Generat ing replicat ion support for a t able creat es t his package. As an exam ple, generat ing replicat ion support for t he t able DEPT produces t he package DEPT$RP ( shown in Exam ple 15.1) , which cont ains a procedure for each of t he t hree t ypes of DML: REP_DELETE, REP_I NSERT, and REP_UPDATE. Each of t hese procedures passes except ions on t o t he appropriat e conflict resolut ion handler. The boldfaced areas show how except ions are passed t o conflict handlers. As you can see, relat ively few except ions have a chance t o be resolved: NO_DATA_FOUND for delet es ( line 25) and updat es ( line 135) and DUP_VAL_ON_I NDEX for insert s ( line 68) and updat es ( line 155) . Any ot her except ions, such as VALUE_ERROR, result in ent ries in t he DEFERROR dat a dict ionary view.

Ex a m ple 1 5 .1 . D e t e ct in g Con flict s w it h D EPT$ RP 1 package body "DEPT$RP" as 2 procedure rep_delete( 3 "DEPTNO1_o" IN NUMBER, 4 "DNAME2_o" IN VARCHAR2, 5 "LOC3_o" IN VARCHAR2, 6 site_name IN VARCHAR2, 7 propagation_flag IN CHAR) is 8 begin 9 if propagation_flag = 'N' then 10 dbms_reputil.replication_off; 11 end if;

349

Oracle Distributed Systems 12 dbms_reputil.rep_begin; 13 dbms_reputil.global_name := site_name; 14 delete from "DEPT" 15 where ("DEPTNO1_o" = "DEPTNO" 16 and (("DNAME2_o" = "DNAME") or ("DNAME2_o" is NULL and "DNAME" is NULL)) 17 and (("LOC3_o" = "LOC") or ("LOC3_o" is NULL and "LOC" is NULL))); 18 if sql%rowcount = 0 then 19 raise no_data_found; 20 elsif sql%rowcount > 1 then 21 raise too_many_rows; 22 end if; 23 dbms_reputil.rep_end; 24 exception 25 when no_data_found then 26 begin 27 if not "DEPT$RR".delete_conflict_handler( 28 "DEPTNO1_o", 29 "DNAME2_o", 30 "LOC3_o", 31 site_name, 32 propagation_flag) then 33 dbms_reputil.rep_end; 34 raise; 35 end if; 36 dbms_reputil.rep_end; 37 exception 38 when others then 39 dbms_reputil.rep_end; 40 raise; 41 end; 42 when others then 43 dbms_reputil.rep_end; 44 raise; 45 end rep_delete; 46 procedure rep_insert( 47 "DEPTNO1_n" IN NUMBER, 48 "DNAME2_n" IN VARCHAR2, 49 "LOC3_n" IN VARCHAR2, 50 site_name IN VARCHAR2, 51 propagation_flag IN CHAR) is 52 begin 53 if propagation_flag = 'N' then 54 dbms_reputil.replication_off; 55 end if; 56 dbms_reputil.rep_begin; 57 dbms_reputil.global_name := site_name; 58 insert into "DEPT" ( 59 "DEPTNO", 60 "DNAME", 61 "LOC") 62 values ( 63 "DEPTNO1_n", 64 "DNAME2_n", 65 "LOC3_n"); 66 dbms_reputil.rep_end;

350

Oracle Distributed Systems 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123

exception when dup_val_on_index then begin if not "DEPT$RR".unique_conflict_insert_handler( "DEPTNO1_n", "DNAME2_n", "LOC3_n", site_name, propagation_flag, SQLERRM) then dbms_reputil.rep_end; raise; end if; dbms_reputil.rep_end; exception when others then dbms_reputil.rep_end; raise; end; when others then dbms_reputil.rep_end; raise; end rep_insert; procedure rep_update( "DEPTNO1_o" IN NUMBER, "DEPTNO1_n" IN NUMBER, "DNAME2_o" IN VARCHAR2, "DNAME2_n" IN VARCHAR2, "LOC3_o" IN VARCHAR2, "LOC3_n" IN VARCHAR2, site_name IN VARCHAR2, propagation_flag IN CHAR) is begin if propagation_flag = 'N' then dbms_reputil.replication_off; end if; dbms_reputil.rep_begin; dbms_reputil.global_name := site_name; update "DEPT" set "DEPTNO" = "DEPTNO1_n", "DNAME" = decode("DNAME2_o", "DNAME2_n", "DNAME", null, nvl("DNAME2_n", "DNAME"), "DNAME2_n"), "LOC" = decode("LOC3_o", "LOC3_n", "LOC", null, nvl("LOC3_n", "LOC"), "LOC3_n") where (((1 = 1 and ("DNAME2_o" = "DNAME2_n" or ("DNAME2_o" is null and "DNAME2_n" is null)) and ("LOC3_o" = "LOC3_n" or ("LOC3_o" is null and "LOC3_n" is null)))) or (1 = 1 and ("DNAME2_o" = "DNAME" or

351

Oracle Distributed Systems 124 ("DNAME2_o" is null and "DNAME" is null)) and 125 ("LOC3_o" = "LOC" or 126 ("LOC3_o" is null and "LOC" is null)))) 127 and "DEPTNO1_o" = "DEPTNO"; 128 if sql%rowcount = 0 then 129 raise no_data_found; 130 elsif sql%rowcount > 1 then 131 raise too_many_rows; 132 end if; 133 dbms_reputil.rep_end; 134 exception 135 when no_data_found then 136 begin 137 if not "DEPT$RR".update_conflict_handler( 138 "DEPTNO1_o", 139 "DEPTNO1_n", 140 "DNAME2_o", 141 "DNAME2_n", 142 "LOC3_o", 143 "LOC3_n", 144 site_name, 145 propagation_flag) then 146 dbms_reputil.rep_end; 147 raise; 148 end if; 149 dbms_reputil.rep_end; 150 exception 151 when others then 152 dbms_reputil.rep_end; 153 raise; 154 end; 155 when dup_val_on_index then 156 begin 157 if not "DEPT$RR".unique_conflict_update_handler( 158 "DEPTNO1_o", 159 "DEPTNO1_n", 160 "DNAME2_o", 161 "DNAME2_n", 162 "LOC3_o", 163 "LOC3_n", 164 site_name, 165 propagation_flag, 166 SQLERRM) then 167 dbms_reputil.rep_end; 168 raise; 169 end if; 170 dbms_reputil.rep_end; 171 exception 172 when others then 173 dbms_reputil.rep_end; 174 raise; 175 end; 176 when others then 177 dbms_reputil.rep_end; 178 raise; 179 end rep_update; 180 end "DEPT$RP";

352

Oracle Distributed Systems

1 5 .5 Colum n Gr oups a nd Pr ior it y Gr oups Colum n groups and priorit y groups provide int erfaces t o a variet y of built - in conflict resolut ion t echniques and t he easiest way t o configure your applicat ion t o resolve conflict s aut om at ically. Let 's look at t hem one at a t im e.

1 5 .5 .1 Colu m n Gr ou ps A colum n group is a set of one or m ore colum ns associat ed wit h a single conflict resolut ion m et hod. A colum n cannot belong t o m ore t han one colum n group, and colum ns t hat are not explicit ly assigned t o a colum n group are m em bers of a shadow colum n group, which Oracle creat es by default and which uses t he default conflict resolut ion m et hods. For exam ple, suppose t hat you want t o define a colum n group for t he EMPLOYEES t able described in t he following t able: Column Name

Type

EMPLOYEE_I D

NUMBER( 10)

LAST_NAME

VARCHAR2( 30)

FI RST_NAME

VARCHAR2( 20)

SOCI AL_SECURI TY_NO

VARCHAR2( 11)

MARI TAL_STATUS

VARCHAR2( 1)

HOME_PHONE

VARCHAR2( 12)

PERS_GLOBAL_NAME

VARCHAR2( 30)

PERS_TI MESTAMP

DATE

MANAGER

NUMBER( 3)

DEPT

NUMBER( 3)

SAL_GRADE

NUMBER( 3)

SENI ORI TY

VARCHAR2( 10)

PAYROLL_GLOBAL_NAME

VARCHAR2( 30)

PAYROLL_TI MESTAMP

DATE

Use t he procedure DBMS_REPCAT.MAKE_COLUMN_GROUP t o define a colum n group for fields t hat t he personnel sit e m aint ains ( i.e., LAST_NAME, FI RST_NAME, SOCI AL_SECURI TY_NO, MARI TAL_STATUS, HOME_PHONE) . The applicat ion records inform at ion about changes t o t hese fields in PERS_GLOBAL_NAME and PERS_TI MESTAMP. EXECUTE dbms_repcat.make_column_group( gname => 'HR', oname => 'EMPLOYEES', column_group => 'CG_EMP_PERSONNEL', list_of_column_names => 'LAST_NAME, FIRST_NAME, SOCIAL_SECURITY_NUM, MARITAL_STATUS, HOME_PHONE, PERS_GLOBAL_NAME, PERS_TIMESTAMP' )

353

Oracle Distributed Systems To add updat e conflict resolut ion t o t his colum n group based on t he Lat est Tim est am p t echnique and a backup resolut ion m et hod based on t he Overwrit e t echnique, m ake t hese calls: EXECUTE dbms_repcat.add_update_resolution( sname => 'HR', oname => 'EMPLOYEES', column_group => 'CG_EMP_PERSONNEL', sequence_no => 1, method => 'LATEST TIMESTAMP', parameter_column_name => 'PERS_TIMESTAMP', comment => 'Method 1 added on '

|| sysdate);

EXECUTE dbms_repcat.add_update_resolution( sname => 'HR', oname => 'EMPLOYEES', column_group => 'CG_EMP_PERSONNEL', sequence_no => 2, method => 'OVERWRITE', parameter_column_name => '*', comment => 'Method 2 added on '

|| sysdate);

As wit h any ot her m odificat ions t o replicat ed obj ect s, you m ust add colum n groups from t he m ast er definit ion sit e when t he environm ent is quiesced. You m ust also regenerat e replicat ion support for any t able for which you m odify a colum n group: EXECUTE dbms_repcat.generate_replication_support( sname => 'HR', oname => 'EMPLOYEES', type => 'TABLE' )

-

Colum n groups provide a m eans t o assign different resolut ion t echniques t o different t ypes of dat a; num eric t echniques for num eric dat a, t im est am p t echniques for dat e fields, and so on. I t also allows you t o group relat ed fields, such as t he com ponent s of an address. Dividing t he fields of a t able int o colum n groups raises t he possibilit y t hat t he " resolved" dat a for a single row m ay cont ain values from different sit es. I n t he EMPLOYEES t able exam ple, we could define a second colum n group cont aining t he fields MANAGER, DEPT, SALGRADE, SENI ORI TY, PERS_GLOBAL_NAME, and PERS_TI MESTAMP. One sit e could updat e MARI TAL_STATUS, and anot her could updat e SAL_GRADE, and t he result ing row would be t he com binat ion of t he t wo updat es. Since dat a can be m erged t his way, it is vit al t o keep relat ed colum ns in t he sam e colum n group; you would not want t o put FI RST_NAME in one colum n group and LAST_NAME in anot her.

1 5 .5 .1 .1 H ow t h e colu m n grou p r e solu t ion m e ch a n ism w or k s Oracle det ect s conflict s by scanning every field in every colum n group, com paring t he old value from t he originat ion sit e wit h t he current value at t he dest inat ion sit e. I f Oracle det ect s a difference ( because, for exam ple, a change at t he dest inat ion sit e had not yet been propagat ed) , it invokes t he conflict resolut ion t echnique( s) for t he

354

Oracle Distributed Systems corresponding colum n group. I f t he colum n group has m ore t han one resolut ion t echnique ( as it should) , t hey are called in descending priorit y order unt il t he conflict is resolved. The shadow colum n group t hat cont ains colum ns t hat have not been explicit ly assigned t o any group is scanned last . I f all conflict s are resolved, t he resolved dat a is com m it t ed. Ot herwise, t he t ransact ion is writ t en t o t he DEFERROR dat a dict ionary view.

1 5 .5 .1 .2 API s for colu m n gr ou ps The following list s t he API s t hat m anipulat e colum n groups: DBMS_REPCAT.DEFI NE_COLUMN_GROUP Creat es a colum n group wit h no m em ber colum ns. DBMS_REPCAT.DROP_COLUMN_GROUP Drops a colum n group. DBMS_REPCAT.ADD_GROUPED_COLUMN Adds a colum n t o an exist ing colum n group. DBMS_REPCAT.DROP_GROUPED_COLUMN Rem oves a colum n from a colum n group. DBMS_REPCAT.MAKE_COLUMN_GROUP Creat es a colum n group and adds colum ns t o it . Appendix A, cont ains a com plet e reference t o t hese API s.

1 5 .5 .2 Pr ior it y Gr ou ps Priorit y groups rank a finit e list of possible values for a colum n so t hat , in t he event of a conflict , Oracle updat es t he dest inat ion t able if and only if t he new value from t he originat ing sit e has a higher priorit y. This m et hod is designed t o work wit h applicat ions t hat use workflow part it ioning. Unlike colum n groups, which are defined at t he t able level, priorit y groups can be used by m ult iple t ables. A sit e priorit y is a priorit y group in which t he range of values for a colum n is t he list of global nam es of dat abases part icipat ing in t he replicat ion. I f you choose t o im plem ent priorit y groups, you m ust select a priorit y colum n, and you m ust rank all pot ent ial values of t hat colum n. Consider t he SENI ORI TY colum n of t he EMPLOYEES t able. Suppose t hat it s range of possible values is PROBATI ON, REGULAR, and TENURED. Assum ing t hat t his organizat ion never dem ot es an em ployee's seniorit y, you could define a priorit y group t o enforce t he workflow of orders from PROBATI ON t o REGULAR t o TENURED:

355

Oracle Distributed Systems -- Create a column group which includes the SENIORITY column. EXECUTE dbms_repcat.make_column_group( sname => 'HR', oname => 'EMPLOYEES', column_group => 'CG_HR', list_of_column_names => 'MANAGER, DEPT, SALGRADE, SENIORITY, PERS_GLOBAL_NAME, PERS_TIMESTAMP') -- Define a priority group using the SENIORITY column. EXECUTE dbms_repcat.define_priority_group( gname => 'HR', pgroup => 'SENIORITY', datatype => 'VARCHAR2', fixed_length => NULL, comment => 'SENIORITY created on ' || sysdate) -- Associate priorities with the various possible values. the -- priority, the higher the precedence. EXECUTE dbms_repcat.add_priority_varchar2( gname => 'HR', pgroup => 'SENIORITY', value => 'PROBATION', priority => 1 ) EXECUTE dbms_repcat.add_priority_varchar2( gname => 'HR', pgroup => 'SENIORITY', value => 'REGULAR', priority => 2 )

-

EXECUTE dbms_repcat.add_priority_varchar2( gname => 'HR', pgroup => 'SENIORITY', value => 'TENURED', priority => 3 )

-

EXECUTE dbms_repcat.generate_replication_support( sname => 'HR', oname => 'EMPLOYEES', type => 'TABLE' )

The higher

-

As usual, you m ust perform t hese st eps from t he m ast er definit ion sit e while t he environm ent is quiesced. A priorit y group is a very powerful resolut ion m et hod because it guarant ees dat a convergence if t he priorit y of t he colum n is always increasing, which is why it is perfect for applicat ions t hat can use workflow part it ioning.

1 5 .5 .3 Sit e Pr ior it y A sit e priorit y is essent ially a priorit y group in which t he priorit y colum n holds t he global nam e of t he dat abase t hat updat es t he dat a. The following procedure calls set up sit e priorit ies for t hree locat ions part icipat ing in a replicat ed environm ent : ALBANY.COM, BUFFALO.COM, and CLEVELAND.COM:

356

Oracle Distributed Systems -- Define the site priority. EXECUTE dbms_repcat.define_site_priority( gname => 'HR', name => 'HR_SITES', comment => 'Site Priority define on ' || sysdate) -- Add the sites. -- ALBANY.COM has highest priority, CLEVELAND.COM has lowest. EXECUTE dbms_repcat.add_priority_site( gname => 'HR', name => 'HR_SITES', site => 'ALBANY.COM', priority => 3) EXECUTE dbms_repcat.add_priority_site( gname => 'HR', name => 'HR_SITES', site => 'BUFFALO.COM', priority => 2)

-

EXECUTE dbms_repcat.add_priority_site( gname => 'HR', name => 'HR_SITES', site => 'CLEVELAND.COM', priority => 1)

-

You would t ypically use sit e priorit y as a backup resolut ion m et hod t o act as a final t iebreaker t hat is invoked when ot her m et hods fail t o resolve t he conflict . I f each of your sit es is associat ed wit h an event or st at us in t he workflow m odel, t hen you should use priorit y groups inst ead of sit e priorit y t o effect dat a convergence. As Table 15.2 illust rat es, sit e priorit y does not guarant ee dat a convergence wit h m ore t han t wo m ast er sit es.

Table 15.2. How Site Priority Can Fail with More Than Two Sites ALBANY.COM

BUFFALO.COM

CLEVELAND.COM

Time Priority = 3

Priority = 2

Priority = 1

12: 00

signal = GREEN

signal = GREEN

signal = GREEN

12: 05

signal = GREEN

signal = GREEN

sit e down

12: 10

signal = YELLOW

signal = GREEN

sit e down

12: 15

signal = YELLOW

signal = YELLOW

sit e down

12: 20

signal = YELLOW

signal = RED

signal = GREEN

12: 25

signal = YELLOW

signal = RED

signal = RED

12: 30

signal = YELLOW

signal = RED

signal = YELLOW

12: 35

signal = RED

signal = RED

signal = YELLOW

Consider t he t im e line: • •

12: 00: All sit es are in agreem ent . 12: 05: CLEVELAND.COM goes down; all sit es are st ill in agreem ent .

357

Oracle Distributed Systems •

•

•

• • •

12: 10: ALBANY.COM updat es signal t o YELLOW; CLEVELAND.COM is st ill down. 12: 15: BUFFALO.COM receives and applies updat e from ALBANY.COM; CLEVELAND.COM is st ill down. 12: 20: BUFFALO.COM updat es signal t o RED; CLEVELAND.COM com es back online. 12: 25: CLEVELAND.COM receives t he updat e from BUFFALO.COM. Sit e Priorit y conflict resolut ion gives precedence t o BUFFALO.COM's updat e, so CLEVELAND.COM set s signal t o RED. 12: 30: CLEVELAND.COM receives an updat e from ALBANY.COM ( from 12: 10) . The sit e priorit y conflict gives precedence t o ALBANY.COM's updat e, so CLEVELAND.COM set s signal t o YELLOW. 12: 35 ALBANY.COM receives updat e from BUFFALO.COM and applies it wit hout any conflict .

So, aft er all t ransact ions have been replicat ed, t here are no unresolved conflict s, but t he dat a does not agree! Of course, if ALBANY.COM or BUFFALO.COM updat es t his part icular row at som e lat er dat e, t he dat a could converge once again. Unfort unat ely for CLEVELAND.COM, no such updat e is im m inent ; you cert ainly cannot depend on addit ional updat es t o at t ain dat a convergence. Sim ilar risks of dat a divergence exist for t he Earliest Tim est am p resolut ion m et hod and for priorit y groups t hat do not follow a workflow m odel. This exam ple would have result ed in dat a convergence if we had used priorit y groups, assum ing t hat t he colum n values always progress from GREEN t o YELLOW t o RED.

1 5 .5 .3 .1 API s for pr ior it y gr ou ps a n d sit e pr ior it y The DBMS_REPCAT API s for priorit y groups and sit e priorit y are sum m arized here. Possible values for dat at ype are CHAR, VARCHAR2, NUMBER, DATE, and RAW. DBMS_REPCAT.DEFI NE_PRI ORI TY_GROUP Creat es a priorit y group. DBMS_REPCAT.DROP_PRI ORI TY_GROUP Drops a priorit y group. DBMS_REPCAT.ADD_PRI ORI TY_dat at ype Adds a new value of t ype dat at ype t o an exist ing priorit y group. DBMS_REPCAT.ALTER_PRI ORI TY_dat at ype Changes t he priorit y of an exist ing colum n value. DBMS_REPCAT.DROP_PRI ORI TY Drops a m em ber of a priorit y group wit h a specified priorit y.

358

Oracle Distributed Systems DBMS_REPCAT.DROP_PRI ORI TY_dat at ype Drops a m em ber of a priorit y group for a specific colum n. DBMS_REPCAT.DROP_SI TE_PRI ORI TY Drops an exist ing sit e priorit y group. DBMS_REPCAT.ALTER_SI TE_PRI ORI TY_SI TE Changes t he sit e associat ed wit h a specific priorit y value. DMBS_REPCAT.ALTER_SI TE_PRI ORI TY Changes t he priorit y of a specific sit e. DMBS_REPCAT.DROP_SI TE_PRI ORI TY_SI TE Drops a sit e from t he sit e priorit y group. Appendix A cont ains a com plet e reference t o t hese API s.

1 5 .6 Th e Bu ilt - in M e t h ods Oracle supplies 11 built - in conflict resolut ion m et hods ( see Table 15.3) , which you can designat e for colum n groups and priorit y groups. You will not ice t hat dat a convergence for replicat ed environm ent s of t hree or m ore sit es is very challenging t o obt ain.

Table 15.3. Built-in Conflict Resolution Methods Method

DML Supported

>1 Master?

Convergence Requirements

Minim um Value

UPDATE

Yes

Always decreasing or < 3 m ast ers

Maxim um Value

UPDATE

Yes

Always increasing or < 3 m ast ers

Earliest Tim est am p

UPDATE

Yes

< 3 m ast ers

Lat est Tim est am p

UPDATE

Yes

Always increasing or < 3 m ast ers

Overwrit e Updat e

UPDATE

No

< 2 m ast ers

Discard Updat e

UPDATE

No

< 2 m ast ers

Average

UPDATE

No

< 2 m ast ers

Addit ive

UPDATE

Yes

Always converges

Append Sit e Nam e

I NSERT

Yes

Never guarant eed t o converge

Append Sequence

I NSERT

Yes

Never guarant eed t o converge

I gnore I nsert / Discard

I NSERT

Yes

Never guarant eed t o converge

359

Oracle Distributed Systems

I nsert For t he m ost part , t hese t echniques are self- explanat ory, but cert ain peculiarit ies of t heir usage warrant furt her explanat ion.

1 5 .6 .1 M in im u m Va lu e / M a x im u m Va lu e The Minim um Value and Maxim um Value m et hods are appropriat e for sit es wit h any num ber of m ast ers and can be used wit h any replicat able dat at ype. Dat a is always guarant eed t o converge wit h t wo m ast ers and wit h t hree m ast ers if values are always decreasing ( for Minim um Value) or always increasing ( for Maxim um Value) . I f t he dat a from t he originat ing sit e and dest inat ion sit e are t he sam e, t hese resolut ion t echniques will fail. Therefore, you should always provide a backup m et hod, such as sit e priorit y t o handle t his sit uat ion.

1 5 .6 .2 Ea r lie st Tim e st a m p/ La t e st Tim e st a m p The Earliest Tim est am p and Lat est Tim est am p t echniques are basically t he sam e as t he Minim um and Maxim um Value t echniques, except t hat t hey only apply t o DATE colum ns. However, t hey do int roduce t he issue of differing t im e zones. As I m ent ioned earlier, Oracle st rongly recom m ends put t ing syst em s in m ult iple t im e zones on Greenwich Mean Tim e ( GMT) if you plan t o use t im est am p- based conflict resolut ion, since Oracle's DATE dat at ype does not have a t im e zone com ponent . The Lat est Tim est am p m et hod is guarant eed t o converge for any num ber of m ast er sit es, alt hough Earliest Tim est am p is not . Earliest Tim est am p does not necessarily converge because such values are not necessarily always decreasing, whereas Lat est Tim est am ps m ust always be increasing. As wit h t he Minim um and Maxim um Value t echniques, you are st rongly encouraged t o supply a backup resolut ion m et hod t o break t ies t hat occur when t he t im est am ps are equal. Not e t hat t he Earliest and Lat est Tim est am p m et hods m ay not be appropriat e for dat a t hat can be updat ed at m ult iple sit es, since t he " correct " value m ay not necessarily be associat ed wit h t he earliest ( or lat est ) t im est am p.

1 5 .6 .3 Ove r w r it e Upda t e / D isca r d Upda t e The Overwrit e Updat e and Discard Updat e m et hods of conflict resolut ion are prim arily int ended for environm ent s wit h a single m ast er sit e and several snapshot sit es. These m et hods eit her overwrit e or discard dat a at eit her t he originat ion or t he dest inat ion and do not guarant ee convergence in a m ult i- m ast er environm ent . Specifically, t he Overwrit e Updat e m et hod sim ply replaces t he dat a at t he dest inat ion wit h t he new originat ing sit e's dat a, and t he Discard Updat e m et hod does not hing at all wit h t he updat e. I f you choose t o use t he Overwrit e Updat e or Discard Updat e conflict resolut ion t echniques in a m ult i- m ast er environm ent , you should do so in conj unct ion wit h a not ificat ion facilit y t o alert t he DBA.

360

Oracle Distributed Systems

1 5 .6 .4 Ave r a ge / Addit ive The Addit ive and Average m et hods work wit h num eric dat a only. The Addit ive m et hod adds t he delt a at t he originat ing sit e t o t he dest inat ion sit e, while t he Average m et hod averages t he new value from t he originat ing sit e wit h t he current value at t he dest inat ion sit e. The Addit ive m et hod always converges, and t he Average m et hod converges wit h t wo or fewer m ast er sit es.

1 5 .6 .5 Appe n d Sit e N a m e / Appe n d Se qu e n ce The Append Sit e Nam e and Append Sequence t echniques are int ended t o resolve insert s t hat result in unique const raint violat ions. Alt hough appending a global nam e or sequence num ber t o t he violat ed key m ay circum vent t he conflict , it does not guarant ee dat a convergence. These m et hods m ay be appropriat e for sit uat ions in which dat a availabilit y is m ore im port ant t han dat a accuracy. These t echniques should also be used in conj unct ion wit h a not ificat ion facilit y.

1 5 .6 .6 I gn or e I n se r t / D isca r d I n se r t The I gnore I nsert and Discard I nsert t echniques are also used t o resolve unique const raint violat ions on insert s. The I gnore I nsert m et hod does not hing wit h t he updat e, and t he Discard I nsert m et hod delet es t he row from t he originat ing sit e. Again, t hese m et hods do not guarant ee dat a convergence and should be used only in conj unct ion wit h a not ificat ion facilit y.

1 5 .7 W r it in g You r Ow n Con flict Re solu t ion H a n dle r I f t he conflict resolut ion t echniques t hat Oracle supplies do not m eet your requirem ent s, you are free t o writ e your own rout ine. An exam ple of such a rout ine is t he one wit h t he delet e conflict handler shown earlier in t his chapt er. When you sit down t o writ e your conflict resolut ion funct ion, it is probably easiest t o begin wit h t he code t hat Oracle generat es for t he corresponding built - in resolut ion t echnique, which you can ext ract from t he DBA_SOURCE dat a dict ionary view. You should also consider building a not ificat ion m et hod. Oracle's requirem ent s for user- defined conflict resolut ion t echniques are as follows: • • • • • • • • •

Use PL/ SQL. Ret urn Boolean TRUE if successful, FALSE ot herwise. Updat e handlers require Old, New, and Current colum n values for colum ns specified in t he param et er_colum n_nam e param et er of DBMS_REPCAT.ADD_UPDATE_RESOLUTI ON. Delet e handlers require Old colum n values for t he ent ire row. Uniqueness handlers require New values for colum ns specified in t he param et er_colum n_nam e param et er of DBMS_REPCAT.ADD_UPDATE_RESOLUTI ON. Do not perform DDL ( i.e., t hrough dynam ic SQL) . Do not perform t ransact ion cont rol ( e.g., ROLLBACK) . Do not perform session cont rol ( e.g., ALTER SESSI ON...) . Do not perform syst em cont rol ( e.g. ALTER SYSTEM...) .

361

Oracle Distributed Systems When you are ready t o add your conflict resolut ion funct ion t o t he t able, follow t hese st eps: 1. Quiesce t he replicat ion group. 2. Call DBMS_REPCAT.CREATE_MASTER_REPOBJECT t o m ake your funct ion a replicat ed obj ect . 3. Call DBMS_REPCAT.ADD_conflict t ype_RESOLUTI ON ( where t ype m ay be UPDATE, DELETE, or UNI QUE) t o associat e your funct ion wit h t he t able. 4. Call DBMS_REPCAT.GENERATE_REPLI CATI ON_PACKAGE t o generat e replicat ion support for your funct ion. 5. Call DBMS_REPCAT.RESUME_MASTER_ACTI VI TY t o resum e replicat ion.

362

Oracle Distributed Systems

Pa r t I I I : Appe n dix e s This part of t he book cont ains t he following appendixes: • •

Appendix A, is t he API reference; it cont ains sum m aries of all specificat ions, param et ers, except ions, and rest rict ions for t he procedures and funct ions available t hrough t he Oracle built - in packages used wit h dist ribut ed syst em s. Appendix B, cont ains t he code for a variet y of script s m ent ioned in t his book.

363

Oracle Distributed Systems

364

Oracle Distributed Systems

Appe n dix A. Bu ilt - in Pa ck a ge s for D ist r ibu t e d Syst e m s This appendix sum m arizes t he Applicat ion Program m ing I nt erface ( API ) calls t o t he procedures and funct ions in t he various Oracle built - in packages t hat support dist ribut ed syst em s. I t covers t he packages list ed in Table A. For each package, I ’ll describe briefly how t o find t he package and how t o call each of it s program s. I ’ll also show except ions and ot her nonprogram elem ent s. For each procedure and funct ion provided in t he package, I ’ll show, in a quick- reference form at , t he specificat ions, param et ers, except ions, and any rest rict ions.

I n addit ion t o t he dist ribut ed syst em packages described here, Oracle provides m any ot her built - in packages ( e.g., DBMS_SQL and DBMS_UTI LI TY) . For a full discussion of all of t he packages, see Oracle Built in Packages by St even Feuerst ein, Charles Dye, and John Beresniewicz ( O’Reilly & Associat es, 1998) .

Table A. Built-in Packages for Distributed Systems Package

Description

DBMS_DEFER

Builds deferred calls.

DBMS_DEFER_QUERY

Provides access t o param et ers passed t o deferred calls, prim arily for diagnost ic purposes.

DBMS_DEFER_SYS

Perform s adm inist rat ive t asks such as scheduling, execut ing, and delet ing queued t ransact ions.

DBMS_OFFLI NE_OG

I nst ant iat es sit es—t hat is, let s you export dat a from an exist ing m ast er sit e and im port it int o t he new m ast er sit e.

Allows you t o inst ant iat e snapshot s wit hout having t o run t he CREATE SNAPSHOT com m and over t he net work. DBMS_OFFLI NE_SNAPSHOT This package is part icularly useful if you need t o inst ant iat e ext rem ely large snapshot s. DBMS_RECTI FI ER_DI FF

Com pares t he replicat ed t ables at t wo m ast er sit es and allows you t o synchronize t hem if t hey are different .

DBMS_REFRESH

Adm inist ers snapshot groups at a snapshot sit e.

DBMS_REPCAT

Perform s a num ber of replicat ion, adm inist rat ion, snapshot , and conflict resolut ion operat ions.

DBMS_REPCAT_ADMI N

Creat es adm inist rat or account s for replicat ion.

DBMS_REPCAT_AUTH

Grant s and revokes “ surrogat e SYS” privileges for an adm inist rat or account .

DBMS_REPUTI L

Enables and disables replicat ion at t he session level.

DBMS_SNAPSHOT

Let s you m aint ain snapshot s and snapshot logs.

365

Oracle Distributed Systems

A.1 D BM S_ D EFER: Bu ildin g D e fe r r e d Ca lls The DBMS_DEFER package queues deferred t ransact ions. These t ransact ions are t ypically rem ot e procedure calls ( RPCs) , but you can also defer procedure calls locally. The advanced replicat ion facilit ies use t his package t ransparent ly and ext ensively, but you can also access it direct ly for ot her purposes.

A.1 .1 H ow t h e Pa ck a ge I s Use d You queue procedure calls by calling t he TRANSACTI ON or CALL procedure. A call t o TRANSACTI ON is followed by one or m ore deferred RPCs, which are followed by a COMMI T. DBMS_DEFER can execut e procedures at rem ot e sit es under a highly privileged account , such as t he replicat ion adm inist rat or account . Therefore, EXECUTE privileges on DBMS_DEFER should not be widely grant ed. As a general rule, you should rest rict it t o DBA account s. I f you want t o provide end users wit h t he abilit y t o creat e t heir own deferred calls, you should creat e a cover package and grant EXECUTE on it t o end users or end user roles.

A.1 .2 I n st a lla t ion a n d Acce ss The DBMS_DEFER package is creat ed when t he Oracle dat abase is inst alled. The dbm sdefr.sql script ( found in t he built - in packages source direct ory) , cont ains t he source code for t his package’s specificat ion. This script is called by cat rep.sql, which m ust be run t o inst all t he advanced replicat ion packages. The script creat es t he public synonym DBMS_DEFER. EXECUTE privileges on DBMS_DEFER are not grant ed.

A.1 .3 D BM S_ D EFER Pr oce du r e s Procedure Name CALL

Description Defines a rem ot e procedure call.

COMMI T_WORK Com m it s deferred RPC t ransact ion. dat at ype_ARG

Adds param et er of specified dat at ype t o a deferred call; dat at ype m ay be CHAR, DATE, NUMBER, RAW, ROWI D, or VARCHAR2.

TRANSACTI ON Marks a t ransact ion as deferred.

A.1 .4 D BM S_ D EFER Ex ce pt ion s Exception Name

Number

Description

bad_param _t ype

– Param et er t ype does not m at ch act ual t ype. 23325

com m failure

– Rem ot e updat e failed due t o com m unicat ion failure. 23302

dbm s_defererror

– Generic int ernal errors. 23305

deferred_rpc_quiesce

– Dat abase is quiescing. 23326

execut iondisabled

–

Deferred RPC execut ion is disabled.

366

Oracle Distributed Systems

23354 m alform edcall

– Argum ent count m ism at ches, et c. 23304

m ixeddest

– Dest inat ions for t ransact ion not specified consist ent ly. 23301

param et erlengt h

– Param et er lengt h exceeds lim it s ( 2000 for 23323 CHAR/ VARCHAR, 255 for RAW) .

updat econflict

– Rem ot e updat e failed due t o conflict . 23303

A.1 .5 D BM S_ D EFER N on pr ogr a m Ele m e n t s I n t he following list , t he node_list _t elem ent is a PL/ SQL t able whose first ent ry is always placed in row 1. I t is filled sequent ially, wit h each subsequent ent ry placed in row node_list _t .last + 1. Element Type and Name

Description

CONSTANT arg_cset id_none ( Oracle8 only)

I nt ernal charact er set I D. Value = 0. I ncludes t ypes DATE, NUMBER, ROWI D, RAW, and BLOB.

CONSTANT arg_form _any ( Oracle8 only)

I nt ernal charact er set I D. Value = 4.

CONSTANT arg_form _im plicit ( Oracle8 only)

I nt ernal charact er set I D. Value = 1. I ncludes t ypes CHAR, VARCHAR2, and CLOB.

CONSTANT arg_form _nchar ( Oracle8 only)

I nt ernal charact er set I D. Value = 2. I ncludes t ypes NCHAR, NVARCHAR2, and NCLOB.

CONSTANT arg_form _none ( Oracle8 only)

I nt ernal charact er set I D. Value = 0. I ncludes t ypes DATE, NUMBER, ROWI D, RAW, and BLOB.

CONSTANT arg_t ype_blob ( Oracle8 only)

Used in arg_t ype colum n of def$_args t able. Value = 113.

CONSTANT arg_t ype_clob ( Oracle8 only)

Used in arg_t ype colum n of def$_args t able. Value = 112.

CONSTANT arg_t ype_bfil ( Oracle8 only)

Used in arg_t ype colum n of def$_args t able. Value = 114.

CONSTANT arg_t ype_cfil ( Oracle8 only)

Used in arg_t ype colum n of def$_args t able. Value = 115.

CONSTANT arg_t ype_num

Used in arg_t ype colum n of def$_args t able. Value = 2.

CONSTANT arg_t ype_char

Used in arg_t ype colum n of def$_args t able. Value = 96.

CONSTANT arg_t ype_varchar2

Used in arg_t ype colum n of def$_args t able. Value = 1.

CONSTANT arg_t ype_dat e

Used in arg_t ype colum n of def$_args t able. Value = 12.

CONSTANT arg_t ype_rowid

Used in arg_t ype colum n of def$_args t able. Value = 11.

CONSTANT arg_t ype_raw

Used in arg_t ype colum n of def$_args t able. Value = 23.

367

Oracle Distributed Systems

CONSTANT repcat _st at us_norm al

Signals norm al successful com plet ion. Value = 0.0.

TYPE node_list _t

Table of VARCHAR2( 128) .

D BM S_ D EFER.CALL

The CALL procedure queues an RPC t o t he dest inat ion specified in t he DEFDEFAULTDEST dat a dict ionary view. I t calls TRANSACTI ON aut om at ically if it is t he first call of a t ransact ion. I f you do not specify a value for t he nodes param et er, t he dest inat ion of t he RPC will be t he locat ions in t he dat a dict ionary view DEFDEFAULTDEST. PROCEDURE DBMS_DEFER.CALL (schema_name IN VARCHAR2, package_name IN VARCHAR2, proc_name IN VARCHAR2, arg_count IN NATURAL, {group_name IN VARCHAR2 := ''| nodes IN node_list_t});

Pa r a m e t e r s Parameter Name

Description

schem a_nam e Nam e of t he schem a queuing t he call. package_nam e Nam e of t he package cont aining t he procedure t hat is being queued. proc_nam e

Nam e of t he procedure being queued.

arg_count

Num ber of param et ers being passed t o t he procedure. You m ust have one call t o DBMS_DEFER.dat at ype_ARG for each param et er.

group_nam e

Opt ional. Reserved for int ernal use.

nodes

Opt ional. List of dest inat ion nodes ( global_nam es) where t he procedure is t o be execut ed. I f nodes are not specified, dest inat ions are det erm ined by t he list passed t o TRANSACTI ON.

Ex ce pt ion s Exception Name Number

Description

m alform edcall

– Num ber of argum ent s in t he call does not m at ch value of 23304 arg_count .

ORA- 23319

– The param et er is NULL, m isspelled, or not allowed. 23319

ORA- 23352

– The nodes list cont ains a duplicat e. 23352

368

Oracle Distributed Systems

Re st r ict ion s The procedures used in deferred RPCs m ust be part of a package; it is not possible t o queue st andalone procedures.

D BM S_ D EFER.COM M I T_ W ORK

The COMMI T_WORK procedure issues a COMMI T com m and t o com m it t he t ransact ion const ruct ed by t he preceding TRANSACTI ON and CALL procedures. PROCEDURE DBMS_DEFER.COMMIT_WORK (commit_work_comment IN VARCHAR2); com m it _work_com m ent is a descript ion of t he t ransact ion. The com m ent m ay be up t o 50 charact ers.

Ex ce pt ion s Exception Name Number

Description

Num ber of argum ent s in t he CALL procedure does not m at ch – value arg_count , t here are m issing calls t o t he dat at ype_ARG m alform edcall 23304 procedure, or t he TRANSACTI ON procedure was not called for t his t ransact ion.

Re st r ict ion s I f t he dest inat ion nodes are not specified in DBMS_REPCAT, t hey are det erm ined by one of t he following, in order of procedure: • • •

List of nodes in param et er passed t o CALL List of nodes in param et er passed t o TRANSACTI ON Ent ries in DEFTRANDEST

D BM S_ D EFER.da t a t ype _ ARG

This dat at ype_ARG procedure specifies an argum ent for a procedure being built for a rem ot e procedure call. The argum ent is of t he dat at ype specified in dat at ype. PROCEDURE DBMS_DEFER.datatype_ARG (arg IN datatype)

369

Oracle Distributed Systems

Pa r a m e t e r s Specificat ions differ for different dat at ypes, depending on whet her you are using Oracle7 or Oracle8. dat at ype can be any t ype in t he following t able. Oracle7 and Oracle8

Oracle8 Only

NUMBER

NVARCHAR2

DATE

ANY_VARCHAR2

VARCHAR2

NCHAR

CHAR

ANY_VARCHAR

ROWI D

BLOB

RAW

CLOB ANY_CLOB NCLOB

The arg param et er is t he value t o pass t o t he param et er of t he sam e dat at ype in t he procedure previously queued via CALL; it m ay not exceed t he following: • •

2000 for CHAR and VARCHAR2 255 for RAW

The various alt ernat ives are list ed here. These specificat ions apply t o bot h Oracle7 and Oracle8: PROCEDURE PROCEDURE PROCEDURE PROCEDURE PROCEDURE PROCEDURE

NUMBER_ARG (arg IN NUMBER); DATE_ARG (arg IN DATE); VARCHAR2_ARG (arg IN VARCHAR2); CHAR_ARG (arg IN CHAR); ROWID_ARG (arg IN ROWID); RAW_ARG (arg IN RAW);

These specificat ions apply only t o Oracle8: PROCEDURE PROCEDURE PROCEDURE PROCEDURE PROCEDURE PROCEDURE PROCEDURE PROCEDURE

NVARCHAR2_ARG (arg IN NVARCHAR2); ANY_VARCHAR2_ARG (arg IN VARCHAR2 CHARACTER SET ANY_CS); NCHAR_ARG (arg IN NCHAR); ANY_CHAR_ARG (arg IN CHAR CHARACTER SET ANY_CS); BLOB_ARG (arg IN BLOB); CLOB_ARG (arg IN CLOB); ANY_CLOB_ARG (arg IN CLOB CHARACTER SET ANY_CS); NCLOB_ARG (arg IN NCLOB);

Ex ce pt ion s Exception Name param len_num

Number –23323

Description Param et er is t oo long.

370

Oracle Distributed Systems

Re st r ict ion s • •

This procedure is used only in conj unct ion wit h CALL. ROWI D param et ers can only be used for RPCs queued for t he local node.

D BM S_ D EFER.TRAN SACTI ON

The TRANSACTI ON procedure allows you t o specify dest inat ion sit es for t he ensuing call( s) t o t he CALL procedure. I t m arks a t ransact ion as “ deferred” —t hat is, t he t ransact ion cont ains RPCs. This call is opt ional because CALL also calls it . There are t wo m ain reasons why you m ight wish t o ident ify dest inat ions t his way: •

•

You m ight wish t o override t he dest inat ions in t he DBA_REPSI TES dat a dict ionary view. You m ight be m aking several calls t o CALL and not wish t o specify t he dest inat ions in t he nodes param et er individually each t im e.

The TRANSACTI ON procedure is overloaded in such a way t hat t he nodes param et er is opt ional. You can specify eit her: PROCEDURE DBMS_DEFER.TRANSACTION; or: PROCEDURE DBMS_DEFER.TRANSACTION (nodes IN node_list_t); I f specified, nodes is a PL/ SQL t able cont aining t he list of nodes t hat should receive t he RPC. I f you do not specify t he nodes param et er, t he ensuing call( s) t o CALL will queue t he calls t o dest inat ions in DEFDEFAULTDEST. I f you do specify t he nodes param et er, you m ust populat e it wit h t he global nam e of t arget dest inat ions.

Ex ce pt ion s Exception Name Number

Description

m alform edcall –23304 Transact ion is not properly form ed, or t ransact ion t erm inat ed. ORA- 23319

–23319 Param et er value is not appropriat e.

ORA- 23352

–23352 node_list _t cont ains duplicat es.

Re st r ict ion s You can call t he TRANSACTI ON procedure only in conj unct ion wit h CALL.

371

Oracle Distributed Systems

A.2 D BM S_ D EFER_ QUERY: Pe r for m ing D ia gnost ics a nd M a in t e n a n ce Occasionally, you m ay want t o see det ails about deferred RPCs in t he queue, such as what procedure and param et ers are used. The DBMS_DEFER_QUERY package cont ains procedures t o display t his dat a.

A.2 .1 H ow t h e Pa ck a ge I s Use d Typically, t his package is used t o assist in debugging errors and conflict s t hat have occurred during t he execut ion of an RPC.

A.2 .2 I n st a lla t ion a n d Acce ss The DBMS_REPCAT_QUERY package is creat ed when t he Oracle dat abase is inst alled. The dbm sdefr.sql script ( found in t he built - in packages source direct ory) cont ains t he source code for t his package’s specificat ion. This script is called by cat rep.sql, which m ust be run t o inst all t he advanced replicat ion packages. The wrapped SQL script prvt rct f.sql creat es t he public synonym DBMS_REPCAT_QUERY. No EXECUTE privileges are grant ed on DBMS_REPCAT_QUERY; only t he owner ( SYS) and t hose wit h t he EXECUTE ANY PROCEDURE syst em privilege m ay execut e t he package. There are no except ions defined for t his package.

A.2 .3 D BM S_ D EFER_ QUERY Pr oce du r e s Procedure Name

Description

GET_ARG_TYPE

Ret urns t he t ype of a param et er in a deferred call

GET_CALL_ARGS

Ret urns inform at ion about param et ers in t ext form

Ret urns t he value of a param et er whose t ype is dat at ype ; GET_dat at ype_ARG values can be CHAR, DATE, NUMBER, RAW, ROWI D, or VARCHAR2

A.2 .4 D BM S_ D EFER_ QUERY N on pr ogr a m Ele m e n t s Type and Name

Description

TYPE t ype_ary

Table of NUMBER

TYPE val_ary

Table of VARCHAR2( 2000)

The PL/ SQL t ables t ype_ary and val_ary are bot h used in param et ers t o t he procedure GET_CALL_ARGS; t ype_ary is an out put array for RPC param et er dat at ypes, and val_ary is an out put array of t he param et er values. The following t able shows t he m apping of num bers t o dat at ypes in t ype_ary: Datatype BFI LE ( Oracle8 only)

Numeric Value in type_ary 114

BLOB ( Oracle8 only)

113

CFI L ( Oracle8 only)

115

372

Oracle Distributed Systems

CHAR

96

CLOB ( Oracle8 only)

112

DATE

12

NUMBER

2

RAW

23

ROWI D

11

VARCHAR2

1

D BM S_ D EFER_ QUERY.GET_ ARG_ TYPE

You can use t his funct ion in conj unct ion wit h GET_dat at ype_ARG or GET_CALL_ARGS t o det erm ine inform at ion about t he deferred RPCs in t he queue. GET_ARG_TYPE ret urns a num ber corresponding t o t he argum ent ’s dat at ype. FUNCTION DBMS_DEFER_QUEUE.GET_ARG_TYPE (callno IN NUMBER, deferred_tran_db IN VARCHAR2, arg_no IN NUMBER, deferred_tran_id IN VARCHAR2) RETURN NUMBER; The following t able shows t he m apping of dat at ypes t o ret urn values: Argument Datatype

GET_ARG_TYPE Return Code

BFI LE ( Oracle8 only)

114

BLOB ( Oracle8 only)

113

CFI L ( Oracle8 only)

115

CHAR

96

CLOB ( Oracle8 only)

112

DATE

12

NUMBER

2

RAW

23

ROWI D

11

VARCHAR2

1

Not ice t hat t he dat at ypes here are lim it ed t o t he Oracle- supplied dat at ypes; you cannot , for exam ple, defer a call t o a procedure t hat accept s a PL/ SQL t able as a param et er. There are no rest rict ions on calling GET_ARG_TYPE.

Pa r a m e t e r s Parameter Name

Description

373

Oracle Distributed Systems

callno

The CALLNO of t he RPC, as st ored in t he DEFCALL dat a dict ionary view

deferred_t ran_db

Global nam e of t he dat abase deferring t he call ( also st ored in DEFCALL)

arg_no

The posit ion of t he argum ent in t he RPC

deferred_t ran_id The deferred_t ran_id for t he call ( also st ored in DEFCALL)

Ex ce pt ion s Exception Name NO_DATA_FOUND

Number

Description

–00100 Specified argum ent does not exist for specified RPC.

D BM S_ D EFER_ QUERY.GET_ CALL_ ARGS

The GET_CALL_ARGS procedure allows you t o obt ain t he dat at ypes and values for all argum ent s passed t o a procedure in a single call. This is t he easiest way t o obt ain inform at ion about t he dat at ypes and values of all passed param et ers. PROCEDURE DBMS_DEFER_QUERY.GET_CALL_ARGS (callno IN NUMBER, startarg IN NUMBER := 1, argcnt IN NUMBER, argsize IN NUMBER, tran_db IN VARCHAR2, tran_id IN VARCHAR2, date_fmt IN VARCHAR2, types OUT TYPE_ARY, vals OUT VAL_ARY); There are no rest rict ions on calling t he GET_CALL_ARGS procedure.

Pa r a m e t e r s Parameter Name

Description

callno

The CALLNO of t he RPC as st ored in t he DEFCALL dat a dict ionary view

st art arg

First argum ent t o fet ch

argcnt

Num ber of argum ent s t o fet ch

argsize

Largest size of a ret urned argum ent

t ran_db

Global nam e of dat abase deferring t he call ( also st ored in DEFCALL)

t ran_id

The deferred_t ran_id param et er for t he call ( also st ored in DEFCALL)

dat e_fm t

Dat e form at m ask

t ypes

Out put array for argum ent t ypes

vals

Out put array for argum ent values

374

Oracle Distributed Systems

Ex ce pt ion s Exception Name NO_DATA_FOUND

Number

Description

–00100 Specified argum ent does not exist for specified RPC.

D BM S_ D EFER_ QUERY.GET_ da t a t ype _ ARG

The GET_dat at ype_ARG funct ion ret urns a value of a cert ain t ype ( specified by dat at ype) . The t ype of t he ret urned value corresponds t o t he value of t he argum ent specified by arg_no in t he deferred RPC corresponding t o callno. There is one variant of t he GET_dat at ype_ARG funct ion for each of t he Oraclesupplied dat at ypes. FUNCTION DBMS_DEFER_QUERY.GET_datatype_ARG (callno IN NUMBER, deferred_tran_db IN VARCHAR2 arg_no IN NUMBER, deferred_tran_id IN VARCHAR2 DEFAULT NULL) RETURN arg; dat at ype can be any t ype in t he following t able. Oracle7 and Oracle8 CHAR

Oracle8 Only NCHAR

DATE

NVARCHAR2

NUMBER

BLOB

RAW

CLOB

ROWI D

NCLOB

VARCHAR2 Therefore, any of t he following are valid: FUNCTION FUNCTION FUNCTION FUNCTION FUNCTION FUNCTION FUNCTION FUNCTION FUNCTION FUNCTION FUNCTION

DBMS_DEFER_QUERY.GET_CHAR_ARG... DBMS_DEFER_QUERY.GET_DATE_ARG... DBMS_DEFER_QUERY.GET_NUMBER_ARG... DBMS_DEFER_QUERY.GET_RAW_ARG... DBMS_DEFER_QUERY.GET_ROWID_ARG... DBMS_DEFER_QUERY.GET_VARCHAR2_ARG... DBMS_DEFER_QUERY.GET_NCHAR_ARG... DBMS_DEFER_QUERY.GET_NVARCHAR2_ARG... DBMS_DEFER_QUERY.GET_BLOB_ARG... DBMS_DEFER_QUERY.GET_CLOB_ARG... DBMS_DEFER_QUERY.GET_NCLOB_ARG...

Param et ers have t he sam e m eanings described for t he GET_ARG_TYPE procedure.

375

Oracle Distributed Systems

Ex ce pt ion s Exception Name

Number

Description

NO_DATA_FOUND

–00100 Specified argum ent does not exist for specified RPC.

WRONG_TYPE

–26564 Specified argum ent is not of t ype dat at ype.

A.3 D BM S_ D EFER_ SYS: M a na gin g D e fe r r e d Tr a n sa ct ion s The DBMS_DEFER_SYS package provides a num ber of program s for adm inist rat ive t asks associat ed wit h deferred t ransact ions.

A.3 .1 H ow t h e Pa ck a ge I s Use d This package is used prim arily t o adm inist er an advanced replicat ion environm ent . DBAs can use t he procedures t o execut e deferred t ransact ions, t o cont rol what nodes are available for t hem , and t o schedule t heir execut ion.

A.3 .2 I n st a lla t ion a n d Acce ss The DBMS_DEFER_SYS package is creat ed when t he Oracle dat abase is inst alled. The dbm sdefr.sql script ( found in t he built - in packages source direct ory) , cont ains t he source code for t his package’s specificat ion. This script is called by cat rep.sql , which m ust be run t o inst all t he advanced replicat ion packages. The wrapped SQL script prvt rct f.sql creat es t he public synonym DBMS_DEFER_SYS. No EXECUTE privileges are grant ed on DBMS_DEFER_SYS; only t he owner ( SYS) and t hose wit h t he EXECUTE ANY PROCEDURE syst em privilege m ay execut e t he package.

A.3 .3 D BM S_ D EFER_ SYS Pr oce du r e s Procedure Name

Description

ADD_DEFAULT_DEST

Adds a dest inat ion t o t he DEFDEFAULTDEST dat a dict ionary view

COPY

Creat es a copy of an RPC wit h a different dest inat ion

DELETE_DEFAULT_DEST

Delet es a dest inat ion from t he DEFDEFAULTDEST dat a dict ionary view

DELETE_ERROR

Delet es an error from t he DEFERROR dat a dict ionary view

DELETE_TRAN

Delet es a t ransact ion from t he DEFTRANDEST dat a dict ionary view

DI SABLED

Ret urns a Boolean indicat ing whet her deferred t ransact ions from t he current sit e t o t he dest inat ion sit e are disabled

EXCLUDE_PUSH

Acquires a lock t o disable deferred pushes

EXECUTE

Execut es an RPC im m ediat ely

EXECUTE_ERROR

Reexecut es an RPC t hat failed previously

PURGE

Purges t ransact ions t hat have been propagat ed from t he deferred t ransact ion queue

PUSH

Pushes a queued t ransact ion t o a dest inat ion node

376

Oracle Distributed Systems

REGI STER_PROPAGATOR

Makes t he designat ed user t he propagat or for t he local dat abase

SCHEDULE_EXECUTI ON

Schedules aut om at ic RPC pushes bet ween a m ast er or snapshot sit e and anot her m ast er sit e

SCHEDULE_PURGE

Schedules t he aut om at ic purge of t ransact ions t hat have been propagat ed from t he queue

SCHEDULE_PUSH

Schedules aut om at ic pushes t o dest inat ion node

SET_DI SABLED

Disables deferred t ransact ions bet ween t he current sit e and a dest inat ion sit e

Com plem ent t o REGI STER_PROPAGATOR; revokes UNREGI STER_PROPAGATOR privileges grant ed t o m ake user t he local dat abase’s propagat or UNSCHEDULE_EXECUTI ON

St ops aut om at ic RPC pushes bet ween a m ast er or snapshot sit e and anot her m ast er sit e

UNSCHEDULE_PURGE

Com plem ent t o SCHEDULE_PURGE; unschedules t he aut om at ic purge of t ransact ions t hat have been propagat ed t o t he queue

UNSCHEDULE_PUSH

Com plem ent t o SCHEDULE_PUSH; unschedules aut om at ic pushes t o dest inat ion node

A.3 .4 D BM S_ D EFER_ SYS Ex ce pt ion s Exception Name crt _err_err

Number –23324

Description Param et er t ype does not m at ch act ual t ype.

A.3 .5 D BM S_ D EFER_ SYS N on pr ogr a m Ele m e n t s The following const ant s defined in t he DBMS_DEFER_SYS are used int ernally in t he package: Type and Name

Description

CONSTANT parm _buffer_size

Size of long buffer used for packing param et ers ( = 4096)

CONSTANT default _alert _nam e

VARCHAR2( 30) : = ORA$DEFER_ALERT

D BM S_ D EFER_ SYS.AD D _ D EFAULT_ D EST

The ADD_DEFAULT_DEST procedure adds records in t he DEFDEFAULTDEST dat a dict ionary view. Adding a record t o t his view effect ively specifies a default dest inat ion for deferred RPCs. PROCEDURE DBMS_DEFER_SYS.ADD_DEFAULT_DEST (dblink IN VARCHAR2);

377

Oracle Distributed Systems dblink is t he global nam e of t he dest inat ion sit e being added. There are no rest rict ions on calling ADD_DEFAULT.DEST. Changes you m ake t o DEFDEFAULTDEST affect fut ure calls only, not calls t hat m ay already be queued.

Ex ce pt ion s Exception Name ORA- 23352

Number

Description

– Specified dest inat ion is already in t he DEFDEFAULTDEST dat a 23352 dict ionary view.

D BM S_ D EFER_ SYS.COPY ( Or a cle 7 on ly)

The COPY procedure copies a specified deferred t ransact ion. Oracle queues t he copied t ransact ion t o t he new dest inat ions t hat you specify. PROCEDURE DBMS_DEFER_SYS.COPY (deferred_tran_id IN VARCHAR2, deferred_tran_db IN VARCHAR2, destination_list IN dbms_defer.node_list_t, destination_count IN BINARY_INTEGER); There are no rest rict ions on calling COPY.

Pa r a m e t e r s Parameter Name

Description

deferred_t ran_id I D from t he DEFTRAN dat a dict ionary view t o be copied deferred_t ran_db Global nam e of t he originat ing dat abase dest inat ion_list

PL/ SQL t able list ing global nam es of dat abases t o which t he t ransact ion is t o be sent

dest inat ion_count Num ber of ent ries in dest inat ion_list

Ex ce pt ion s Exception Name NO_DATA_FOUND

Number –01403

Description Specified deferred_t ran_id does not exist .

D BM S_ D EFER.SYS.D ELETE_ D EFAULT_ D EST

The DELETE_DEFAULT_DEST procedure delet es records in t he DEFDEFAULTDEST dat a dict ionary view. Delet ing a record effect ively rem oves a default dest inat ion for deferred RPCs.

378

Oracle Distributed Systems PROCEDURE DBMS_DEFER_SYS.DELETE_DEFAULT_DEST (dblink IN VARCHAR2); dblink is t he global nam e of t he dest inat ion sit e being delet ed. There are no rest rict ions on calling DELETE_DEFAULT_DEST, and t he procedure raises no except ions.

D BM S_ D EFER_ SYS.D ELETE_ ERROR

The DELETE_ERROR procedure allows you t o delet e t ransact ions from t he DEFERROR dat a dict ionary view. The procedure also delet es t he relat ed ent ries from DEFCALL, DEFTRAN, and DEFTRANDEST. Use DELETE_ERROR if you have m anually resolved a t ransact ion t hat init ially failed. PROCEDURE DBMS_DEFER_SYS.DELETE_ERROR (deferred_tran_id IN VARCHAR2, deferred_tran_db IN VARCHAR2, destination IN VARCHAR2); There are no rest rict ions on calling DELETE_ERROR.

Pa r a m e t e r s Parameter Name

Description

I D from t he DEFTRAN dat a dict ionary view of t he t ransact ion t o be deferred_t ran_id delet ed from DEFERROR. I f NULL, all ent ries for t he specified deferred_t ran_db and dest inat ion are delet ed. deferred_t ran_db

Global nam e of t he originat ing dat abase. I f NULL, all ent ries for t he specified deferred_t ran_id and dest inat ion are delet ed.

dest inat ion

Global nam e of t he dest inat ion dat abase. I f NULL, all ent ries for t he specified deferred_t ran_id and deferred_t ran_db are delet ed.

Ex ce pt ion s Exception Name NO_DATA_FOUND

Number

Description

Specified deferred_t ran_id does not exist , specified – deferred_t ran_db does not exist , or specified dest inat ion 01403 does not exist .

D BM S_ D EFER_ SYS.D ELETE_ TRAN

The DELETE_TRAN procedure delet es deferred t ransact ions. You m ight want t o do t his if you have applied t he call m anually or if you rem ove a node from your

379

Oracle Distributed Systems environm ent . The procedure delet es t he call from t he DEFTRANDEST dat a dict ionary view and also from DEFCALLDEST ( if it is an RPC) . I f t he original call has been applied t o all ot her dest inat ions, t hen t he procedure also rem oves t he ent ries from DEFCALL and DEFTRAN. PROCEDURE DBMS_DEFER_SYS.DELETE_TRAN (deferred_tran_id IN VARCHAR2, deferred_tran_db IN VARCHAR2, destination IN VARCHAR2); There are no rest rict ions on calling DELETE_TRAN.

Pa r a m e t e r s Parameter Name

Description

I D from t he DEFTRAN dat a dict ionary view of t he t ransact ion t o be deferred_t ran_id delet ed from DEFERROR. I f NULL, all ent ries for t he specified deferred_t ran_db and dest inat ion are delet ed. deferred_t ran_db

Global nam e of t he originat ing dat abase. I f NULL, all ent ries for t he specified deferred_t ran_id and dest inat ion are delet ed.

dest inat ion

Global nam e of t he dest inat ion dat abase. I f NULL, all ent ries for t he specified deferred_t ran_id and deferred_t ran_db are delet ed.

Ex ce pt ion s Exception Name NO_DATA_FOUND

Number

Description

Specified deferred_t ran_id does not exist , specified – deferred_t ran_db does not exist , or specified dest inat ion 01403 does not exist .

D BM S_ D EFER_ SYS.D I SABLED

The DI SABLED funct ion ret urns t he Boolean value TRUE if t he deferred RPCs t o t he specified dest inat ion have been disabled ( wit h SET_DI SABLED) and ret urns FALSE ot herwise. FUNCTION DBMS_DEFER_SYS.DISABLED (destination IN VARCHAR2) RETURN BOOLEAN; dest inat ion is t he global nam e of t he dest inat ion dat abase. There are no rest rict ions on calling t he DI SABLED funct ion.

Ex ce pt ion s Exception Name NO_DATA_FOUND

Number

Description

– Specified dest inat ion is not in t he DEFSCHEDULE dat a 01403 dict ionary view.

380

Oracle Distributed Systems

D BM S_ D EFER_ SYS.EXCLUD E_ PUSH ( Or a cle 8 On ly)

Oracle8 uses a slight ly different m echanism t o propagat e t ransact ions t o rem ot e dat abases. I nst ead of delet ing t ransact ions from t he local queue as soon as t hey are delivered t o a rem ot e sit e, Oracle purges t he queue as a separat e process. This st rat egy enhances perform ance because t here is no need for a t wo- phase com m it when t ransact ions are propagat ed. I n addit ion, Oracle8 includes support for parallel propagat ion, which m eans t hat m ult iple t ransact ions can be delivered t o t he dest inat ions sim ult aneously if t hey are not dependent on each ot her. FUNCTION DBMS_DEFER_SYS.EXCLUDE_PUSH (timeout IN INTEGER) RETURN INTEGER; t im eout is t he t im e t o wait t o acquire a lock t hat disables pushes. Specify DBMS_LOCK.MAXWAI T t o wait indefinit ely. The EXCLUDE_PUSH funct ion m ay ret urn t he values shown in t he following t able: Value

Meaning

0

Norm al successful com plet ion

1

Tim ed out wait ing for lock

2

Unsuccessful due t o deadlock

4

Lock is already owned

D BM S_ D EFER_ SYS.EXECUTE

The DBMS_DEFER.CALL procedure, discussed earlier, neit her execut es nor pushes t ransact ions t o t he dest inat ion dat abases; it sim ply queues t hem . I n order t o propagat e t he deferred call t o t he dest inat ions and t o execut e it t here, you m ust use t he DBMS_DEFER_SYS package’s EXECUTE procedure. EXECUTE forces im m ediat e execut ion of a deferred t ransact ion from t he current m ast er or snapshot sit e. PROCEDURE DBMS_DEFER_SYS.EXECUTE (destination IN VARCHAR2, stop_on_error IN BOOLEAN := FALSE, transaction_count IN BINARY_INTEGER := 0, execution_seconds IN BINARY_INTEGER := 0, execute_as_user IN BOOLEAN := FALSE, delay_seconds IN NATURAL := 0, batch_size IN NATURAL := 0); There are no rest rict ions on calling EXECUTE.

381

Oracle Distributed Systems

Pa r a m e t e r s Parameter Name

Description

dest inat ion

Global nam e of t he dest inat ion dat abase.

st op_on_error

I f TRUE, execut ion of queued t ransact ions st ops if an error is encount ered. I f FALSE ( t he default ) , execut ion cont inues unless dest inat ion is unavailable.

t ransact ion_count I f > 0, m axim um num ber of t ransact ions t o execut e. execut ion_seconds

I f > 0, m axim um num ber of seconds t o spend execut ing t ransact ions.

execut e_as_user

I f TRUE, t he execut ion of deferred t ransact ions is aut hent icat ed at t he rem ot e syst em using t he aut hent icat ion cont ext of t he session user. I f FALSE ( t he default ) , t he execut ion is aut hent icat ed at t he rem ot e syst em using t he aut hent icat ion cont ext s of t he users t hat originally queued t he deferred t ransact ions ( indicat ed in t he origin_user colum n of t he DEFTRAN dat a dict ionary view) . This param et er is obsolet e in Oracle8, which execut es t ransact ions under t he cont ext of t he propagat or.

delay_seconds

I f > 0, rout ine sleeps for t his m any seconds before resum ing when t here are no m ore t ransact ions t o push t o dest inat ion.

bat ch_size

The num ber of deferred t ransact ions execut ed before com m it t ing. I f bat ch_size = 0, a com m it occurs aft er each deferred t ransact ion. I f bat ch_size > 0, a com m it occurs when t he t ot al num ber of deferred calls execut ed exceeds bat ch_size and a com plet e t ransact ion has been execut ed.

Ex ce pt ion s I f execut ion st ops because of an except ion, t he EXECUTE procedure raises t he last except ion encount ered.

D BM S_ D EFER_ SYS.EXECUTE_ ERROR

The EXECUTE_ERROR procedure execut es t ransact ions in t he DEFERROR dat a dict ionary view aft er t he cause of t he error has been resolved. As wit h t he DELETE_ERROR and DELETE_TRAN procedures, you m ay pass NULLs t o indicat e wildcards. PROCEDURE DBMS_DEFER_SYS.EXECUTE_ERROR (deferred_tran_id IN VARCHAR2, deferred_tran_db IN VARCHAR2, destination IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

382

Oracle Distributed Systems

deferred_t ran_id I D of t ransact ion in t he DEFERROR dat a dict ionary view deferred_t ran_db

Global nam e of dat abase t hat originat ed or copied t he t ransact ion originally

dest inat ion

Global nam e of dest inat ion dat abase

Ex ce pt ion s Exception Name ORA24275

Number

Description

– dest inat ion is NULL, or deferred_t ran_id and deferred_t ran_db 24275 are neit her bot h NULL nor bot h NOT NULL.

I f execut ion st ops because of an except ion, t he EXECUTE_ERROR procedure raises t he last except ion encount ered.

Re st r ict ion s • •

The dest inat ion param et er m ay not be NULL. The deferred_t ran_id and deferred_t ran_db param et ers m ust eit her bot h be NULL or bot h be NOT NULL. I f t hey are NULL, all t ransact ions in DEFERROR dest ined for dest inat ion are applied.

D BM S_ D EFER_ SYS.PURGE ( Or a cle 8 On ly)

The PURGE procedure purges t ransact ions t hat have been propagat ed from t he deferred t ransact ion queue. FUNCTION DBMS_DEFER_SYS.PURGE( purge_method IN BINARY_INTEGER := purge_method_quick, rollback_segment IN VARCHAR2 := NULL, startup_seconds IN BINARY_INTEGER := 0, execution_seconds IN BINARY_INTEGER := seconds_infinity, delay_seconds IN BINARY_INTEGER := 0, transaction_count IN BINARY_INTEGER := transactions_infinity, write_trace IN BOOLEAN := FALSE ) RETURN BINARY_INTEGER;

Pa r a m e t e r s Parameter Name

Description 1 = purge_m et hod_quick ( not necessarily com plet e, but fast er) .

purge_m et hod 2 = purge_m et hod_precise ( com plet e purge) . rollback_segm ent

Which rollback segm ent should be used.

st art up_seconds

Maxim um num ber of seconds t o wait for t he com plet ion of a previous push t o t he sam e dest inat ion.

383

Oracle Distributed Systems

execut ion_seconds

I f > 0, m axim um num ber of seconds t o spend execut ing t ransact ions.

delay_seconds

I f > 0, rout ine sleeps for t his m any seconds before resum ing when t here are no m ore t ransact ions t o push t o dest inat ion.

t ransact ion_count Maxim um num ber of t ransact ions t o push per execut ion. writ e_t race

I f TRUE, record result in a t race file.

The ret urn values for PURGE are list ed in t he following t able: Value

Meaning

0

Norm al com plet ion aft er delay_seconds expired

1

Term inat ed by lock t im eout while st art ing

2

Term inat ed by exceeding execut ion_seconds

3

Term inat ed by exceeding t ransact ion_count

4

Term inat ed at delivery_order_lim it

5

Term inat ed aft er errors

Ex ce pt ion s Exception Name

Number

Description

argout ofrange

–23427

A param et er value is out of range.

execut iondisabled

–23354

Execut ion is disabled at dest inat ion.

dbm s_defererror

–23305

An int ernal error occurred.

D BM S_ D EFER_ SYS.PUSH

The PUSH funct ion pushes a queued t ransact ion t o a dest inat ion node. FUNCTION DBMS_DEFER_SYS.PUSH( destination IN VARCHAR2, parallelism IN BINARY_INTEGER := 0, heap_size IN BINARY_INTEGER := 0, stop_on_error IN BOOLEAN := FALSE, write_trace IN BOOLEAN := FALSE, startup_seconds IN BINARY_INTEGER := 0, execution_seconds IN BINARY_INTEGER := seconds_infinity, delay_seconds IN BINARY_INTEGER := 0, transaction_count IN BINARY_INTEGER := transactions_infinity, delivery_order_limit IN NUMBER := delivery_order_infinity ) RETURN BINARY_INTEGER;

Pa r a m e t e r s Parameter Name dest inat ion

Description Global nam e of t he dest inat ion dat abase.

384

Oracle Distributed Systems

Degree of parallelism : parallelism

heap_size

0 = serial ( no parallelism ) 1 = parallel propagat ion wit h one slave n = parallel propagat ion wit h n slaves I f > 0, m axim um num ber of t ransact ions t o exam ine sim ult aneously for parallel scheduling com put at ion. I f 0, com put e t his num ber based on parallelism param et er.

st op_on_error

I f TRUE, t hen st op on t he first error, even if not fat al.

writ e_t race

I f TRUE, record result in a t race file.

st art up_seconds

Maxim um num ber of seconds t o wait for t he com plet ion of a previous push t o t he sam e dest inat ion.

execut ion_seconds

Maxim um num ber of seconds t o spend on t he push before shut t ing down; default s t o seconds_infinit y ( i.e., unlim it ed) .

delay_seconds

Shut down push cleanly if queue is em pt y for t his m any seconds.

t ransact ion_count

Maxim um num ber of t ransact ions t o push per execut ion.

delivery_order_lim it delivery_order > delivery_order_lim it . Ret urn values for PUSH are list ed in t he following t able: Value

Meaning

0

Norm al com plet ion aft er delay_seconds expired

1

Term inat ed by lock t im eout while st art ing

2

Term inat ed by exceeding execut ion_seconds

3

Term inat ed by exceeding t ransact ion_count

4

Term inat ed at delivery_order_lim it

5

Term inat ed aft er errors

Ex ce pt ion s Exception Name com m failure

Number –23302

Description Com m unicat ion failure.

crt _err_err

–23324

Error creat ing DEFERROR ent ry.

deferred_rpc_quiesce

–23326

The syst em is being quiesced.

execut iondisabled

–23354

Execut ion is disabled at dest inat ion.

incom plet eparallelpush

–23388

I nt ernal error.

m issingpropagat or

–23357

A propagat or does not exist .

D BM S_ D EFER_ SYS.REGI STER_ PROPAGATOR ( Or a cle 8 On ly)

385

Oracle Distributed Systems The REGI STER_PROPAGATOR procedure m akes a designat ed user t he propagat or for t he local dat abase. PROCEDURE DBMS_DEFER_SYS.REGISTER_PROPAGATOR (username IN VARCHAR2); usernam e is t he nam e of t he account t o which privileges are t o be grant ed.

Ex ce pt ion s Exception Name

Number

Description

alreadypropagat or

– User usernam e is already t he propagat or for t his 23393 dat abase.

duplicat epropagat or

– Dat abase already has a propagat or account . 23394

m issinguser

– User usernam e does not exist . 23362

D BM S_ D EFER_ SYS.SCH ED ULE_ EXECUTI ON

I f you are using t he advanced replicat ion facilit ies or if your applicat ion queues deferred RPCs on a cont inual basis, t hen you should schedule t he calls t o t he EXECUTE procedure at prescribed int ervals for each dest inat ion. The SCHEDULE_EXECUTI ON procedure does j ust t hat by placing calls t o t he EXECUTE procedure in t he j ob queue. PROCEDURE DBMS_DEFER_SYS.SCHEDULE_EXECUTION (dblink IN VARCHAR2, interval IN VARCHAR2, next_date IN DATE, reset IN BOOLEAN default FALSE, stop_on_error IN BOOLEAN := NULL, transaction_count IN BINARY_INTEGER := NULL, execution_seconds IN BINARY_INTEGER := NULL, execute_as_user IN BOOLEAN := NULL, delay_seconds IN NATURAL := NULL, batch_size IN NATURAL := NULL); The SCHEDULE_EXECUTI ON procedure does not raise any except ions nor are t here any rest rict ions on calling t his procedure.

Pa r a m e t e r s Parameter Name

Description

dblink

Global nam e of t he dest inat ion dat abase.

int erval

Frequency wit h which t o execut e t he RPC.

next _dat e

First t im e t o execut e t ransact ions queued for dblink.

reset

I f TRUE, t hen last _t xn_count , last _error, and last _m sg are nulled

386

Oracle Distributed Systems

in DEFSCHEDULE dat a dict ionary view for t his dblink. st op_on_error

I f not NULL, value is used by t he call t o EXECUTE.

t ransact ion_count I f not NULL, value is used by t he call t o EXECUTE. execut ion_seconds I f not NULL, value is used by t he call t o EXECUTE. execut e_as_user

I f not NULL, value is used by t he call t o DBMS_DEFER_SYS.EXECUTE ( obsolet e in Oracle8) .

delay_seconds

I f not NULL, value is used by t he call t o EXECUTE.

bat ch_size

I f not NULL, value is used by t he call t o EXECUTE.

I f an ent ry for dblink already exist s in t he DEFSCHEDULE dat a dict ionary view wit h non- NULL values for next _dat e and int erval, you do not need t o specify t hese values in t he call t o SCHEDULE_EXECUTI ON. I f you do specify int erval and/ or next _dat e, t hen any previous values in DEFSCHEDULE will be overwrit t en. I f t here is no ent ry for dblink in DEFSCHEDULE, t hen you m ust supply a value for int erval and/ or next _dat e.

D BM S_ D EFER_ SYS.SCH ED ULE_ PURGE ( Or a cle 8 On ly)

The SCHEDULE_PURGE procedure schedules t he aut om at ic purge of t ransact ions t hat have been propagat ed from t he queue. PROCEDURE DBMS_DEFER_SYS.SCHEDULE_PURGE( interval IN VARCHAR2, next_date IN DATE, reset IN BOOLEAN := FALSE, purge_method IN BINARY_INTEGER := NULL, rollback_segment IN VARCHAR2 := NULL, startup_seconds IN BINARY_INTEGER := NULL, execution_seconds IN BINARY_INTEGER := NULL, delay_seconds IN BINARY_INTEGER := NULL, transaction_count IN BINARY_INTEGER := NULL, write_trace IN BOOLEAN := NULL );

Pa r a m e t e r s Parameter Name

Description

int erval

Frequency wit h which t o execut e t he call.

next _dat e

First t im e t o execut e t he purge.

reset

I f TRUE, last _t xn_count , last _error, and last _m sg are nulled in DEFSCHEDULE dat a dict ionary view. 1 = purge_m et hod_quick ( not necessarily com plet e, but fast er) .

purge_m et hod 2 = purge_m et hod_precise ( com plet e purge) . rollback_segm ent

Which rollback segm ent should be used.

387

Oracle Distributed Systems

st art up_seconds

Maxim um num ber of seconds t o wait for t he com plet ion of a previous push t o t he sam e dest inat ion.

execut ion_seconds

Maxim um num ber of seconds t o spend on t he push before shut t ing down; default s t o seconds_infinit y ( i.e., unlim it ed) .

delay_seconds

I f > 0, rout ine sleeps for t his m any seconds before resum ing when t here are no m ore t ransact ions t o push t o dest inat ion.

t ransact ion_count Maxim um num ber of t ransact ions t o push per execut ion. writ e_t race

I f TRUE, record t he result in a t race file.

D BM S_ D EFER_ SYS.SCH ED ULE_ PUSH ( Or a cle 8 On ly)

The SCHEDULE_PUSH procedure schedules aut om at ic pushes t o t he dest inat ion node. PROCEDURE DBMS_DEFER_SYS.SCHEDULE_PUSH( destination IN VARCHAR2, interval IN VARCHAR2, next_date IN DATE, reset IN BOOLEAN := FALSE, parallelism IN BINARY_INTEGER := NULL, heap_size IN BINARY_INTEGER := NULL, stop_on_error IN BOOLEAN := NULL, write_trace IN BOOLEAN := NULL, startup_seconds IN BINARY_INTEGER := NULL, execution_seconds IN BINARY_INTEGER := NULL, delay_seconds IN BINARY_INTEGER := NULL, transaction_count IN BINARY_INTEGER := NULL );

Pa r a m e t e r s Parameter Name

Description

dest inat ion

Global nam e of t he dest inat ion dat abase.

int erval

Frequency wit h which t o execut e t he call.

next _dat e

First t im e t o push t ransact ions queued for dest inat ion.

reset

I f TRUE, last _t xn_count , last _error, and last _m sg are nulled in DEFSCHEDULE dat a dict ionary view for t his dest inat ion. Degree of parallelism :

parallelism

0 = serial ( no parallelism ) 1 = parallel propagat ion wit h one slave n = parallel propagat ion wit h n slaves

heap_size

I f > 0, m axim um num ber of t ransact ions t o exam ine sim ult aneously for parallel scheduling com put at ion. I f 0, com put e t his num ber based on parallelism param et er.

st op_on_error

I f TRUE, st op on t he first error, even if not fat al.

writ e_t race

I f TRUE, record t he result in a t race file.

388

Oracle Distributed Systems

st art up_seconds

Maxim um num ber of seconds t o wait for t he com plet ion of a previous push t o t he sam e dest inat ion.

execut ion_seconds

Maxim um num ber of seconds t o spend on t he push before shut t ing down; default s t o seconds_infinit y ( i.e., unlim it ed) .

delay_seconds

I f > 0, rout ine sleeps for t his m any seconds before resum ing when t here are no m ore t ransact ions t o push t o dest inat ion.

t ransact ion_count Maxim um num ber of t ransact ions t o push per execut ion.

D BM S_ D EFER_ SYS.SET_ D I SABLED

The SET_DI SABLED procedure disables or enables propagat ion t o t he specified dest inat ion. I f you are m anaging a replicat ed environm ent , you m ight want t o disable propagat ion t o a given sit e while you perform m aint enance. I f you disable propagat ion while RPCs are being delivered t o t he dest inat ion dat abase, t he delivery will be allowed t o com plet e. PROCEDURE DBMS_DEFER_SYS.SET_DISABLED (destination IN VARCHAR2, disabled IN BOOLEAN := TRUE);

Pa r a m e t e r s Parameter Name

Description

dest inat ion

Global nam e of t he dest inat ion dat abase

disabled

Flag indicat ing whet her calls are t o be disabled ( TRUE) or enabled ( FALSE)

I f disabled is set t o TRUE, propagat ion t o t he dest inat ion is disabled, alt hough any t ransact ions in progress are allowed t o com plet e. I f disabled is set t o FALSE, propagat ion t o t he dest inat ion is enabled, alt hough t his does not call EXECUTE.

Ex ce pt ion s Exception Name NO_DATA_FOUND

Number

Description

– Specified dest inat ion is not in t he DEFSCHEDULE dat a 01403 dict ionary view.

Re st r ict ion s You m ust execut e a COMMI T aft er a call t o t he SET_DI SABLED procedure for t he changes t o t ake effect .

D BM S_ D EFER_ SYS.UN REGI STER_ PROPAGATOR ( Or a cle 8 On ly)

389

Oracle Distributed Systems

The UNREGI STER_PROPAGATOR procedure revokes t he privileges grant ed t o m ake a part icular user t he local dat abase propagat or. PROCEDURE DBMS_DEFER_SYS.UNREGISTER_PROPAGATOR (username IN VARCHAR2, timeout IN INTEGER DEFAULT dbms_lock.maxwait); I recom m end using t he sam e usernam e as t he propagat or at all dat abase sit es. Also, m ake sure t hat t he account is t he sam e as t he replicat ion adm inist rat or ( REPADMI N) account .

Pa r a m e t e r s Parameter Name

Description

usernam e

Nam e of t he account for which privileges are t o be revoked

t im eout

Num ber of seconds t o wait if t he propagat or account is in use when t he call t o UNREGI STER_PROPAGATOR is m ade

Ex ce pt ion s Exception Name

Number

Description

m issingpropagat or

– User usernam e is not a propagat or. 23357

propagat or_inuse

– The propagat or account is in use, and t im eout seconds 23418 have elapsed.

D BM S_ D EFER_ SYS.UN SCH ED ULE_ EXECUTI ON

When you need t o st op t he propagat ion of deferred calls t o a given dest inat ion, you can do so wit h t he UNSCHEDULE_EXECUTI ON procedure. PROCEDURE DBMS_DEFER_SYS.UNSCHEDULE_EXECUTION (dblink IN VARCHAR2); dblink is t he global nam e of t he dest inat ion dat abase. Calling t his procedure is analogous t o calling DBMS_JOB.REMOVE t o rem ove t he j ob t hat SCHEDULE_EXECUTI ON scheduled. The j ob is rem oved from t he queue, and aut om at ic propagat ion t o t he dat abase specified by dblink ceases. Whenever you rem ove a m ast er definit ion sit e, call UNCHEDULE_EXECUTI ON for t he sit e. There are no rest rict ions on calling UNSCHEDULE_EXECUTI ON.

390

Oracle Distributed Systems

Ex ce pt ion s Exception Name

Number

Description Specified dest inat ion is not in t he DEFSCHEDULE dat a

NO_DATA_FOUND –01403 dict ionary view.

D BM S_ D EFER_ SYS.UN SCH ED ULE_ PURGE ( Or a cle 8 On ly)

The UNSCHEDULE_PURGE procedure is t he com plem ent t o t he SCHEDULE_PURGE procedure. This procedure unschedules t he aut om at ic purge of t ransact ions t hat have been propagat ed t o t he queue. PROCEDURE DBMS_DEFER_SYS.UNSCHEDULE_PURGE;

D BM S_ D EFER_ SYS.UN SCH ED ULE_ PUSH ( Or a cle 8 On ly)

The UNSCHEDULE_PUSH procedure is t he com plem ent t o t he SCHEDULE_PUSH procedure. This procedure unschedules aut om at ic pushes t o t he dest inat ion node. PROCEDURE DBMS_DEFER_SYS.UNSCHEDULE_PUSH(dblink IN VARCHAR2); dblink is t he global nam e of t he dat abase t o which pushes are t o be unscheduled.

Ex ce pt ion s Exception Name NO_DATA_FOUND

Number –00100

Description No pushes t o dblink exist .

A.4 D BM S_ OFFLI N E_ OG: Pe r for m ing Sit e I n st a n t ia t ion When you add a new sit e t o your replicat ed environm ent , you m ust not only creat e t he replicat ed obj ect s but also populat e snapshot s and replicat ed t ables wit h a copy of t he current dat a. Alt hough you can set t he copy_rows param et er t o TRUE in your call t o t he DBMS_REPCAT package’s CREATE_MASTER_REPOBJECT or ADD_MASTER_DATABASE procedure, t his opt ion is not pract ical for schem as t hat are large or com plex. The DBMS_OFFLI NE_OG package provides a m ore feasible m et hod of sit e inst ant iat ion. The general idea is t hat you export dat a from an exist ing m ast er sit e and im port it int o t he new m ast er sit e. While t he im port is t aking place, t he exist ing m ast er sit e’s queue dat a updat es t o t he new sit e, but t he updat es are not act ually

391

Oracle Distributed Systems sent unt il t he load is com plet e. This package let s you perform m uch of t he inst ant iat ion wit hout quiescing t he ent ire replicat ion group.

A.4 .1 H ow t h e Pa ck a ge I s Use d The following t able sum m arizes t he st eps you follow when using DBMS_OFFLI NE_OG. Step

Where Performed

Activity

1

Mast er definit ion sit e

DBMS_REPCAT.ADD_MASTER_DATABASE

2

Mast er definit ion sit e

DBMS_REPCAT.SUSPEND_MASTER_ACTI VI TY

3

Mast er definit ion sit e

DBMS_OFFLI NE_OG.BEGI N_I NSTANTI ATI ON

4

Any m ast er sit e

Export replicat ed schem a

5

Mast er definit ion sit e

DBMS_OFFLI NE_OG.RESUME_SUBSET_OF_MASTERS

6

New sit e

DBMS_OFFLI NE_OG.BEGI N_LOAD

7

New sit e

I m port dat a from St ep 4

8

New sit e

DBMS_OFFLI NE_OG.END_LOAD

9

Mast er definit ion sit e

DBMS_OFFLI NE_OG.END_I NSTANTI ATI ON

A.4 .2 I n st a lla t ion a n d Acce ss The DBMS_OFFLI NE_OG package is creat ed when t he Oracle dat abase is inst alled. The dbm sofln.sql script ( found in t he built - in packages source direct ory) cont ains t he source code for t his package’s specificat ion. This script is called by cat rep.sql, which m ust be run t o inst all t he advanced replicat ion packages. The wrapped SQL script prvt ofln.plb creat es t he public synonym DBMS_OFFLI NE_OG. No EXECUTE privileges are grant ed on DBMS_OFFLI NE_OG; only t he owner ( SYS) and t hose wit h t he EXECUTE ANY PROCEDURE syst em privilege m ay execut e t he package.

A.4 .3 D BM S_ OFFLI N E_ OG Pr oce du r e s Procedure Name BEGI N_I NSTANTI ATI ON

Description Call from m ast er definit ion sit e t o flag beginning of offline inst ant iat ion

BEGI N_LOAD

Call from new m ast er sit e prior t o im port ing dat a

END_I NSTANTI ATI ON

Call from m ast er definit ion sit e t o flag end of offline inst ant iat ion

END_LOAD

Call from new m ast er sit e aft er im port ing dat a

Call from m ast er definit ion sit e t o resum e RESUME_SUBSET_OF_MASTERS replicat ion act ivit y for exist ing sit es while new sit e is inst ant iat ed

A.4 .4 D BM S_ OFFLI N E_ OG Ex ce pt ion s Name badargum ent

Number

Description

– gnam e, snam e, m ast er_sit e, or snapshot _onam e is NULL or 23430 ' '.

sit ealreadyexist s –

new_sit e already exist s.

392

Oracle Distributed Systems

23432 unknownsit e

– new_sit e is not known at t he m ast er definit ion sit e ( i.e., not 23434 in t he DBA_REPSI TES dat a dict ionary view) .

wrongsit e

– BEGI N_LOAD is execut ed at a sit e ot her t han new_sit e. 23433

wrongst at e

– The sit e is not in t he appropriat e st at e ( norm al or quiesced) 23431 for t he at t em pt ed act ivit y.

A.4 .5 D BM S_ OFFLI N E_ OG N on pr ogr a m Ele m e n t s Type and Name TYPE Set OfSit eType

Description Table of VARCHAR2( 256)

Set OfSit eType is a PL/ SQL t able t hat is used int ernally.

D BM S_ OFFLI N E_ OG.BEGI N _ I N STAN TI ATI ON

The BEGI N_I NSTANTI ATI ON procedure is called from t he m ast er definit ion sit e t o flag t he beginning of offline inst ant iat ion. PROCEDURE DBMS_OFFLINE_OG.BEGIN_INSTANTIATION (gname IN VARCHAR2, new_site IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

gnam e

The replicat ion group t o which t he sit e is being added

new_sit e

The global nam e of t he new sit e

Ex ce pt ion s Exception Name

Number

Description

badargum ent

– Group gnam e is NULL or ' '. 23430

m issingrepgroup

– Group gnam e does not exist . 23373

nonm ast erdef

– Rout ine is not being called from t he m ast er definit ion sit e. 23312

sit ealreadyexist s

– new_sit e already exist s. 23432

wrongst at e

– Group gnam e is not in NORMAL st at e at t he m ast er 23431 definit ion sit e.

393

Oracle Distributed Systems

Re st r ict ion s • •

This procedure m ust be run from t he m ast er definit ion sit e. Group gnam e m ust be quiesced.

D BM S_ OFFLI N E_ OG.BEGI N _ LOAD

Call t he BEGI N_LOAD procedure from t he new m ast er sit e before you begin im port ing dat a. The effect is t o disable t riggers so t hat dat a cannot be m odified during t he im port and t o disable t he propagat ion of changes t o ot her m ast er sit es. PROCEDURE DBMS_OFFLINE_OG.BEGIN_LOAD (gname IN VARCHAR2, new_site IN VARCHAR2); Param et ers are ident ical t o t hose given for t he BEGI N_I NSTANTI ATI ON procedure.

Ex ce pt ion s Exception Name

Number

Description

badargum ent

– Group gnam e is NULL or ' ' . 23430

m issingrepgroup

– Group gnam e does not exist . 23373

wrongsit e

– BEGI N_LOAD or END_LOAD is execut ed at a sit e ot her t han 23433 new_sit e.

wrongst at e

– Group gnam e is not in NORMAL st at e at t he m ast er 23431 definit ion sit e.

Re st r ict ion s This procedure m ust be run from t he new sit e prior t o im port ing t he replicat ed schem a. The effect is t o add t he new sit e t o t he set of m ast ers in a norm al st at e— t hat is, all propagat ion is enabled am ong all sit es.

D BM S_ OFFLI N E_ OG.EN D _ I N STAN TI ATI ON

You call t he END_I NSTANTI ATI ON procedure from t he m ast er definit ion sit e t o flag t he end of offline inst ant iat ion. PROCEDURE DBMS_OFFLINE_OG.END_INSTANTIATION

394

Oracle Distributed Systems (gname IN VARCHAR2, new_site IN VARCHAR2); Param et ers are ident ical t o t hose described for t he BEGI N_I NSTANTI ATI ON procedure.

Ex ce pt ion s Exception Name

Number

Description

badargum ent

– Group gnam e is NULL or ' '. 23430

m issingrepgroup

– Group gnam e does not exist . 23373

nonm ast erdef

– Rout ine is not being called from t he m ast er definit ion sit e. 23312

sit ealreadyexist s

– new_sit e already exist s. 23432

wrongst at e

– Group gnam e is not in NORMAL st at e at t he m ast er 23431 definit ion sit e.

Re st r ict ion s • •

This procedure m ust be run from t he m ast er definit ion sit e. Group gnam e m ust be in t he NORMAL st at e at t he m ast er definit ion sit e.

D BM S_ OFFLI N E_ OG.EN D _ LOAD

Call t he END_LOAD procedure from t he new m ast er sit e when you are finished im port ing dat a. The effect is t o enable propagat ion t o all ot her sit es part icipat ing in t he replicat ion. PROCEDURE DBMS_OFFLINE_OG.END_LOAD (gname IN VARCHAR2, new_site IN VARCHAR2); Param et ers are ident ical t o t hose given for t he BEGI N_I NSTANTI ATI ON procedure.

Ex ce pt ion s Exception Name

Number

Description

badargum ent

– Group gnam e is NULL or ' '. 23430

m issingrepgroup

– Group gnam e does not exist . 23373

wrongsit e

–

BEGI N_LOAD or END_LOAD is execut ed at a sit e ot her t han

395

Oracle Distributed Systems

23433 new_sit e. wrongst at e

– Group gnam e is not in NORMAL st at e at t he m ast er 23431 definit ion sit e.

Re st r ict ion s This procedure m ust be run from t he new sit e aft er t he dat a is im port ed.

D BM S_ OFFLI N E_ OG.RESUM E_ SUBSET_ OF_ M ASTERS

Call t his procedure from t he m ast er definit ion sit e t o allow propagat ion of replicat ion act ivit y am ong all m ast er sit es except t he sit e indicat ed by t he new_sit e param et er. Upon successful com plet ion, t he st at us of gnam e is NORMAL in all m ast er sit es except for new_sit e, where t he group is st ill quiesced. PROCEDURE DBMS_OFFLINE_OG.RESUME_SUBSET_OF_MASTERS (gname IN VARCHAR2, new_site IN VARCHAR2); Param et ers are ident ical t o t hose given for t he BEGI N_I NSTANTI ATI ON procedure.

Ex ce pt ion s Exception Name

Number

Description

badargum ent

– Group gnam e is NULL or ' '. 23430

m issingrepgroup

– Group gnam e does not exist . 23373

nonm ast erdef

– Rout ine is not being called from m ast er definit ion sit e. 23312

sit ealreadyexist s

– new_sit e already exist s. 23432

wrongst at e

– Group gnam e is not in NORMAL st at e at t he m ast er 23431 definit ion sit e.

Re st r ict ion s • •

This procedure m ust be run from t he m ast er definit ion sit e. Group gnam e m ust be in t he quiesced st at e at t he m ast er definit ion sit e.

396

Oracle Distributed Systems

A.5 D BM S_ OFFLI N E_ SN APSH OT: Pe r for m in g Offlin e Sn a pshot I n st a n t ia t ion The DBMS_OFFLI NE_SNAPSHOT package allows you t o inst ant iat e snapshot s wit hout having t o run t he CREATE SNAPSHOT com m and or t he DBMS_REPEAT.SNAPSHOT_REPOBJECT procedure over t he net work. Doing offline inst ant iat ion in t his way is part icularly useful in cases in which you wish t o inst ant iat e a snapshot sit e wit h a large am ount of dat a in an advanced replicat ion environm ent . Offline inst ant iat ion refers t o t he populat ion of snapshot s wit h t he im port and export ut ilit ies, as opposed t o using t he DBMS_SNAPSHOT.REFRESH procedure. This t echnique is less t im e consum ing and less t axing on your net work, and it m inim izes t he t im e your environm ent m ust be quiesced.

A.5 .1 H ow t h e Pa ck a ge I s Use d The following t able sum m arizes t he st eps you follow when using DBMS_OFFLI NE_SNAPSHOT: Step

Where Performed

Activity

1

Mast er sit e

Creat e snapshot log on t able( s) t o be snapshot t ed ( opt ional, but recom m ended) .

2

Mast er sit e

Creat e a snapshot locally on t he t able( s) t o be snapshot t ed.

3

Mast er sit e

Export SNAP$_t able_nam e t able( s) creat ed in St ep 2 as t he schem a owner.

4

New snapshot DBMS_REPCAT.CREATE_SNAPSHOT_REPGROUP. sit e

5

New snapshot DBMS_OFFLI NE_SNAPSHOT.BEGI N_LOAD. sit e

6

New snapshot I m port SNAP$_t able_nam e t ables from export file creat ed in St ep sit e 3.

7

New snapshot DBMS_OFFLI NE_SNAPSHOT.END_LOAD. sit e

8

Mast er sit e

Drop snapshot ( s) creat ed in St ep 2.

A.5 .2 I n st a lla t ion a n d Acce ss The DBMS_OFFLI NE_SNAPSHOT package is creat ed when t he Oracle dat abase is inst alled. The dbm sofln.sql script ( found in t he built - in packages source direct ory) cont ains t he source code for t his package’s specificat ion. This script is called by cat rep.sql, which m ust be run t o inst all t he advanced replicat ion packages. The wrapped SQL script prvt ofln.plb creat es t he public synonym DBMS_OFFLI NE_SNAPSHOT. No EXECUTE privileges are grant ed on DBMS_OFFLI NE_SNAPSHOT; only t he owner ( SYS) and t hose wit h t he EXECUTE ANY PROCEDURE syst em privilege m ay execut e t he package.

397

Oracle Distributed Systems

A.5 .3 D BM S_ OFFLI N E_ SN APSH OT Pr oce du r e s Name

Description

BEGI N_LOAD

Call before beginning t o load dat a from an export file

END_LOAD

Call aft er t he load is com plet e

A.5 .4 D BM S_ OFFLI N E_ SN APSH OT Ex ce pt ion s Name

Number

Description

badargum ent

– The gnam e, snam e, m ast er_sit e, or snapshot _onam e 23430 param et er is NULL or ' '.

m issingrem ot esnap

– The snapshot _onam e param et er does not exist at t he 23361 rem ot e m ast er sit e ( m ast er_sit e param et er) .

snapt abm ism at ch

– The base t able nam e of t he snapshot at t he m ast er sit e 23363 and snapshot sit e do not m at ch.

D BM S_ OFFLI N E_ SN APSH OT.BEGI N _ LOAD

Call t he BEGI N_LOAD procedure from t he new snapshot sit e prior t o im port ing t he SNA P$t able_nam e t ables t hat were export ed from t he m ast er sit e. This call creat es em pt y snapshot s and support ing obj ect s. The specificat ions for t he Oracle7 and Oracle8 versions differ as follows. Oracle7 specificat ion: PROCEDURE DBMS_OFFLINE_SNAPSHOT.BEGIN_LOAD (gname IN VARCHAR2, sname IN VARCHAR2, master_site IN VARCHAR2, snapshot_oname IN VARCHAR2, storage_c IN VARCHAR2 := '', comment IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_OFFLINE_SNAPSHOT.BEGIN_LOAD (gname IN VARCHAR2, sname IN VARCHAR2, master_site IN VARCHAR2, snapshot_oname IN VARCHAR2, storage_c IN VARCHAR2 := '', comment IN VARCHAR2 := '', min_communication IN BOOLEAN := TRUE ); The BEGI N_LOAD procedure does not raise any except ions.

398

Oracle Distributed Systems

Pa r a m e t e r s Parameter Name

Description

gnam e

The replicat ion group t o which t he new snapshot belongs.

snam e

The schem a t hat owns t he new snapshot .

m ast er_sit e

The global nam e of t he snapshot m ast er sit e.

snapshot _onam e

The nam e of t he t em porary snapshot creat ed at t he m ast er sit e.

st orage_c

Opt ional st orage clause for t he new snapshot .

com m ent

Opt ional com m ent for t he snapshot ; st ored wit h ent ry in DBA_SNAPSHOTS if supplied.

The m in_com m unicat ion param et er cont rols how t he updat e t rigger on updat eable snapshot queues changes back t o t he m in_com m unicat ion m ast er sit e. I f t his param et er is set t o TRUE ( t he default ) , t hen old colum n values are sent only if t he updat e changes t heir value. New colum n values are sent only if t he colum n is part of ( Oracle8 only) t he prim ary key or if t he colum n is in a colum n group t hat has been m odified.

Re st r ict ion s This procedure m ust be run from t he new snapshot sit e prior t o im port ing t he replicat ed schem a.

D BM S_ OFFLI N E_ SN APSH OT.EN D _ LOAD

Call t he END_LOAD procedure aft er t he dat a im port ( init iat ed by t he BEGI N_LOAD procedure) is com plet e. Upon successful com plet ion, t he new snapshot is inst ant iat ed and operat ional. The specificat ion is t he sam e for Oracle7 and Oracle8: PROCEDURE DBMS_OFFLINE_SNAPSHOT.END_LOAD (gname IN VARCHAR2, sname IN VARCHAR2, snapshot_oname IN VARCHAR2); Param et ers have t he sam e m eanings as for t he BEGI N_LOAD procedure. The END_LOAD procedure does not raise any except ions.

Re st r ict ion s This procedure m ust be run from t he new snapshot sit e aft er im port ing t he replicat ed schem a.

399

Oracle Distributed Systems

A.6 D BM S_ RECTI FI ER_ D I FF: Com pa r ing Re plica t e d Ta ble s I f you are not sure whet her t he dat a at t wo sit es are ident ical, you can use t he DBMS_RECTI FI ER_DI FF package t o find out .

A.6 .1 H ow t h e Pa ck a ge I s Use d The DBMS_RECTI FI ER_DI FF’s DI FFERENCES procedure com pares t wo inst ant iat ions of a t able. The t able at one of t wo sit es is considered t he reference, or “ t rut h” t able, and t he ot her is t he “ com parison” t able. The procedure st ores discrepancies bet ween t he t rut h t able and com parison t able in a “ m issing rows” t able, which t he user m ust creat e. I f differences exist , t he DBA can use t he RECTI FY procedure t o synchronize t he com parison t able wit h t he t rut h t able. The t rut h t able is not m odified.

A.6 .2 I n st a lla t ion a n d Acce ss The DBMS_RECTI FI ER_DI FF package is creat ed when t he Oracle dat abase is inst alled. The dbm srepc.sql script ( found in t he built - in packages source direct ory) cont ains t he source code for t his package’s specificat ion. This script is called by cat rep.sql, which m ust be run t o inst all t he advanced replicat ion packages. The wrapped SQL script prvt rct f.sql creat es t he public synonym DBMS_RECTI FI ER_DI FF. No EXECUTE privileges are grant ed on DBMS_RECTI FI ER_DI FF; only t he owner ( SYS) and t hose wit h t he EXECUTE ANY PROCEDURE syst em privilege m ay execut e t he package.

A.6 .3 D BM S_ RECTI FI ER_ D I FF Pr oce du r e s Procedure Name

Description

DI FFERENCES

Det erm ines differences bet ween t he t rut h t able and t he com parison t able

RECTI FY

Synchronizes t he com parison t able wit h t he t rut h t able

A.6 .4 D BM S_ RECTI FI ER_ D I FF Ex ce pt ion s Exception Name

Number

Description

badm rnam e

– Trut h t able and m issing rows t able are t he sam e. 23377

badnam e

– snam e, onam e, m issing_rows_snam e, or 23368 m issing_rows_onam e is NULL or ''.

badnum ber

– m ax_m issing is less t han 1 or NULL. 23366

cannot benull

– m ax_m issing is NULL. 23369

dbm s_repcat .com m failure

– Rem ot e sit e is not accessible. 23302

dbm s_repcat .m issingobj ect

One or m ore of t he t ables onam e1, onam e2, – m issing_rows_onam e1, or m issing_rows_onam e2 23308 do not exist .

dbm s_repcat .norepopt ion

–

Replicat ion opt ion is not linked t o kernel.

400

Oracle Distributed Systems

02094 m issingprim arykey

colum n_list does not cont ain t he t able’s prim ary – keys. I f m ult iple colum ns const it ut e t he prim ary 23367 key, t hen all colum ns m ust be specified in colum n_list .

nosuchsit e

– reference_sit e, com parison_sit e, or 23365 m issing_rows_sit e does not nam e a sit e.

not shapeequivalent

Colum ns specified in colum n_list are not t he – sam e for snam e1.onam e1 at sit e reference_sit e 23370 and snam e2.onam e2 at sit e com parison_sit e.

unknowncolum n

– Colum ns specified in colum n_list do not exist in 23371 snam e1.onam e1 and/ or snam e2.onam e2.

unsupport edt ype

– colum n_list cont ains colum ns of t ype LONG, 23372 LONG RAW, or MLSLABEL.

D BM S_ RECTI FI ER_ D I FF.D I FFEREN CES

The DI FFERENCES procedure com pares t he dat a in a t able at a m ast er sit e wit h t he sam e t able at a reference sit e. The reference sit e need not be t he m ast er definit ion sit e. The procedure st ores discrepancies bet ween t he reference t able and com parison t able in a “ m issing rows” t able, which t he user m ust creat e. I t populat es t he t able specified by t he m issing_rows_onam e1 param et er wit h rows t hat exist in t he reference t able but not t he com parison t able and rows t hat exist in t he com parison t able but not t he reference t able. The t able ident ified by t he m issing_rows_onam e2 param et er has one record for every record in m issing_rows_onam e1, which ident ifies which sit e has t he record. PROCEDURE DBMS_RECTIFIER_DIFF.DIFFERENCES (sname1 IN VARCHAR2, oname1 IN VARCHAR2, reference_site IN VARCHAR2 := '', sname2 IN VARCHAR2, oname2 IN VARCHAR2, comparison_site IN VARCHAR2 := '', where_clause IN VARCHAR2 := '', {column_list IN VARCHAR2 := '' | array_columns IN dbms_utility.name_array,}, missing_rows_sname IN VARCHAR2, missing_rows_oname1 IN VARCHAR2, missing_rows_oname2 IN VARCHAR2, missing_rows_site IN VARCHAR2 := '', max_missing IN INTEGER, commit_rows IN INTEGER := 500); This procedure can t ake a long t im e t o run and only ident ifies differences, which t hen need t o be processed wit h DBMS_RECTI FI ER_DI FF.RECTI FY. I f t he volum e of dat a is

401

Oracle Distributed Systems significant , it will probably be easier for you t o sim ply reinst ant iat e t he com parison t able by im port ing an export of t he reference t able.

Pa r a m e t e r s Parameter Name snam e1

Description Nam e of t he schem a t hat owns onam e1.

onam e1

Table at t he reference sit e ( t rut h t able) .

reference_sit e

The global nam e of sit e wit ht he t rut h t able. I f NULL or '' ( default ) , t he t rut h t able is assum ed t o be local.

snam e2

Nam e of t he schem a t hat owns onam e2.

onam e2

The com parison t able.

com parison_sit e

The global nam e of t he sit e wit h com parison t able. I f NULL or ' ', t able is assum ed t o be local.

where_clause

Opt ional predicat e t hat can be used t o lim it set of rows com pared ( e.g.,WHERE STATE = 'CA') .

colum n_list

Com m a- separat ed list of one or m ore colum ns whose values are t o be com pared. I f NULL or ' ' ( default ) , t hen all colum ns are used. There should not be any whit espace aft er t he com m as.

array_colum ns

PL/ SQL t able of colum n nam es; eit her colum n_list or array_colum ns can be passed, not bot h.

m issing_rows_snam e

Nam e of schem a t hat owns m issing_rows_onam e1.

m issing_rows_onam e1

Nam e of t able cont aining records t hat do not exist in bot h t he t rut h t able and t he com parison t able.

m issing_rows_onam e2

Table t hat holds inform at ion t elling which t able owns each record in m issing_rows_onam e1.

m issing_rows_sit e

The global nam e of sit e where t ables m issing_rows_onam e1 and m issing_rows_onam e2 exist ; if NULL or ' ' ( default ) , t ables are assum ed t o be local.

m ax_m issing

The m axim um num ber of rows t o insert int o m issing_rows_onam e1 before exit ing; it can be any value > 1.

com m it _rows

Com m it rows insert ed int o m issing_rows_onam e1 aft er t his m any records.

Ex ce pt ion s Exception Name

Number

Description

badm rnam e

– onam e1 is t he sam e as m issing_rows_onam e1. 23377

badnam e

– 23368

snam e, onam e, m issing_rows_snam e, or m issing_rows_onam e is NULL or ' '.

badnum ber

– m ax_m issing is less t han 1 or NULL. 23366

dbm s_repcat .com m failure

– Rem ot e sit e is not accessible. 23302

402

Oracle Distributed Systems

dbm s_repcat .m issingobj ect

One or m ore of t he t ables onam e1, onam e2, – m issing_rows_onam e1, or m issing_rows_onam e2 23308 does not exist .

nosuchsit e

– reference_sit e, com parison_sit e, or 23365 m issing_rows_sit e does not nam e a sit e.

Re st r ict ion s • •

•

You m ust creat e t ables nam ed in t he form m issing_rows_snam e.m issing_rows_onam e1 and m issing_rows_snam e.m issing_rows_onam e2 before running t his procedure. The colum ns in t able m issing_rows_onam e1 m ust m at ch t he colum ns passed t o colum n_list or array_colum ns exact ly. The replicat ion group t o which t he t ables belong m ust be quiesced.

D BM S_ RECTI FI ER_ D I FF.RECTI FY

The DI FFERENCES procedure paves t he way for it s com panion procedure, RECTI FY, which synchronizes t he reference t able ( onam e1) . Before running t he RECTI FY procedure, always m ake sure t hat t he updat es t o t he com parison t able ( onam e2) will not violat e any int egrit y, check, or NOT NULL const raint s. Not e t hat t his procedure does not m odify t he reference t able. The DI FFERENCES and RECTI FY procedures can t ake a long t im e t o run. I f t he volum e of dat a is significant , it will probably be easier for you t o sim ply reinst ant iat e t he com parison t able by im port ing an export of t he reference t able. PROCEDURE DBMS_RECTIFIER_DIFF.RECTIFY (sname1 IN VARCHAR2, oname1 IN VARCHAR2, reference_site IN VARCHAR2 := '', sname2 IN VARCHAR2, oname2 IN VARCHAR2, comparison_site IN VARCHAR2 := '', {column_list IN VARCHAR2 := '' | array_columns IN dbms_utility.name_array}, missing_rows_sname IN VARCHAR2, missing_rows_oname1 IN VARCHAR2, missing_rows_oname2 IN VARCHAR2, missing_rows_site IN VARCHAR2 := '', commit_rows IN INTEGER := 500);

Pa r a m e t e r s Parameter Name

Description

snam e1

Nam e of t he schem a t hat owns onam e1.

onam e1

Table at t he reference_sit e ( t rut h t able) .

403

Oracle Distributed Systems

reference_sit e

The global nam e of t he sit e wit h t rut h t able; if NULL or ' ' ( default ) , t he t rut h t able is assum ed t o be local.

snam e2

Nam e of t he schem a t hat owns onam e2.

onam e2

The com parison t able.

com parison_sit e

The global nam e of t he sit e wit h com parison t able. I f NULL or ' ', t able is assum ed t o be local.

colum n_list

A com m a- separat ed list of one or m ore colum ns whose values are t o be com pared; if NULL or ' ' ( default ) , t hen all colum ns are used. There should not be any whit espace aft er t he com m as.

array_colum ns

PL/ SQL t able of colum n nam es; eit her colum n_list or array_colum ns can be passed, not bot h.

m issing_rows_snam e

Nam e of t he schem a t hat owns m issing_rows_onam e1.

m issing_rows_onam e1

The nam e of t he t able cont aining records t hat do not exist in bot h t he t rut h t able and t he com parison t able.

m issing_rows_onam e2

The t able t hat holds inform at ion t elling which t able owns each record in m issing_rows_onam e1.

m issing_rows_sit e

The global nam e of t he sit e where t ables m issing_rows_onam e1 and m issing_rows_onam e2 exist ; if NULL or ' ' ( default ) , t ables are assum ed t o be local.

com m it _rows

Com m it rows insert ed int o m issing_row_onam e1 aft er t his m any records.

Ex ce pt ion s Exception Name

Number

Description

badnam e

– snam e, onam e, m issing_rows_snam e, or 23368 m issing_rows_onam e is NULL or ' '.

badnum ber

– m ax_m issing is less t han 1 or NULL. 23366

dbm s_repcat .com m failure

– Rem ot e sit e is not accessible. 23302

dbm s_repcat .m issingobj ect

The t able onam e1, onam e2, – m issing_rows_onam e1, or m issing_rows_onam e2 23308 does not exist .

dbm s_repcat .norepopt ion

–2094 Replicat ion opt ion is not linked t o kernel.

nosuchsit e

– reference_sit e, com parison_sit e, or 23365 m issing_rows_sit e does not nam e a sit e.

Re st r ict ion s • • •

•

The DI FFERENCES procedure m ust have been run prior t o running RECTI FY. The replicat ion group t o which t he t ables belong should st ill be quiesced. I f duplicat e rows exist in t he reference t able but not t he com parison t able, t hey will be insert ed int o t he com parison t able. I f duplicat e rows exist in t he com parison t able but not t he reference t able, t hey will be delet ed from t he com parison t able.

404

Oracle Distributed Systems

A.7 D BM S_ REFRESH : M a n a gin g Sn a psh ot Gr oups The DBMS_REFRESH package cont ains procedures for adm inist ering snapshot groups.

A.7 .1 H ow t h e Pa ck a ge I s Use d A snapshot group is a collect ion of one or m ore snapshot s t hat Oracle refreshes in an at om ic t ransact ion, guarant eeing t hat relat ionships am ong t he m ast er t ables are preserved in t he snapshot t ables.

A.7 .2 I n st a lla t ion a n d Acce ss The DBMS_REFRESH package is creat ed when t he Oracle dat abase is inst alled. The dbm ssnap.sql script ( found in t he built - in packages source direct ory) cont ains t he source code for t his package’s specificat ion. This script is called by cat proc.sql, which is norm ally run im m ediat ely aft er dat abase creat ion. The script creat es t he public synonym DBMS_REFRESH for t he package and grant s t he EXECUTE privilege on t he package t o public. All Oracle users can reference and m ake use of t his package.

A.7 .3 D BM S_ REFRESH Pr oce du r e s Procedure Name

Description

ADD

Adds one or m ore snapshot s t o an exist ing refresh group

CHANGE

Changes param et ers associat ed wit h a refresh group

DESTROY

Rem oves a refresh group

MAKE

Creat es a refresh group

REFRESH

Forces a refresh of a refresh group

SUBTRACT

Rem oves one or m ore snapshot s from a refresh group

DBMS_REFRESH does not define any except ions.

A.7 .4 D BM S_ REFRESH N on pr ogr a m Ele m e n t s Element Name/Type aaspriv/ BI NARY I NTEGER

Description Privilege num ber for ALTER ANY SNAPSHOT syst em privilege ( 107)

D BM S_ REFRESH .AD D

Call t he ADD procedure t o add one or m ore snapshot s t o all exist ing snapshot groups or m ove a snapshot from one group t o anot her. PROCEDURE DBMS_REFRESH.ADD (name IN VARCHAR2, {list IN VARCHAR2,| tab IN dbms_utility.uncl_array,} lax IN BOOLEAN DEFAULT FALSE );

405

Oracle Distributed Systems A snapshot group cannot have m ore t han 100 m em bers. I n bot h Oracle7 and Oracle8, t he ADD procedure is overloaded; you can supply t he list of snapshot s eit her as a com m a- separat ed st ring wit h t he list param et er, or as a PL/ SQL t able wit h t he t ab param et er. You m ust select eit her t he list or t ab param et er, but not bot h.

Pa r a m e t e r s Parameter Name

Description

nam e

Nam e of t he refresh group t o creat e.

list

A com m a- delim it ed st ring of snapshot s t o include in t he new refresh group. Use eit her list or t ab t o specify t he snapshot ( s) you want t o add.

t ab

A PL/ SQL t able of snapshot s t o include in t he new refresh group. Use eit her list or t ab t o specify t he snapshot ( s) you want t o add.

lax

I f set t o TRUE and t he snapshot s already exist in a refresh group ot her t han nam e, t he snapshot s are first rem oved from t he ot her group.

Ex ce pt ion s Exception Name/Type aaspriv/ BI NARY I NTEGER

Description Privilege num ber for ALTER ANY SNAPSHOT syst em privilege

Re st r ict ion s • • •

This procedure m ust be run from t he snapshot sit e. A snapshot cannot belong t o m ore t han one refresh group. I f you want t o m ove a snapshot from one refresh group t o anot her, t he lax param et er m ust be set t o TRUE, which is not t he default .

D BM S_ REFRESH .CH AN GE

The CHANGE procedure allows you t o m odify set t ings associat ed wit h a snapshot group. You can change m ost of t he param et ers t hat are available in ADD. The specificat ions for CHANGE differ for Oracle7 and Oracle8 as follows. Not e t hat t he difference bet ween t he Oracle7 and Oracle8 CHANGE specificat ions is t he inclusion of support for parallel propagat ion and purging in t he Oracle8 version. Oracle7 specificat ion: PROCEDURE DBMS_REFRESH.CHANGE (name IN VARCHAR2, next_date IN DATE DEFAULT NULL,

406

Oracle Distributed Systems interval IN VARCHAR2 DEFAULT NULL, implicit_destroy IN BOOLEAN DEFAULT NULL, rollback_seg IN VARCHAR2 DEFAULT NULL, push_deferred_rpc IN BOOLEAN DEFAULT NULL, refresh_after_errors IN BOOLEAN DEFAULT NULL); Oracle8 specificat ion: PROCEDURE DBMS_REFRESH.CHANGE (name IN VARCHAR2, next_date IN DATE := NULL, interval IN VARCHAR2 := NULL, implicit_destroy IN BOOLEAN := NULL, rollback_seg IN VARCHAR2 := NULL, push_deferred_rpc IN BOOLEAN := NULL, refresh_after_errors IN BOOLEAN := NULL, purge_option IN BINARY_INTEGER := NULL, parallelism IN BINARY_INTEGER := NULL, heap_size IN BINARY_INTEGER := NULL); Refer t o t he ADD sect ion for an explanat ion of t hese param et ers.

Ex ce pt ion s Exception Name ORA- 23404

Number –23404

Description Refresh group nam e does not exist .

Re st r ict ion s This procedure m ust be run from t he snapshot sit e.

D BM S_ REFRESH .D ESTROY

Call t he DESTROY procedure t o dest roy a snapshot group. For bot h Oracle7 and Oracle8, you call DESTROY as follows: PROCEDURE DBMS_REFRESH.DESTROY (name IN VARCHAR2); nam e is t he nam e of t he snapshot group t o be dest royed.

Ex ce pt ion s Exception Name ORA- 23404

Number –23404

Description Refresh group nam e does not exist .

407

Oracle Distributed Systems

Re st r ict ion s This procedure m ust be run from t he snapshot sit e.

D BM S_ REFRESH .M AKE

Call t he MAKE procedure t o creat e a snapshot group. The specificat ions for t he Oracle7 and Oracle8 versions differ as follows. Oracle7 specificat ion: PROCEDURE DBMS_REFRESH.MAKE (name IN VARCHAR2, {list IN VARCHAR2, | tab IN dbms_utility.uncl_array,} next_date IN DATE, interval IN VARCHAR2, implicit_destroy IN BOOLEAN DEFAULT FALSE, lax IN BOOLEAN DEFAULT FALSE, job IN BINARY_INTEGER DEFAULT 0, rollback_seg IN VARCHAR2 DEFAULT NULL, push_deferred_rpc IN BOOLEAN DEFAULT TRUE, refresh_after_errors IN BOOLEAN DEFAULT FALSE ); Oracle8 specificat ion: PROCEDURE DBMS_REFRESH.MAKE (name IN VARCHAR2, {list IN VARCHAR2, | tab IN dmbs_utility.uncl_array,} next_date IN DATE, interval IN VARCHAR2, implicit_destroy IN BOOLEAN := FALSE, lax IN BOOLEAN := FALSE, job IN BINARY_INTEGER := 0, rollback_seg IN VARCHAR2 := NULL, push_deferred_rpc IN BOOLEAN := TRUE, refresh_after_errors IN BOOLEAN := FALSE, purge_option IN BINARY_INTEGER := 1, parallelism IN BINARY_INTEGER := 0, heap_size IN BINARY_INTEGER := 0); The MAKE procedure does not raise any except ions.

Pa r a m e t e r s Parameter Name

Description

nam e

Nam e of t he refresh group t o creat e.

list

A com m a- delim it ed st ring of snapshot s t o include in t he new refresh group. Use eit her list or t ab t o specify t he snapshot ( s)

408

Oracle Distributed Systems

you want t o add. t ab

A PL/ SQL t able of snapshot s t o include in t he new refresh group. Use eit her list or t ab t o specify t he snapshot ( s) you want t o add.

next _dat e

The t im e of t he next refresh.

int erval

A DATE expression indicat ing t he snapshot group’s refresh int erval.

im plicit _dest roy

I f set t o TRUE, t he snapshot group is dest royed if all snapshot s are rem oved from it .

lax

I f set t o TRUE and t he snapshot ( s) already exist in a refresh group ot her t han nam e, t he snapshot ( s) are first rem oved from t he ot her group.

j ob

Used by im port ut ilit y. Always use default value of 0.

rollback_seg

Specifies t he rollback segm ent t o use during snapshot refreshes. I f set t o NULL, t he default rollback segm ent is used.

push_deferred_rpc

For updat eable snapshot s only. Set t ing t his param et er t o TRUE indicat es t hat local updat es will be pushed back t o t he m ast er sit e ( ot herwise, local updat es will not be visible during t he refresh) .

For updat eable snapshot s only. Set t ing t his param et er t o TRUE refresh_aft er_errors indicat es t hat refreshes should occur even if errors exist in t he DEFERROR dat a dict ionary view. purge_opt ion ( Oracle8 only)

parallelism ( Oracle8 only)

heap_size ( Oracle8 only)

I f push_deferred_rpc is TRUE, t his designat es t he purge m et hod; default is 1. 0 = no purge 1 = lazy purge ( opt im ized for t im e) 2 = aggressive purge ( com plet e) I f push_deferred_rpc is TRUE, t his det erm ines t he m axim um degree of parallelism ; default is 1. 0 = serial 1 = parallel wit h 1 slave n = parallel wit h n slaves ( n > 1) Used only if parallelism > 0. Set s t he m axim um num ber of t ransact ions t o be exam ined sim ult aneously for det erm ining parallel scheduling. Oracle det erm ines t his value int ernally; you are advised not t o use it .

Re st r ict ion s This procedure m ust be run from t he snapshot sit e.

D BM S_ REFRESH .REFRESH

409

Oracle Distributed Systems Call REFRESH t o refresh a snapshot group. A call t o REFRESH causes all m em bers of snapshot group nam e t o be refreshed wit h t he set t ings t hat you have designat ed in MAKE and/ or CHANGE. PROCEDURE DBMS_REFRESH.REFRESH (name IN VARCHAR2); nam e ident ifies t he snapshot group.

Ex ce pt ion s Exception Name ORA- 23404

Number –23404

Description Refresh group nam e does not exist .

Re st r ict ion s This procedure m ust be run from t he snapshot sit e.

D BM S_ REFRESH .SUBTRACT

Call t he SUBTRACT procedure t o subt ract a snapshot group. PROCEDURE DBMS_REFRESH.SUBTRACT (name IN VARCHAR2, {list IN VARCHAR2,| tab IN dbms_utility.uncl_array,} lax IN BOOLEAN DEFAULT FALSE ); The param et ers for t heSUBTRACT procedure have t he sam e m eaning as in t he ADD procedure; refer t o t he param et er t able in t hat sect ion. Not e t hat you m ust select t he list or t ab param et er, but not bot h.

Ex ce pt ion s Exception Name ORA- 23404

Number –23404

Description Refresh group nam e does not exist .

Re st r ict ion s This procedure m ust be run from t he snapshot sit e.

A.8 D BM S_ REPCAT: Pe r for m in g Re plica t ion Adm in ist r a t ion The DBMS_REPCAT package is t he foundat ion of t he replicat ion API . I t allows you t o perform a wide variet y of operat ions in several cat egories: advanced replicat ion adm inist rat ion, snapshot s, and conflict resolut ion.

410

Oracle Distributed Systems

A.8 .1 H ow t h e Pa ck a ge I s Use d DBMS_REPCAT cont ains t he procedures required t o m aint ain t he following aspect s of a replicat ed environm ent : • • • • • • • •

Sit e priorit y inform at ion Colum n group configurat ion Priorit y group configurat ion Conflict resolut ion t echniques Snapshot propagat ion Obj ect replicat ion support St at ist ics Mast er sit e configurat ion

A.8 .2 I n st a lla t ion a n d Acce ss The DBMS_REPCAT package is creat ed when t he Oracle dat abase is inst alled. The dbm srepc.sql script ( found in t he built - in packages source direct ory) cont ains t he source code for t his package’s specificat ion. This script is called by cat rep.sql, which m ust be run t o inst all t he advanced replicat ion packages. The script creat es t he public synonym DBMS_REPCAT. The package procedure DBMS_REPCAT_AUTH.GRANT_SURROGATE_REPCAT grant s EXECUTE privileges on t he package t o t he specified grant ee. I n addit ion, t he package owner ( SYS) and users wit h t he EXECUTE ANY PROCEDURE syst em privilege m ay execut e it .

A.8 .3 D BM S_ REPCAT Pr oce du r e s Procedure Name

Description

ADD_conflict t ype_RESOLUTI ON

Adds a cust om conflict resolut ion handler for updat e, delet e, or uniqueness conflict s.

ADD_GROUPED_COLUMN

Adds t able colum n( s) t o an exist ing colum n group.

ADD_MASTER_DATABASE

Adds a m ast er dat abase t o a replicat ion group.

ADD_PRI ORI TY_dat at ype

Adds a m em ber t o an exist ing priorit y group.

ADD_SI TE_PRI ORI TY_SI TE

Adds a sit e t o an exist ing sit e priorit y group.

ALTER_MASTER_PROPAGATI ON

Alt ers t he propagat ion m et hod for a replicat ion group at a given sit e. Opt ions are SYNCHRONOUS or ASYNCHRONOUS.

ALTER_MASTER_REPOBJECT

Perform s DDL on a replicat ed obj ect .

ALTER_PRI ORI TY

Changes priorit y level for a m em ber of a priorit y group.

ALTER_PRI ORI TY_dat at ype

Alt ers t he value of a m em ber of a priorit y group.

ALTER_SI TE_PRI ORI TY

Alt ers priorit y level of a sit e.

ALTER_SI TE_PRI ORI TY_SI TE

Designat es a sit e t o a given priorit y level.

ALTER_SNAPSHOT_PROPAGATI ON

Alt ers t he propagat ion m et hod for a replicat ion group at a snapshot sit e.

CANCEL_STATI STI CS

Cancels collect ion of st at ist ics about conflict

411

Oracle Distributed Systems

resolut ion for a t able. COMMENT_ON_conflict t ype_ RESOLUTI ON

Creat es a com m ent on a conflict resolut ion m et hod, visible in DBA_REPRESOLUTI ON dat a dict ionary view.

COMMENT_ON_COLUMN_GROUP

Creat es or updat es a com m ent on a colum n group, visible in DBA_REPCOLUMN_GROUP dat a dict ionary view.

COMMENT_ON_PRI ORI TY_GROUP

Creat es or updat es com m ent on a priorit y group, visible in DBA_REPPRI ORI TY_GROUP.

COMMENT_ON_REPGROUP

Creat es or updat es a com m ent on a replicat ion group, visible in DBA_REPGROUP dat a dict ionary view.

COMMENT_ON_REPOBJECT

Creat es or updat es a com m ent on a replicat ed obj ect , visible in DBA_REPOBJECT dat a dict ionary view.

COMMENT_ON_REPSI TES

Creat es or updat es a com m ent on a replicat ion sit e, visible in DBA_REPSI TES dat a dict ionary view.

COMMENT_ON_SI TE_PRI ORI TY

Creat es or updat es a com m ent on a sit e priorit y, visible in DBA_REPRI ORI TY_GROUP dat a dict ionary view.

CREATE_MASTER_REPGROUP

Creat es a m ast er replicat ion group.

CREATE_MASTER_REPOBJECT

Adds an obj ect t o a replicat ion group.

CREATE_SNAPSHOT_REPGROUP

Creat es a snapshot replicat ion group.

CREATE_SNAPSHOT_REPOBJECT

Adds an obj ect t o a snapshot replicat ion group.

DEFI NE_COLUMN_GROUP

Creat es an em pt y colum n group for a replicat ion group.

DEFI NE_PRI ORI TY_GROUP

Creat es a priorit y group for a replicat ion group.

DEFI NE_SI TE_PRI ORI TY

Creat es a sit e priorit y group for a replicat ion group.

DO_DEFERRED_REPCAT_ADMI N

Perform s out st anding adm inist rat ive t asks at local m ast er sit e.

DROP_conflict t ype_RESOLUTI ON

Drops an updat e, delet e, or uniqueness conflict resolut ion handling t echnique from a replicat ion group.

DROP_COLUMN_GROUP

Drops a colum n group from a replicat ion group.

DROP_GROUPED_COLUMN

Drops a colum n from a colum n group.

DROP_MASTER_REPGROUP

Drops a replicat ion group.

DROP_MASTER_REPOBJECT

Drops an obj ect from a replicat ion group.

DROP_PRI ORI TY

Drops a m em ber of a priorit y group, select ed by priorit y level.

DROP_PRI ORI TY_dat at ype

Drops a m em ber of a priorit y group, select ed by value.

DROP_PRI ORI TY_GROUP

Drops a priorit y group from a replicat ion group.

412

Oracle Distributed Systems

DROP_SI TE_PRI ORI TY

Drops a sit e priorit y group from a replicat ion group.

DROP_SI TE_PRI ORI TY_SI TE

Drops a sit e from a sit e priorit y group, select ed by sit e nam e.

DROP_SNAPSHOT_REPGROUP

Drops a snapshot replicat ion group.

DROP_SNAPSHOT_REPOBJECT

Drops an obj ect from a snapshot replicat ion group.

EXECUTE_DDL

Specifies DDL t o execut e at m ast er sit es.

GENERATE_REPLI CATI ON_PACKAGE

Generat es packages required t o replicat e a given t able.

GENERATE_REPLI CATI ON_SUPPORT

Generat es t riggers, packages, and procedures required t o replicat e a given t able.

GENERATE_REPLI CATI ON_TRI GGER

Generat es t riggers and packages required t o replicat e a given t able.

MAKE_COLUMN_GROUP

Creat es a colum n group and adds one or m ore colum ns.

PURGE_MASTER_LOG

Delet es ent ries from t he local repcat log ( DBA_REPCATLOG) .

PURGE_STATI STI CS

Delet es ent ries from t he DBA_REPRESOLUTI ON_STATI STI CS dat a dict ionary view.

REFRESH_SNAPSHOT_REPGROUP

Refreshes a snapshot replicat ion group.

REGI STER_STATI STI CS

St art s collect ion of st at ist ics for t he resolut ion of updat e, delet e, and uniqueness conflict s for a given t able.

RELOCATE_MASTERDEF

Changes t he m ast er definit ion sit e for a replicat ion group.

REMOVE_MASTER_DATABASES

Drops one or m ore m ast er dat abases from a replicat ion group.

REPCAT_I MPORT_CHECK

Confirm s a replicat ed obj ect ’s validit y aft er an im port .

RESUME_MASTER_ACTI VI TY

Enables propagat ion of a replicat ion group t hat had been quiesced.

Avoids sending unchanged values when SEND_AND_COMPARE_OLD_VALUES propagat ion updat es t o part icipat ing m ast er sit es. SET_COLUMNS

Designat es alt ernat ive colum n( s) t o use inst ead of a prim ary t o uniquely ident ify rows of a replicat ed t able.

SUSPEND_MASTER_ACTI VI TY

Quiesces a replicat ion group.

SWI TCH_SNAPSHOT_MASTER

Rem ast ers a snapshot sit e t o anot her m ast er sit e.

VALI DATE

Diagnoses t he st at us of your replicat ed environm ent .

WAI T_MASTER_LOG

Det erm ines whet her asynchronous DML has been applied at a m ast er sit e.

413

Oracle Distributed Systems

A.8 .4 D BM S_ REPCAT Ex ce pt ion s Exception Name

Number

Description

badsnapnam e

– I nvalid snapshot nam e ( used int ernally) . 23328

com m failure

– Unable t o com m unicat e wit h rem ot e sit e. 23317

corrupt

– Corrupt ion occurred ( used int ernally during generat ion 23320 of replicat ion support obj ect s) .

dbnot com pat ible

– Operat ion not available for current version of RDBMS. 23375

ddlfailure

– DDL failed during obj ect creat ion or m aint enance 23318 act ivit y.

duplicat ecolum n

– At t em pt t o add duplicat e colum n t o colum n group. 23333

duplicat egroup

– At t em pt t o add duplicat e colum n group t o a replicat ed 23330 t able.

duplicat eobj ect

– Replicat ed obj ect already exist s. 23309

duplicat epriorit ygroup

– At t em pt t o creat e duplicat e priorit y group. 23335

duplicat erepgroup

– At t em pt t o creat e duplicat e snapshot replicat ion 23374 group.

duplicat eresolut ion

– At t em pt t o creat e duplicat e resolut ion m et hod. 23339

duplicat eschem a

– At t em pt t o creat e duplicat e replicat ion group. 23307

duplicat evalue

– At t em pt t o creat e duplicat e value in a priorit y group. 23338

fullqueue

– At t em pt t o drop replicat ion group or schem a for which 23353 RPC ent ries are queued.

invalidm et hod

– At t em pt t o use nonexist ent conflict resolut ion m et hod. 23340

invalidparam et er

– I nvalid num ber of colum ns in call t o 23342 ADD_UNI QUE_RESOLUTI ON.

invalidpropm ode

– I nvalid propagat ion m ode ( used int ernally) . 23380

invalidqualifier

– I nvalid qualifier ( used int ernally) . 23378

m ast ernot rem oved

– Mast er sit e not rem oved ( used int ernally) . 23356

m issingcolum n

– Reference t o nonexist ent colum n. 23334

m issingconst raint

– Missing const raint ( used int ernally) . 23344

m issingfunct ion

– User funct ion does not exist . 23341

414

Oracle Distributed Systems

m issinggroup

– Colum n group does not exist . 23331

m issingobj ect

– Obj ect does not exist as a t able. 23308

m issingpriorit ygroup

– Priorit y group does not exist . 23336

m issingrem ot eobj ect

– Mast er obj ect has not had replicat ion support 23381 generat ed.

m issingrepgroup

– Replicat ion group does not exist . 23373

m issingresolut ion

– Referenced conflict resolut ion m et hod does not exist . 23343

m issingschem a

– Schem a does not exist . 23306

m issingvalue

– Missing value ( used int ernally) . 23337

m isssnapobj ect

– Snapshot obj ect does not exist . 23355

nonm ast er

– Sit e is not a m ast er sit e. 23313

nonm ast erdef

– Sit e is not a m ast er definit ion sit e. 23312

nonsnapshot

– Sit e is not a snapshot sit e. 23314

norepopt ion

– Replicat ion opt ion not inst alled. 23364

not norm al

– Replicat ion group is not in norm al propagat ion m ode. 23311

not quiesced

– Replicat ion group is not quiesced. 23310

onlyonesnap

– Only one snapshot ( used int ernally) . 23360

param t ype

– I nvalid param et er t ype ( used int ernally) . 23325

qualifiert oolong

– Qualifier param et er t oo long ( used int ernally) . 23379

reconfigerror

– At t em pt t o drop m ast er definit ion sit e wit h 23316 REMOVE_MASTER_DATABASES.

referenced

– At t em pt t o drop colum n group used for conflict 23332 resolut ion.

repnot com pat ible

– Replicat ion versions not com pat ible ( used int ernally) . 23376

st at not reg

– Conflict resolut ion st at ist ics not regist ered ( used 23345 int ernally) .

t ypefailure

– At t em pt t o replicat e nonsupport ed dat at ype. 23319

version

–

Replicat ion versions not com pat ible ( used int ernally) .

415

Oracle Distributed Systems

23315

A.8 .5 D BM S_ REPCAT N on pr ogr a m Ele m e n t s I n addit ion t o program s and except ions, t he DBMS_REPCAT package defines t he VARCHAR2S const ant . This is a PL/ SQL t able of VARCHAR2( 60) indexed by BI NARY I NTEGER. This t ype can be used t o supply a list of colum n nam es t o t he following procedures: ADD_GROUPED_COLUMN

ADD_UPDATE_RESOLUTI ON

MAKE_COLUMN_GROUP

ADD_DELETE_RESOLUTI ON

DROP_COLUMN_GROUP

ADD_UNI QUE_RESOLUTI ON

A.8 .6 D BM S_ REPCAT.AD D _ con flict t ype _ RESOLUTI ON The ADD_conflict t ype_RESOLUTI ON procedure adds a built - in or user- defined conflict resolut ion t ype t o a t able. The value of conflict t ype can be UPDATE, UNI QUE, or DELETE. The built - in conflict resolut ion t ypes for updat e conflict s are t he following: • • • • • • • • • •

Minim um Value Maxim um Value Lat est Tim est am p Earliest Tim est am p Addit ive Average Priorit y Group Sit e Priorit y Overwrit e Discard

The built - in conflict resolut ion m et hods for uniqueness conflict s are as follows: • • •

Append Sit e Nam e Append Sequence Num ber Discard

Oracle does not provide any conflict resolut ion t echniques for delet e conflict s. Here are t he specificat ions: PROCEDURE DBMS_REPCAT.ADD_UPDATE_RESOLUTION (sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, sequence_no IN NUMBER, method IN VARCHAR2, {parameter_column_name IN dbms_repcat.varchar2s,| parameter_column_name IN VARCHAR2,}

416

Oracle Distributed Systems priority_group IN VARCHAR2 := NULL, function_name IN VARCHAR2 := NULL, comment IN VARCHAR2 := NULL); PROCEDURE DBMS_REPCAT.ADD_UNIQUE_RESOLUTION (sname IN VARCHAR2, oname IN VARCHAR2, constraint_name IN VARCHAR2, sequence_no IN NUMBER, method IN VARCHAR2, {parameter_column_name IN dbms_repcat.varchar2s, | parameter_column_name IN VARCHAR2,} comment IN VARCHAR2 := NULL); PROCEDURE DBMS_REPCAT.ADD_DELETE_RESOLUTION (sname IN VARCHAR2, oname IN VARCHAR2, sequence_no IN NUMBER, {parameter_column_name IN dbms_repcat.varchar2s, | parameter_column_name IN VARCHAR2,} function_name IN VARCHAR2 := NULL, comment IN VARCHAR2 := NULL); Always define m ore t han one conflict resolut ion m et hod for a given colum n or priorit y group. No single resolut ion m et hod is com plet ely foolproof.

A.8 .6 .1 Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a cont aining t he replicat ed schem a. Default s t o current user.

onam e

Nam e of t he replicat ed t able.

colum n_group

ADD_UPDATE_RESOLUTI ON only. Colum n group for which t he conflict resolut ion m et hod is being defined.

const raint _nam e

ADD_UNI QUE_RESOLUTI ON only. Nam e of t he const raint nam e or unique index for which t he conflict resolut ion m et hod is being added.

sequence_no

Num ber indicat ing when t his conflict resolut ion m et hod should be applied relat ive t o ot her m et hods defined for t he sam e colum n group or priorit y group. The conflict resolut ion m et hod. Valid values are:

m et hod

Priorit y Group Sit e Priorit y User Funct ion or one of t he built - in t ypes list ed earlier.

param et er_colum n_nam e

Com m a- separat ed list of colum ns t o be used t o resolve t he conflict ( if VARCHAR2) or a PL/ SQL t able of colum n nam es. I f colum n_group is passed, t he colum n( s) passed t o

417

Oracle Distributed Systems

param et er_colum n_nam e m ust be in t he group. An ast erisk ( * ) indicat es t hat all colum ns in t he t able or colum n group should be passed t o t he conflict resolut ion funct ion, in alphabet ical order. priorit y_group

ADD_UPDATE_RESOLUTI ON only. I f using a priorit y group or sit e priorit y group, t he nam e of t he group.

funct ion_nam e

I f designat ing a user- defined conflict resolut ion m et hod, t he nam e of t he user funct ion.

com m ent

Com m ent on t he conflict resolut ion m et hod, visible in t he DBA_REPRESOLUTI ON dat a dict ionary view.

A.8 .6 .2 Ex ce pt ions Exception Name

Number

Description

duplicat esequence

– Resolut ion m et hod already exist s wit h sequence num ber 00001 sequence_no for t his colum n or priorit y group.

invalidm et hod

– Resolut ion m et hod does not exist . 23340

invalidparam et er

– Colum n( s) specified in param et er_colum n_nam e invalid. 23342

m issingcolum n

– Specified colum n( s) do not exist in t able onam e. 23334

m issingconst raint

– Const raint const raint _nam e specified in 23344 ADD_UNI QUE_RESOLUTI ON does not exist .

m issingfunct ion

– User- defined funct ion funct ion_nam e does not exist . 23341

m issinggroup

– colum n_group does not exist . 23331

m issingobj ect

– Table onam e does not exist in t he replicat ion group. 23308

m issingpriorit ygroup

– priorit y_group does not exist . 23336

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

t ypefailure

Dat at ype of one of t he colum ns specified in – param et er_colum n_nam e is not appropriat e for t he 23319 resolut ion m et hod.

A.8 .6 .3 Re st r ict ions • •

You m ust call t his procedure from t he m ast er definit ion sit e. Aft er t his call, you m ust generat e replicat ion support for t he t able passed t o onam e .

D BM S_ REPCAT.AD D _ GROUPED _ COLUM N

418

Oracle Distributed Systems

The ADD_GROUPED_COLUMN procedure adds a m em ber colum n t o a colum n group. You can call t his procedure aft er you have creat ed a new, em pt y colum n group wit h DEFI NE_COLUMN_GROUP or if your schem a or conflict resolut ion requirem ent s change. PROCEDURE DBMS_REPCAT.ADD_GROUPED_COLUMN (sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, {list_of_column_names IN VARCHAR2 | list_of_column_names IN dbms_repcat.varchar2s}); Not e t hat you m ust specify only one of t he list _of_colum n_nam es param et ers.

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t hat owns t he replicat ed t able.

onam e

Nam e of t he t able wit h t he colum n_group.

colum n_group

Nam e of t he colum n_group t o which colum n( s) will be added.

A com m a- delim it ed list of colum n nam es, or a PL/ SQL t able of list _of_colum n_nam es colum n nam es. Use an ast erisk ( * ) t o add all colum ns in t he t able t o t he colum n group.

Ex ce pt ion s Exception Name

Number

Description

duplicat ecolum n

–23333 Colum n( s) specified already exist in colum n_group.

m issingcolum n

–23334 Colum n( s) specified do not exist in t able onam e.

m issinggroup

–23331 Colum n group colum n_group does not exist .

m issingobj ect

–23308 Table onam e does not exist .

m issingschem a

–23306 Schem a snam e does not exist .

nonm ast erdef

–23312 I nvoking sit e is not m ast er definit ion sit e.

Re st r ict ion s • •

You m ust call t his procedure from t he quiesced m ast er definit ion sit e. You m ust regenerat e replicat ion support for t he t able aft er defining t he colum n group wit h t he GENERATE_REPLI CATI ON_SUPPORT procedure.

D BM S_ REPCAT.AD D _ M ASTER_ D ATABASE

419

Oracle Distributed Systems The ADD_MASTER_DATABASE procedure adds a m ast er sit e t o an exist ing replicat ion group and init ializes all obj ect s at t he new sit e. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.ADD_MASTER_DATABASE (gname IN VARCHAR2 := '', master IN VARCHAR2, use_existing_objects IN BOOLEAN := TRUE, copy_rows IN BOOLEAN := TRUE, comment IN VARCHAR2 := '', propagation_mode IN VARCHAR2 := 'ASYNCHRONOUS', sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.ADD_MASTER_DATABASE (gname IN VARCHAR2 := '', master IN VARCHAR2, use_existing_objects IN BOOLEAN := TRUE, copy_rows IN BOOLEAN := TRUE, comment IN VARCHAR2 := '', propagation_mode IN VARCHAR2 := 'ASYNCHRONOUS'); I t is generally easier t o inst ant iat e all obj ect s at t he new m ast er sit e first . That way, t he call t o ADD_MASTER_DATABASE does not have t o perform DDL t o creat e t he schem a or send all of t he dat a across a net work link. I f you inst ant iat e t he obj ect s first , t he call t o ADD_MASTER_DATABASE only has t o generat e replicat ion support for t he obj ect s and updat e ot her m ast er sit es wit h t he new m ast er’s exist ence.

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which m ast er sit e is being added.

m ast er

Global nam e of t he new m ast er sit e.

use_exist ing_obj ect s Reuse exist ing obj ect s at t he new sit e. copy_rows

Copy rows from t he invoking sit e t o t he new m ast er sit e.

com m ent

Com m ent on new m ast er sit e, visible in DBA_REPSI TES dat a dict ionary view.

propagat ion_m ode

Propagat ion m ode ( SYNCHRONOUS or ASYNCHRONOUS) .

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y) .

Ex ce pt ion s Exception Name com m failure

Number

Description

– Sit e m ast er is not reachable. 23317

duplicat eschem a –

Replicat ion group gnam e already exist s at sit e m ast er.

420

Oracle Distributed Systems

23307 – Propagat ion_m ode is not SYNCHRONOUS or invalidpropm ode 23380 ASYNCHRONOUS. m issingrepgroup

– Replicat ion group gnam e does not exist at t he calling sit e. 23373

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

not quiesced

– Replicat ion group gnam e is not quiesced. 23310

repnot com pat ible

– Replicat ion group gnam e does not exist at m ast er, and 23376 m ast er is a pre- 7.3 release.

Re st r ict ion s • •

This procedure m ust be run from t he m ast er definit ion sit e. The replicat ion group m ust be quiesced.

D BM S_ REPCAT.AD D _ PRI ORI TY_ da t a t ype

Each of t he procedures cont aining t he dat at ype suffix act ually has five different versions in Oracle7, one for each of t he dat at ypes CHAR, VARCHAR2, NUMBER, RAW, and DATE. Oracle8 adds support for t wo m ore dat at ypes: NCHAR and NVARCHAR2. The usage of each of t hese packages is ident ical.

The ADD_PRI ORI TY_dat at ype procedure adds a m em ber ( of t he specified dat at ype) t o an exist ing priorit y group. The addit ion of t he new priorit y and value t akes effect im m ediat ely. Values wit h higher num eric priorit ies t ake precedence—t hat is, t he value wit h priorit y 1 has t he lowest priorit y. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.ADD_PRIORITY_datatype (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, value IN {CHAR|VARCHAR2|NUMBER|DATE|RAW, priority IN NUMBER, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.ADD_PRIORITY_datatype

421

Oracle Distributed Systems (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, value IN {CHAR|NCHAR|VARCHAR2|NUMBER|DATE|RAW, priority IN NUMBER) I n t hese specificat ions, dat at ype can be any of t he following, and value can be any of t hese t ypes: Oracle7 and Oracle8

Oracle8 Only

CHAR

NCHAR

VARCHAR2

NVARCHAR2

NUMBER DATE RAW

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which priorit y group pgroup belongs

pgroup

Priorit y group t o which new value and priorit y are being added

value

Lit eral value t hat is being assigned added t o pgroup

priorit y

Priorit y designat ed t o value; it is a good idea t o num ber priorit ies in m ult iples of 10 or m ore so t hat you can easily add new priorit y values lat er as requirem ent s change.

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

duplicat epriorit y

– Anot her value is already designat ed wit h t he specified 23335 priorit y.

duplicat evalue

– Value is already in t he priorit y group pgroup. 23338

m issingpriorit ygroup

– Priorit y group pgroup does not exist . 23336

m issingrepgroup

– Replicat ion group gnam e does not exist . 23373

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

t ypefailure

– Dat at ype of value is not t he sam e as t he dat at ype for 23319 priorit y group pgroup.

Re st r ict ion s •

The new value m ust be unique wit hin t he priorit y group.

422

Oracle Distributed Systems • •

The new priorit y m ust be unique wit hin t he priorit y group. ADD_PRI ORI TY_dat at ype m ust be called from t he m ast er definit ion sit e.

D BM S_ REPCAT.AD D _ SI TE_ PRI ORI TY_ SI TE

The ADD_SI TE_PRI ORI TY_SI TE procedure adds a new sit e t o an exist ing sit e priorit y group. The addit ion of t he new sit e t akes effect im m ediat ely. Specificat ions for Oracle7 and Oracle8 differ as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.ADD_SITE_PRIORITY_SITE (gname IN VARCHAR2 := '', name IN VARCHAR2, site IN VARCHAR2, priority IN NUMBER, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.ADD_SITE_PRIORITY_SITE (gname IN VARCHAR2 := '', name IN VARCHAR2, site IN VARCHAR2, priority IN NUMBER);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which sit e priorit y group nam e belongs

nam e

Nam e of t he sit e priorit y group

sit e

Global nam e of t he new sit e

priorit y

Priorit y designat ed t o sit e; it is a good idea t o num ber priorit ies in m ult iples of 10 or m ore so t hat you can easily add new priorit y values lat er as requirem ent s change.

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

duplicat epriorit y

– Anot her sit e is already designat ed wit h t he priorit y specified 23335 by t he priorit y param et er.

duplicat esit e

–

Sit e is already in t he sit e priorit y group nam e.

423

Oracle Distributed Systems

23338 m issingpriorit y

–1403 Sit e does not exist .

m issingrepgroup

– Replicat ion group gnam e does not exist . 23373

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

Re st r ict ion s •

•

You m ust call t he ADD_SI TE_PRI ORI TY_SI TE procedure from t he m ast er definit ion sit e. The new priorit y m ust be unique wit hin t he sit e priorit y group.

D BM S_ REPCAT.ALTER_ M ASTER_ PROPAGATI ON

The ALTER_MASTER_PROPAGATI ON procedure changes t he propagat ion m ode bet ween specified m ast er sit es ( from synchronous t o asynchronous, or vice versa) . PROCEDURE DBMS_REPCAT.ALTER_MASTER_PROPAGATION (gname IN VARCHAR2, master IN VARCHAR2, {dblink_table IN dbms_utility.dblink_array | dblink_list IN VARCHAR2}, propagation_modee IN VARCHAR2 := 'ASYNCHRONOUS', comment IN VARCHAR2 := ''); ALTER_MASTER_PROPAGATI ON does not aut om at ically generat e replicat ion support t riggers. Aft er alt ering t he propagat ion m et hod, you m ust call GENERATE_REPLI CATI ON_TRI GGER for replicat ed t able in t he replicat ion group.

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group whose propagat ion m ode is being alt ered

m ast er

Global nam e of t he m ast er sit e having it s propagat ion m ode alt ered

dblink_list

List of dat abase links for which t he m ast er’s propagat ion m ode is being alt ered

propagat ion_m ode New propagat ion m ode ( SYNCHRONOUS or ASYNCHRONOUS) com m ent

Com m ent visible in DBA_REPPROP dat a dict ionary view

Ex ce pt ion s Exception Name

Number

Description

424

Oracle Distributed Systems

nonm ast er

– One of t he sit es in dblink_list is not a m ast er sit e. 23312

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

not quiesced

– Replicat ion group gnam e is not quiesced. 23310

t ypefailure

– The propagat ion_m ode is not SYNCHRONOUS or 23319 ASYNCHRONOUS.

Re st r ict ion s • •

You m ust run t his procedure from t he m ast er definit ion sit e. The replicat ion group m ust be quiesced.

D BM S_ REPCAT.ALTER_ M ASTER_ REPOBJECT

Just as you can propagat e DDL t o creat e obj ect s wit h t he EXECUTE_DDL procedure, you can also propagat e DDL t o alt er obj ect s wit h ALTER_MASTER_REPOBJECT. Unlike EXECUTE_DDL, ALTER_MASTER_REPOBJECT does not allow you t o specify a list of m ast er sit es; t he call affect s all m ast ers. I n ot her words, Oracle does not support sit e- specific cust om izat ions of replicat ed obj ect s. You can perform DDL on any of t hese obj ect s: Funct ion

Synonym

I ndex

Table

Package

Trigger

Package body

View

Procedure Here is t he specificat ion: PROCEDURE DBMS_REPCAT.ALTER_MASTER_REPOBJECT (sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, ddl_text IN VARCHAR2, comment IN VARCHAR2 := '', retry IN BOOLEAN := FALSE);

Pa r a m e t e r s Parameter Name snam e

Description Nam e of t he schem a t o which obj ect onam e belongs.

425

Oracle Distributed Systems

onam e

Nam e of t he obj ect t o alt er.

t ype

The onam e obj ect t ype. Support ed t ypes: FUNCTI ON, I NDEX, PACKAGE, PACKAGE BODY, SYNONYM, TABLE, TRI GGER, and VI EW.

ddl_t ext

Text of DDL st at em ent t o apply.

com m ent

Com m ent visible in DBA_REPOBJECT dat a dict ionary view.

ret ry

I f set t o TRUE, procedure alt ers only obj ect s whose st at us is not VALI D at m ast er sit es.

Ex ce pt ion s Exception Name

Number

Description

com m failure

–23317 Unable t o com m unicat e wit h one or m ore m ast er sit es.

ddlfailure

–23318 DDL at m ast er definit ion sit e failed.

m issingobj ect

–23308 Obj ect onam e does not exist .

nonm ast erdef

–23312 Calling sit e is not t he m ast er definit ion sit e.

not quiesced

–23310 Replicat ion group gnam e is not quiesced.

t ypefailure

–23319 DDL on obj ect s of t he specified t ype is not support ed.

Re st r ict ion s • • •

This procedure m ust be run from t he m ast er definit ion sit e. The replicat ion group m ust be quiesced. You m ust call GENERATE_REPLI CATI ON_SUPPORT for t he alt ered obj ect before resum ing replicat ion.

D BM S_ REPCAT.ALTER_ PRI ORI TY

The ALTER_PRI ORI TY procedure let s you change t he priorit y associat ed wit h a specific value in a priorit y group. The change t akes place im m ediat ely. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.ALTER_PRIORITY (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, old_priority IN NUMBER, new_priority IN NUMBER, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.ALTER_PRIORITY (gname IN VARCHAR2 := '', pgroup IN VARCHAR2,

426

Oracle Distributed Systems old_priority IN NUMBER, new_priority IN NUMBER)

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which priorit y group pgroup belongs

pgroup

Nam e of t he priorit y group whose priorit y is being alt ered

old_priorit y

pgroup’s previous priorit y value

new_priorit y

pgroup’s new priorit y value

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

duplicat epriorit y

– Priorit y new_priorit y already exist s in priorit y group 23335 pgroup.

m issingpriorit ygroup

– Priorit y group pgroup does not exist . 23336

m issingvalue

– Value was not regist ered wit h a call t o 23337 ADD_PRI ORI TY_dat at ype.

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

Re st r ict ion s • •

You m ust call t he ALTER_PRI ORI TY procedure from t he m ast er definit ion sit e. The new priorit y m ust be unique wit hin t he priorit y group.

D BM S_ REPCAT.ALTER_ PRI ORI TY_ da t a t ype

The ALTER_PRI ORI TY_dat at ype procedures let you alt er t he dat a value associat ed wit h a specific priorit y for a priorit y group. For exam ple, in t he priorit y group PG_MFG_STAT, t he value associat ed wit h priorit y 1 could be changed from CONCEPT t o PLANNED. The change t akes effect im m ediat ely. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.ALTER_PRIORITY_datatype (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, old_value IN {CHAR|VARCHAR2|NUMBER|DATE|RAW}, new_value IN {CHAR|VARCHAR2|NUMBER|DATE|RAW},

427

Oracle Distributed Systems sname

IN VARCHAR2 := '');

Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.ALTER_PRIORITY_datatype (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, old_value IN {CHAR|NCHAR|VARCHAR2|NUMBER|DATE|RAW}, new_value IN {CHAR|NCHAR|VARCHAR2|NUMBER|DATE|RAW}); dat at ype, value, and old_value can be any of t he t ypes in t he following t able. Oracle7 and Oracle8

Oracle8 Only

CHAR

NCHAR

VARCHAR2

NVARCHAR2

NUMBER DATE RAW

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which priorit y group pgroup belongs

pgroup

Nam e of t he priorit y group whose priorit y is being alt ered

old_value

Current value of t he priorit y group m em ber

new_value

New value of t he priorit y group m em ber

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

duplicat evalue

– Value new_value is already designat ed a priorit y in 23338 priorit y group pgroup.

m issingpriorit ygroup

– Priorit y group pgroup does not exist . 23336

m issingvalue

– Value was not regist ered wit h a call t o 23337 ADD_PRI ORI TY_dat at ype.

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

Re st r ict ion s •

•

You m ust call t he ALTER_PRI ORI TY_dat at ype procedure from t he m ast er definit ion sit e. The new priorit y m ust be unique wit hin t he priorit y group.

428

Oracle Distributed Systems

D BM S_ REPCAT.ALTER_ SI TE_ PRI ORI TY

Just as you can change t he priorit y of a value in a priorit y group, you can change t he priorit y of a sit e in a sit e priorit y group. Use t he ALTER_SI TE_PRI ORI TY procedure t o do t his. The specificat ions for Oracle7 and Oracle8 differ as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.ALTER_SITE_PRIORITY (gname IN VARCHAR2 := '', name IN VARCHAR2, old_priority IN NUMBER, new_priority IN NUMBER, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.ALTER_SITE_PRIORITY (gname IN VARCHAR2 := '', name IN VARCHAR2, old_priority IN NUMBER, new_priority IN NUMBER); site IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which t he sit e priorit y group nam e belongs

nam e

Nam e of t he sit e priorit y group

old_priorit y

Sit e’s current priorit y

new_priorit y

Sit e’s new priorit y

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

sit e

Global nam e of t he sit e

Ex ce pt ion s Exception Name

Number

Description

duplicat epriorit y

– Priorit y new_priorit y already exist s for t he sit e priorit y 00001 group nam e.

m issingpriorit y

– Priorit y old_priorit y is not associat ed wit h any sit es. 01403

m issingrepgroup

– Replicat ion group gnam e does not exist . 23373

m issingvalue

–

Value old_value does not already exist .

429

Oracle Distributed Systems

23337 nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

param t ype

– Param et er new_value is incorrect dat at ype. 23325

Re st r ict ion s • •

You m ust run t his procedure from t he m ast er definit ion sit e. The new priorit y m ust be unique wit hin t he sit e priorit y group.

D BM S_ REPCAT.ALTER_ SI TE_ PRI ORI TY_ SI TE

The ALTER_SI TE_PRI ORI TY_SI TE procedure is analogous t o t he ADD_PRI ORI TY_dat at ype procedure; use it t o change t he sit e nam e for an exist ing nam ed sit e in a sit e priorit y group. The specificat ions for Oracle7 and Oracle8 differ as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.ALTER_SITE_PRIORITY_SITE (gname IN VARCHAR2 := '', name IN VARCHAR2, old_site IN VARCHAR2, new_site IN VARCHAR2, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.ALTER_SITE_PRIORITY_SITE (gname IN VARCHAR2 := '', name IN VARCHAR2, old_site IN VARCHAR2, new_site IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which t he sit e priorit y group nam e belongs

nam e

Nam e of t he sit e priorit y group

old_sit e

Global nam e of t he sit e current ly associat ed wit h t he priorit y level

new_sit e

Global nam e of t he sit e t hat is t o replace old_sit e at old_sit e’s priorit y level

snam e ( Oracle7

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

430

Oracle Distributed Systems

only)

Ex ce pt ion s Exception Name

Number

Description

duplicat esit e

–00001

new_sit e is already in t he sit e priorit y group.

m issingpriorit y

–01403

Sit e priorit y group nam e does not exist .

m issingrepgroup

–23373

Replicat ion group gnam e does not exist .

m issingvalue

–23337

old_sit e is not in t he sit e priorit y group.

nonm ast erdef

–23312

Calling sit e is not t he m ast er definit ion sit e.

Re st r ict ion s • •

You m ust call t his procedure from t he m ast er definit ion sit e. The new sit e m ust be unique in t he sit e priorit y group.

D BM S_ REPCAT.ALTER_ SN APSH OT_ PROPAGATI ON

Call t he ALTER_SNAPSHOT_PROPAGATI ON procedure t o change t he propagat ion m ode of a part icular snapshot . Specificat ions for Oracle7 and Oracle8 differ. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.ALTER_SNAPSHOT_PROPAGATION (gname IN VARCHAR2, propagation_mode IN VARCHAR2, comment IN VARCHAR2 := '', execute_as_user IN BOOLEAN := FALSE); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.ALTER_SNAPSHOT_PROPAGATION (gname IN VARCHAR2, propagation_mode IN VARCHAR2, comment IN VARCHAR2 := '' );

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o be alt ered.

propagat ion_m ode

The new propagat ion m ode t o use ( SYNCHRONOUS or ASYNCHRONOUS) .

com m ent

Com m ent visible in DBA_REPPROP dat a dict ionary view.

execut e_as_user

FALSE ( default ) indicat es t hat rem ot e syst em will aut hent icat e calls using aut hent icat ion cont ext user who originally queued t he

431

Oracle Distributed Systems

( Oracle7 only)

RPC; TRUE indicat es t hat rem ot e syst em will use aut hent icat ion cont ext of t he session user.

Ex ce pt ion s Exception Name

Number

Description

dbnot com pat ible

–23375

Dat abase version is not 7.3 or lat er.

m issingrepgroup

–23373

Replicat ion group gnam e does not exist .

t ypefailure

–23319

I nvalid propagat ion_m ode.

Re st r ict ion s This procedure m ust be called from a snapshot sit e.

D BM S_ REPCAT.CAN CEL_ STATI STI CS

The CANCEL_STATI STI CS procedure disables t he gat hering of conflict resolut ion st at ist ics. PROCEDURE DBMS_REPCAT.CANCEL_STATISTICS (sname IN VARCHAR2, oname IN VARCHAR2); There are no rest rict ions on calling CANCEL_STATI STI CS.

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t o which t he replicat ed t able belongs

onam e

Nam e of t he replicat ed t able

Ex ce pt ion s Exception Name

Number

Description

m issingobj ect

–23308 Table onam e does not exist .

m issingschem a

–23306 Schem a snam e does not exist .

st at not reg

–23345 St at ist ics have not been regist ered for obj ect onam e.

D BM S_ REPCAT.COM M EN T_ ON _ con flict t ype _ RESOLUTI ON

432

Oracle Distributed Systems You can use t he COMMENT_ON_conflict t ype_RESOLUTI ON procedure t o add or replace a com m ent for a given conflict resolut ion t ype. You can see t his com m ent in t he DBA_REPRESOLUTI ON dat a dict ionary view. Following are t he specificat ions for t he t hree values of conflict t ype ( UPDATE, UNI QUE, DELETE) : PROCEDURE DBMS_REPCAT.COMMENT_ON_UPDATE_RESOLUTION (sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, sequence_no IN NUMBER, comment IN VARCHAR2); PROCEDURE DBMS_REPCAT.COMMENT_ON_UNIQUE_RESOLUTION (sname IN VARCHAR2, oname in VARCHAR2, constraint_name IN VARCHAR2, sequence_no IN NUMBER, comment IN VARCHAR2) ; PROCEDURE DBMS_REPCAT. COMMENT_ON_DELETE_RESOLUTION (sname IN VARCHAR2, oname IN VARCHAR2, sequence_no IN NUMBER, comment IN VARCHAR2) ;

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t o which obj ect onam e belongs

onam e

Nam e of t he obj ect

colum n_group

Nam e of colum n group for which conflict resolut ion m et hod is defined

const raint _nam e

Nam e of unique const raint t he m et hod resolves ( COMMENT_ON_UNI QUE_RESOLUTI ON only)

sequence_no

Sequence num ber associat ed wit h t he resolut ion m et hod

com m ent

Com m ent

Ex ce pt ion s Exception Name

Number

Description

m issingobj ect

– Obj ect onam e does not exist . 23308

m issingresolut ion

– No resolut ion m et hod exist s for colum n_group and 23343 sequence_no.

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

Re st r ict ion s •

You m ust call t his procedure from t he m ast er definit ion sit e.

433

Oracle Distributed Systems •

•

Aft er t his call, you m ust generat e replicat ion support for t he t able passed t o onam e. Com m ent s do not t ake effect unt il t here is a call t o GENERATE_REPLI CATI ON_SUPPORT.

D BM S_ REPCAT.COM M EN T_ ON _ COLUM N _ GROUP

The COMMENT_ON_COLUMN_GROUP procedure adds or changes t he com m ent associat ed wit h a colum n group. This com m ent is visible in t he DBA_REPCOLUMN_GROUP dat a dict ionary view. PROCEDURE DBMS_REPCAT.COMMENT_ON_COLUMN_GROUP (sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, comment IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t o which t he replicat ed t able belongs

onam e

Nam e of t he replicat ed t able cont aining t he colum n group

colum n_group

Nam e of t he colum n group

com m ent

Com m ent

Ex ce pt ion s Exception Name

Number

Description

m issinggroup

–23331

colum n_group does not exist .

nonm ast erdef

–23312

Calling sit e is not t he m ast er definit ion sit e.

Re st r ict ion s The COMMENT_ON_COLUMN_GROUP procedure m ust be called from t he m ast er definit ion sit e.

D BM S_ REPCAT.COM M EN T_ ON _ PRI ORI TY_ GROUP

The COMMENT_ON_PRI ORI TY_GROUP procedure allows you t o add or replace t he com m ent for a priorit y group ( as seen in t he DBA_REPPRI ORI TY_GROUP dat a dict ionary view) . The specificat ions for Oracle7 and Oracle8 differ as follows.

434

Oracle Distributed Systems Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.COMMENT_ON_PRIORITY_GROUP (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, comment IN VARCHAR2, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.COMMENT_ON_PRIORITY_GROUP (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, comment IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group cont aining t he priorit y group

pgroup

Nam e of t he priorit y group

com m ent

Com m ent

snam e ( Oracle7only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

m issingpriorit ygroup

–23336

Priorit y group pgroup does not exist .

m issingrepgroup

–23373

Replicat ion group gnam e does not exist .

nonm ast erdef

–23312

Calling sit e is not t he m ast er definit ion sit e.

Re st r ict ion s You m ust call COMMENT_ON_PRI ORI TY_GROUP from t he m ast er definit ion sit e.

D BM S_ REPCAT.COM M EN T_ ON _ REPGROUP

This procedure adds a new schem a com m ent field t o t he DBA_REPCAT dat a dict ionary view or changes an exist ing one. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DMBS_REPCAT.COMMENT_ON_REPGROUP (gname IN VARCHAR2 := '', comment IN VARCHAR2, sname IN VARCHAR2 := '');

435

Oracle Distributed Systems Oracle8 specificat ion: PROCEDURE DMBS_REPCAT.COMMENT_ON_REPGROUP (gname IN VARCHAR2, comment IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

gnam e

Replicat ion group t o which com m ent is added

com m ent

Com m ent

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

com m failure

–23317 Unable t o com m unicat e wit h one or m ore m ast er sit es.

m issinggroup

–23331 Replicat ion group gnam e does not exist .

nonm ast erdef

–23312 Calling sit e is not m ast er definit ion sit e.

Re st r ict ion s The COMMENT_ON_REPGROUP procedure m ust be called from t he m ast er definit ion sit e.

D BM S_ REPCAT.COM M EN T_ ON _ REPOBJECT

As you have seen, you can associat e com m ent s wit h a replicat ed obj ect when you creat e or alt er it by passing a VARCHAR2 st ring t o t he com m ent param et er. You can see t hese com m ent s in t he obj ect _com m ent field of DBA_REPOBJECTS. Also, you can creat e com m ent s wit hout creat ing or alt ering t he obj ect wit h DBMS_REPCAT’s COMMENT_ON_REPOBJECT procedure. PROCEDURE DBMS_REPCAT.COMMENT_ON_REPOBJECT (sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, comment IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of schem a t o which obj ect belongs

onam e

Nam e of t he obj ect

t ype

Obj ect t ype

com m ent

Com m ent

436

Oracle Distributed Systems

Ex ce pt ion s Exception Name

Number

Description

com m failure

–23317 Unable t o com m unicat e wit h one or m ore m ast er sit es.

m issingobj ect

–23308 Obj ect onam e does not exist .

nonm ast erdef

–23312 Calling sit e is not m ast er definit ion sit e.

t ypefailure

–23319 Obj ect t ype is not support ed.

Re st r ict ion s The COMMENT_ON_REPOBJECT procedure m ust be called from t he m ast er definit ion sit e.

D BM S_ REPCAT.COM M EN T_ ON _ REPSI TES

The COMMENT_ON_REPSI TES procedure allow s you t o add or change a com m ent associat ed wit h a m ast er sit e, which is visible in t he DBA_REPSI TES dat a dict ionary view. PROCEDURE DBMS_REPCAT.COMMENT_ON_REPSITES (gname IN VARCHAR2, master IN VARCHAR, comment IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which m ast er belongs

m ast er

Global nam e of m ast er sit e

com m ent

Com m ent

Ex ce pt ion s Exception Name

Number

Description

com m failure

–23317 Unable t o com m unicat e wit h one or m ore m ast er sit es.

nonm ast er

–23313 The m ast er is not a m ast er sit e.

nonm ast erdef

–23312 Calling sit e is not m ast er definit ion sit e.

Re st r ict ion s You m ust call t he COMMENT_ON_REPSI TES procedure from t he m ast er definit ion sit e.

D BM S_ REPCAT.COM M EN T_ ON _ SI TE_ PRI ORI TY

437

Oracle Distributed Systems

The COMMENT_ON_SI TE_PRI ORI TY procedure adds or replaces t he com m ent field in t he DBA_REPPRI ORI TY_GROUP dat a dict ionary view for t he specified sit e priorit y group. Specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.COMMENT_ON_SITE_PRIORITY (gname IN VARCHAR2 := '', name IN VARCHAR2, comment IN VARCHAR2, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.COMMENT_ON_SITE_PRIORITY (gname IN VARCHAR2 := '', name IN VARCHAR2, comment IN VARCHAR2)

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group cont aining t he priorit y group

nam e

Nam e of t he sit e priorit y group

com m ent

Com m ent

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name m issingpriorit y

Number –1403

Description Sit e priorit y group nam e does not exist .

m issingrepgroup

–23373

Replicat ion group gnam e does not exist .

nonm ast erdef

–23312

Calling sit e is not m ast er definit ion sit e.

Re st r ict ion s You m ust call COMMENT_ON_SI TE_PRI ORI TY from t he m ast er definit ion sit e.

D BM S_ REPCAT.CREATE_ M ASTER_ REPGROUP

The CREATE_MASTER_REPGROUP procedure creat es a new, em pt y, quiesced replicat ion group at t he m ast er definit ion sit e. The calling sit e is t he m ast er definit ion sit e for t he new group.

438

Oracle Distributed Systems PROCEDURE DBMS_REPCAT.CREATE_MASTER_REPGROUP (gname IN VARCHAR2, group_comment IN VARCHAR2 := '', master_comment IN VARCHAR2 := '', qualifier IN VARCHAR2 := '');

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he new replicat ion group

group_com m ent

Com m ent for new replicat ion group, visible in DBA_REPGROUP dat a dict ionary view

m ast er_com m ent

Com m ent for t he calling sit e, visible in DBA_REPSI TES dat a dict ionary view

qualifier

For int ernal use

Ex ce pt ion s Exception Name

Number

Description

ddlfailure

– Unable t o creat e REP$WHAT_AM_I package or package 23318 body.

duplicat erepgroup

– Replicat ion group gnam e already exist s. 23374

duplicat eschem a

– Schem a gnam e is already a replicat ion group. 23307

m issingrepgroup

– The gnam e was not specified correct ly. 23373

norepopt ion

– Replicat ion opt ion not inst alled. 23364

dbnot com pat ible

– The gnam e is not a schem a nam e, and RDBMS is a pre23375 7.3 release.

Re st r ict ion s You m ust be connect ed t o t he replicat ion adm inist rat or account ( t ypically REPADMI N) t o call CREATE_MASTER_REPGROUP.

D BM S_ REPCAT.CREATE_ M ASTER_ REPOBJECT

The CREATE_MASTER_REPOBJECT procedure adds a new replicat ed obj ect t o an exist ing replicat ion group. PROCEDURE DBMS_REPCAT.CREATE_MASTER_REPOBJECT( sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2,

439

Oracle Distributed Systems use_existing_object IN BOOLEAN := TRUE, ddl_text IN VARCHAR2 := NULL, comment IN VARCHAR2 := '', retry IN BOOLEAN := FALSE, copy_rows IN BOOLEAN := TRUE, gname IN VARCHAR2 := ''); I t is generally easier t o inst ant iat e obj ect s t hat you int end t o replicat e at all part icipat ing m ast er sit es before calling CREATE_MASTER_REPOBJECT. This avoids t he addit ional t im e and com plexit y of having t he procedure creat e and populat e t he replicat ed obj ect s it self.

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t o which onam e belongs.

onam e

Nam e of t he obj ect t o be added.

t ype

Obj ect t ype. Valid t ypes: TABLE, I NDEX, SYNONYM, TRI GGER, VI EW, PROCEDURE, FUNCTI ON, PACKAGE, and PACKAGE BODY.

use_exist ing_obj ect

Set t o TRUE t o reuse exist ing obj ect s wit h t he sam e nam e and st ruct ure at m ast er sit es.

ddl_t ext

Text of DDL st at em ent t o creat e obj ect onam e ( use t his param et er if and only if obj ect does not already exist ) .

com m ent

Com m ent on replicat ed obj ect , visible in DBA_REPOBJECT dat a dict ionary view.

ret ry

Flag indicat ing t hat t his call is a reat t em pt of an earlier call. An at t em pt is m ade t o creat e obj ect only at m ast er sit es where it does not exist wit h a st at us of VALI D.

copy_rows

Populat e t ables and ot her m ast er sit es wit h dat a from m ast er definit ion sit e.

gnam e

Nam e of t he replicat ion group t o which onam e should be added.

Ex ce pt ion s Exception Name Number

Description

com m failure

– Not all m ast er sit es are reachable. 23317

ddlfailure

– Obj ect onam e already exist s in replicat ion group gnam e, and 23309 ret ry is not set t o TRUE.

duplicat eobj ect

– Replicat ion group gnam e already exist s. 23374

m issingobj ect

– Obj ect onam e does not exist . 23308

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e for replicat ion 23373 group gnam e.

not quiesced

– Replicat ion group gnam e is not quiesced. 23310

t ypefailure

– The t ype is not support ed. 23319

440

Oracle Distributed Systems

Re st r ict ion s • •

This procedure m ust be called from t he m ast er definit ion sit e. The replicat ion group m ust already exist and be quiesced.

D BM S_ REPCAT.CREATE_ SN APSH OT_ REPGROUP

This procedure creat es a new, em pt y snapshot replicat ion group. I f you will be creat ing t he snapshot group at m ult iple sit es, it is advisable t o creat e a script t o perform t his call because t here is no analogy t o ADD_MASTER_DATABASE for snapshot groups. PROCEDURE DBMS_REPCAT.CREATE_SNAPSHOT_REPGROUP (gname IN VARCHAR2, master IN VARCHAR2, comment IN VARCHAR2 := '', propagation_mode IN VARCHAR2 := 'ASYNCHRONOUS');

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he new snapshot group

m ast er

Global nam e of m ast er sit e

com m ent

Com m ent for t he snapshot group, visible in DBA_REPSI TES dat a dict ionary view

propagat ion_m ode

Snapshot propagat ion m ode ( SYNCHRONOUS or ASYNCHRONOUS)

Ex ce pt ion s Exception Name

Number

Description

com m failure

– Unable t o com m unicat e wit h m ast er. 23317

dbnot com pat ible

– At t em pt t o use SYNCHRONOUS propagat ion in pre- 7.3 23375 dat abase.

duplicat erepgroup

– Replicat ion group gnam e already exist s. 23374

nonm ast er

– The m ast er param et er is not a m ast er sit e. 23312

norepopt ion

– Replicat ion opt ion not inst alled. 23364

t ypefailure

– propagat ion_m ode not specified correct ly. 23319

441

Oracle Distributed Systems

Re st r ict ion s •

•

•

You m ust be connect ed t o t he replicat ion adm inist rat or account ( t ypically REPADMI N) t o call t he CREATE_SNAPSHOT_REPGROUP procedure. The snapshot group nam e m ust m at ch t he nam e of t he m ast er replicat ion group. You m ust invoke t his procedure from t he snapshot sit e.

D BM S_ REPCAT.CREATE_ SN APSH OT_ REPOBJECT

The CREATE_SNAPSHOT_REPOBJECT procedure adds an obj ect t o a specified snapshot replicat ion group at a snapshot sit e. For new snapshot obj ect s, t his procedure generat es row- level replicat ion t riggers for snapshot s if t he m ast er t able uses row- level replicat ion. The specificat ions differ for Oracle7 and Oracle8 as follows. ( Not e t he addit ion of t he m in_com m unicat ion param et er in Oracle8.) Oracle7 specificat ion: PROCEDURE DBMS_REPCAT. CREATE_SNAPSHOT_REPOBJECT (sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, ddl_text IN VARCHAR2 := '', comment IN VARCHAR2 := '', gname IN VARCHAR2 := '', gen_objs_owner IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.CREATE_SNAPSHOT_REPOBJECT (sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, ddl_text IN VARCHAR2 := '', comment IN VARCHAR2 := '', gname IN VARCHAR2 := '', gen_objs_owner IN VARCHAR2 := '', min_communication IN BOOLEAN := TRUE);

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of schem a t o which onam e belongs.

onam e

Nam e of obj ect t o be added.

t ype

Obj ect t ype. Support ed t ypes are PACKAGE, PACKAGE BODY, PROCEDURE, SNAPSHOT, SYNONYM, and VI EW.

ddl_t ext

DDL used t o creat e obj ect ( for t ype SNAPSHOT only) .

442

Oracle Distributed Systems

com m ent

Com m ent on obj ect , visible in DBA_REPOBJECT dat a dict ionary view.

gnam e

Nam e of snapshot group t o which obj ect is being added. Default s t o snam e if not specified.

gen_obj s_owner

Nam e of t he schem a in which t o creat e t he generat ed t rigger and t rigger package or procedure wrapper for t he obj ect . Default s t o snam e.

drop_obj ect s

I f set t o TRUE, obj ect is dropped t oo. I f FALSE ( t he default ) , obj ect is rem oved only from t he snapshot group.

m in_com m unicat ion ( Oracle8 only)

Must be FALSE if any m ast er sit e is running Oracle7. TRUE, t he default set t ing, uses t he m inim um com m unicat ion algorit hm .

Ex ce pt ion s Exception Name

Number

Description

com m failure

– Unable t o com m unicat e wit h m ast er sit e. 23317

ddlfailure

– Unable t o perform DDL. 23318

duplicat eobj ect

– Obj ect onam e already exist s. 23309

m issingobj ect

– Obj ect onam e does not exist in m ast er’s replicat ion 23308 group gnam e.

m issingrem ot eobj ect

– Mast er sit e has not generat ed replicat ion support for 23381 onam e.

m issingschem a

– Schem a snam e does not exist . 23306

m isssnapobj ect

– Obj ect onam e does not exist at m ast er. 23355

nonm ast er

– Mast er sit e associat ed wit h snapshot group is no longer 23312 a m ast er sit e.

nonsnapshot

– Calling sit e is not a snapshot sit e. 23314

t ypefailure

– I nvalid value for t ype. 23319

Re st r ict ion s •

•

You m ust be connect ed t o t he replicat ion adm inist rat or account ( t ypically REPADMI N) . I f you are creat ing an snapshot wit h ddl_t ext , be sure t o specify t he schem a in which it should be creat ed ( if ot her t han t he replicat ion adm inist rat or) .

D BM S_ REPCAT.D EFI N E_ COLUM N _ GROUP

443

Oracle Distributed Systems

The DEFI NE_COLUMN_GROUP procedure creat es a colum n group wit h no m em ber colum ns. The new colum n group does not t ake effect unt il you call GENERATE_REPLI CATI ON_SUPPORT for t he t able. PROCEDURE DBMS_REPCAT.DEFINE_COLUMN_GROUP (sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, comment IN VARCHAR@ := NULL);

Pa r a m e t e r s Parameter Name snam e

Description Nam e of t he schem a t o which t he replicat ed t able belongs

onam e

Nam e of t he replicat ed t able cont aining t he colum n group

colum n_group

Nam e of t he colum n group

com m ent

Com m ent

Ex ce pt ion s Exception Name duplicat egroup

Number –23330

Description Colum n_group already exist s.

m issingobj ect

–23308

Obj ect onam e does not exist .

nonm ast erdef

–23312

Calling sit e is not m ast er definit ion sit e.

Re st r ict ion s You m ust call t his procedure from t he quiesced m ast er definit ion sit e.

D BM S_ REPCAT.D EFI N E_ PRI ORI TY_ GROUP

The DEFI NE_PRI ORI TY_GROUP procedure creat es a new priorit y group. The new group does not t ake effect unt il you call GENERATE_REPLI CATI ON_SUPPORT for t he t able. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.DEFINE_PRIORITY_GROUP (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, datatype IN VARCHAR2, fixed_length IN INTEGER := NULL, comment IN VARCHAR2 := NULL,

444

Oracle Distributed Systems sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.DEFINE_PRIORITY_GROUP (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, datatype IN VARCHAR2, fixed_length IN INTEGER := NULL, comment IN VARCHAR2 := NULL);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group cont aining t he priorit y group.

pgroup

Nam e of t he priorit y group. Dat at ype for t he value used in t he priorit y group. Support ed dat at ypes:

dat at ype

CHAR NCHAR ( Oracle8 only) VARCHAR2 NUMBER DATE RAW

fixed_lengt h

Fixed lengt h for values. Used only for dat at ype CHAR.

com m ent

Com m ent .

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y) .

Ex ce pt ion s Exception Name

Number

Description

duplicat epriorit ygroup

–23335 Priorit y group pgroup already exist s.

m issingschem a

–23306 Schem a does not exist .

nonm ast erdef

–23312 Calling sit e is not t he m ast er definit ion sit e.

t ypefailure

–23319 Dat at ype not support ed.

Re st r ict ion s You m ust call t he DEFI NE_PRI ORI TY_GROUP procedure from t he m ast er definit ion sit e.

D BM S_ REPCAT.D EFI N E_ SI TE_ PRI ORI TY

445

Oracle Distributed Systems The DEFI NE_SI TE_PRI ORI TY procedure creat es a sit e priorit y group. You can add sit es t o t his group lat er. The new sit e priorit y does not t ake effect unt il you call GENERATE_REPLI CATI ON_SUPPORT for t he t able. Specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.DEFINE_SITE_PRIORITY (gname IN VARCHAR2 := '', name IN VARCHAR2, comment IN VARCHAR2 := NULL, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.DEFINE_SITE_PRIORITY (gname IN VARCHAR2 := '', name IN VARCHAR2, comment IN VARCHAR2 := NULL)

Pa r a m e t e r s Parameter Name gnam e

Description Nam e of t he replicat ion group cont aining t he sit e priorit y group

nam e

Nam e of t he sit e priorit y group

com m ent

Com m ent , visible in DBA_REPPRI ORI TY_GROUP dat a dict ionary view

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

duplicat epriorit ygroup

–23335 Sit e priorit y group nam e already exist s.

m issingrepgroup

–23373 Replicat ion group gnam e does not exist .

nonm ast erdef

–23312 Calling sit e is not t he m ast er definit ion sit e.

Re st r ict ion s You m ust call DEFI NE_SI TE_PRI ORI TY from t he m ast er definit ion sit e.

D BM S_ REPCAT.D O_ D EFERRED _ REPCAT_ AD M I N

Whenever you creat e or alt er replicat ed obj ect s—for exam ple, wit h t he GENERATE_REPLI CATI ON_SUPPORT or ALTER_MASTER_REPOBJECT procedure— Oracle queues t he changes in t he repcat log queue; t he ent ries in t his queue

446

Oracle Distributed Systems correspond t o ent ries in t he DBA_REPCATLOG dat a dict ionary view. All DDL changes m ust originat e at t he m ast er definit ion sit e, but t he repcat log queue exist s at every m ast er sit e. The DO_DEFERRED_REPCAT_ADMI N procedure perform s adm inist rat ive t asks queued in DBA_REPCAT for t he specific replicat ion group at t he m ast er sit e from which t he call is m ade. I f t he all_sit es param et er is set t o TRUE, t he t asks are applied at all m ast ers. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN (gname IN VARCHAR2 := '', all_sites IN BOOLEAN := FALSE, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN (gname IN VARCHAR2, all_sites IN BOOLEAN := FALSE);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group for which t o push t he repcat log queue

all_sit es

I f TRUE, execut e queued procedures at every m ast er sit e

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

com m failure

– Unable t o com m unicat e wit h m ast er sit e. 23317

nonm ast er

– Mast er sit e associat ed wit h snapshot group is no longer a 23312 m ast er sit e.

Re st r ict ion s The DO_DEFERRED_REPCAT_ADMI N procedure perform s only t he procedures t hat have been queued by t he invoking user. Not e t hat t he j ob queue is used t o perform t he queued procedures aut om at ically.

D BM S_ REPCAT.D ROP_ con flict t ype _ RESOLUTI ON

447

Oracle Distributed Systems

The DROP_conflict t ype_RESOLUTI ON procedure rem oves a conflict resolut ion t ype from a replicat ed t able. The value of conflict t ype can be UPDATE, UNI QUE, or DELETE. PROCEDURE DBMS_REPCAT.DROP_UPDATE_RESOLUTION (sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, sequence_no IN NUMBER) ; PROCEDURE DBMS_REPCAT.DROP_UNIQUE_RESOLUTION (sname IN VARCHAR2, oname IN VARCHAR2, constraint_name IN VARCHAR2, sequence_no IN NUMBER) ; PROCEDURE DBMS_REPCAT.DROP_DELETE_RESOLUTION (sname IN VARCHAR2, oname IN VARCHAR2, sequence_no IN NUMBER) ;

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a cont aining t he replicat ed schem a. Default s t o current user.

onam e

Nam e of t he replicat ed t able.

colum n_group

Colum n group for which t he conflict resolut ion m et hod is defined.

For procedure DROP_UNI QUE_RESOLUTI ON only. Nam e of t he const raint _nam e const raint nam e or unique index for which t he conflict resolut ion m et hod is defined. sequence_no

Num ber indicat ing when t his conflict resolut ion m et hod is applied relat ive t o ot her conflict resolut ion m et hods defined for t he sam e colum n group or priorit y group.

Ex ce pt ion s Exception Name

Number

Description

m issingobj ect

–23308 Table onam e does not exist in t he replicat ion group.

m issingschem a

–23306 Schem a snam e does not exist .

nonm ast erdef

–23312 Calling sit e is not t he m ast er definit ion sit e.

Re st r ict ion s • •

You m ust call t his procedure from t he m ast er definit ion sit e. Aft er t his call, you m ust generat e replicat ion support for t he t able passed t o onam e.

448

Oracle Distributed Systems

D BM S_ REPCAT.D ROP_ COLUM N _ GROUP

The DROP_COLUMN_GROUP procedure drops a colum n group t hat you’ve previously creat ed. The change does not t ake effect unt il you call GENERATE_REPLI CATI ON_SUPPORT for t he t able for which t he colum n group is defined. PROCEDURE DBMS_REPCAT.DROP_COLUMN_GROUP (sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t o which t he replicat ed t able belongs

onam e

Nam e of t he replicat ed t able cont aining t he colum n group

colum n_group

Nam e of t he colum n group

Ex ce pt ion s Exception Name Number

Description

m issinggroup

– The colum n_group does not exist . 23331

m issingobj ect

– The obj ect onam e does not exist . 23308

m issingschem a

– The schem a snam e does not exist . 23306

nonm ast erdef

– Calling sit e is not m ast er definit ion sit e. 23312

referenced

– The colum n_group is used by exist ing conflict resolut ion 23332 m et hods.

Re st r ict ion s You m ust call t his procedure from t he quiesced m ast er definit ion sit e.

D BM S_ REPCAT.D ROP_ GROUPED _ COLUM N

The DROP_GROUPED_COLUMN procedure allows you t o drop one or m ore colum ns from a colum n group. Dropping a colum n from a colum n group is quit e sim ilar t o adding one. Make sure, however, t hat none of your conflict resolut ion m et hods

449

Oracle Distributed Systems reference t he colum n( s) t hat you are dropping. Changes do not t ake effect unt il GENERATE_REPLI CATI ON_SUPPORT is called. As wit h t he ot her procedures wit h a list _of_colum n_nam es param et er, you can pass an ast erisk ( * ) t o t he param et er t o indicat e all fields in t able onam e. PROCEDURE DBMS_REPCAT.DROP_GROUPED_COLUMN (sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, {list_of_column_names IN VARCHAR2 | list_of_column_names IN dbms_repcat.varchar2s}); Not e t hat you m ust specify only one of t he list _of_colum n_nam es param et ers.

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t hat owns t he replicat ed t able

onam e

Nam e of t he t able wit h t he colum n_group

colum n_group

Nam e of t he colum n_group from which colum n( s) will be dropped

list _of_colum n_nam es

A com m a- delim it ed list of colum n nam es or a PL/ SQL t able of colum n nam es

Ex ce pt ion s Exception Name

Number

Description

m issinggroup

–23331

Colum n group colum n_group does not exist .

m issingobj ect

–23308

Table onam e does not exist .

m issingschem a

–23306

Schem a snam e does not exist .

nonm ast erdef

–23312

I nvoking sit e is not t he m ast er definit ion sit e.

Re st r ict ion s You m ust not call t his procedure from t he quiesced m ast er definit ion sit e.

D BM S_ REPCAT.D ROP_ M ASTER_ REPGROUP

The DROP_MASTER_REPGROUP procedure drops one or m ore replicat ion groups ( and opt ionally all of it s cont ent s) at t he m ast er definit ion sit e. Changes do not t ake effect unt il GENERATE_REPLI CATI ON_SUPPORT is called. Before calling DROP_MASTER_REPGROUP, call REMOVE_MASTER_DATABASES from t he m ast er definit ion sit e t o rem ove all m ast ers for which you plan t o drop t he group

450

Oracle Distributed Systems and t hat do not cont ain any ot her replicat ion groups. I n addit ion, you can avoid t he fullqueue error by quiescing t he replicat ion group before at t em pt ing t o drop t he replicat ion group. PROCEDURE DBMS_REPCAT.DROP_MASTER_REPGROUP (gname IN VARCHAR2, drop_contents IN BOOLEAN := FALSE, all_sites IN BOOLEAN := FALSE);

Pa r a m e t e r s Parameter Name

Description

all_sit es

I f TRUE and call is t he m ast er definit ion sit e, t hen drop t he replicat ion group from all sit es in t he environm ent .

drop_cont ent s

I f TRUE, drop t he obj ect s in t he replicat ion group as well as t he group it self.

gnam e

Nam e of t he new replicat ion group.

Ex ce pt ion s Exception Name

Number

Description

com m failure

– Unable t o com m unicat e wit h all m ast ers, and all_sit es is 23317 TRUE.

fullqueue

– Out st anding t ransact ions queued for replicat ion group 23353 gnam e.

m issingrepgroup

– gnam e is not specified correct ly. 23373

nonm ast er

– Calling sit e is not a m ast er sit e. 23313

nonm ast erdef

– Calling sit e is not a m ast er definit ion sit e, and all_sit es is 23312 TRUE.

Re st r ict ion s •

•

You m ust be connect ed t o t he replicat ion adm inist rat or account ( t ypically REPADMI N) t o call DROP_MASTER_REPGROUP. DROP_MASTER_REPGROUP does not drop all snapshot s if t he gnam e param et er is t he m ast er of any snapshot groups. Dropping a m ast er sit e does not necessarily rem ove it from t he DBA_REPSI TES at ot her m ast ers.

D BM S_ REPCAT.D ROP_ M ASTER_ REPOBJECT

The DROP_MASTER_REPOBJECT procedure drops a replicat ed obj ect in an exist ing replicat ion group at t he m ast er sit e and opt ionally drops t he obj ect from all sit es. Do not drop t ables t o which snapshot s are m ast ered.

451

Oracle Distributed Systems PROCEDURE DBMS_REPOBJECT.DROP_MASTER_REPOBJECT (sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, drop_objects IN BOOLEAN := FALSE);

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t o which onam e belongs.

onam e

Nam e of t he obj ect t o be added.

t ype

Obj ect t ype. Valid t ypes: TABLE, I NDEX, SYNONYM, TRI GGER, VI EW, PROCEDURE, FUNCTI ON, PACKAGE, and PACKAGE BODY.

drop_obj ect s I f TRUE, drop t he obj ect at all m ast er sit es; default is FALSE.

Ex ce pt ion s Exception Name

Number

Description

com m failure

– Not all m ast er sit es are reachable. 23317

m issingobj ect

– Obj ect onam e does not exist . 23308

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e for replicat ion 23373 group gnam e.

t ypefailure

– The t ype is not support ed. 23319

Re st r ict ion s • •

This procedure m ust be called from t he m ast er definit ion sit e. The replicat ion group m ust already exist and be quiesced.

D BM S_ REPCAT.D ROP_ PRI ORI TY

The DROP_PRI ORI TY procedure rem oves a value from a priorit y group. The change t akes effect im m ediat ely. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.DROP_PRIORITY (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, priority_num IN NUMBER, sname IN VARCHAR2 := '');

452

Oracle Distributed Systems Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.DROP_PRIORITY (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, priority_num IN NUMBER);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which priorit y group pgroup belongs

pgroup

Nam e of t he priorit y group whose priorit y is being alt ered

priorit y_num

Priorit y for t he value t o be dropped

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

m issingpriorit ygroup

–23336

Priorit y group pgroup does not exist .

m issingrepgroup

–23373

Replicat ion group gnam e does not exist .

nonm ast erdef

–23312

Calling sit e is not t he m ast er definit ion sit e.

Re st r ict ion s You m ust call t he DROP_PRI ORI TY procedure from t he m ast er definit ion sit e.

D BM S_ REPCAT.D ROP_ PRI ORI TY_ da t a t ype

The DROP_PRI ORI TY_dat at ype procedure rem oves a value from a priorit y group. I n t his version of t he procedure, you can specify t he value by dat a value. The rem oval of a priorit y and value t akes effect im m ediat ely. The specificat ions differ for Oracle7 and Oracle 8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.DROP_PRIORITY_datatype (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, value IN {CHAR|VARCHAR2|NUMBER|DATE|RAW}, sname IN VARCHAR2 := ''); Oracle8 specificat ion:

453

Oracle Distributed Systems PROCEDURE DBMS_REPCAT.DROP_PRIORITY_datatype (name IN VARCHAR2 := '', pgroup IN VARCHAR2, value IN {CHAR|NCHAR|VARCHAR2|NUMBER|DATE|RAW}, sname IN VARCHAR2 := ''); dat at ype and value can be any of t he t ypes in t he following t able. Oracle7 and Oracle8

Oracle8 Only

CHAR

NCHAR

VARCHAR2

NVARCHAR2

NUMBER DATE RAW

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which priorit y group pgroup belongs

pgroup

Priorit y group t o which new value and priorit y are being added

value

Lit eral value t hat is being assigned t o pgroup

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

– m issingpriorit ygroup Priorit y group pgroup does not exist . 23336 m issingrepgroup

– Replicat ion group gnam e does not exist . 23373

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

param t ype

– Dat at ype of value is not t he sam e as t he dat at ype for 23325 priorit y group pgroup.

Re st r ict ion s You m ust call DROP_PRI ORI TY_dat at ype from t he m ast er definit ion sit e.

D BM S_ REPCAT.D ROP_ PRI ORI TY_ GROUP

454

Oracle Distributed Systems The DROP_PRI ORI TY_GROUP procedure let s you drop a priorit y group t hat you have defined. The change does not go int o effect unt il t he next call t o GENERATE_REPLI CATI ON_SUPPORT. Do not drop a priorit y group t hat you have designat ed as an UPDATE conflict resolut ion m et hod for a colum n group. You m ust first use DROP_UPDATE_RESOLUTI ON for t he colum n group. Records in t he dat a dict ionary view DBA_REPRESOLUTI ON indicat e if and where t he priorit y group is used. At t em pt ing t o drop a priorit y group t hat is in use raises t he referenced except ion. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.DROP_PRIORITY_GROUP (gname IN VARCHAR2 := '', pgroup IN VARCHAR2, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.DROP_PRIORITY_GROUP (gname IN VARCHAR2 := '', pgroup IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group cont aining t he priorit y group

pgroup

Nam e of t he priorit y group t o drop

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

– m issingrepgroup Replicat ion group gnam e does not exist . 23373 nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

referenced

– Priorit y group pgroup is used by exist ing conflict resolut ion 23332 m et hods.

Re st r ict ion s You m ust call DROP_PRI ORI TY_GROUP from t he m ast er definit ion sit e.

D BM S_ REPCAT.D ROP_ SI TE_ PRI ORI TY

455

Oracle Distributed Systems The DROP_SI TE_PRI ORI TY procedure drops an exist ing sit e priorit y group t hat is no longer in use. The change does not go int o effect unt il t he next call t o GENERATE_REPLI CATI ON_SUPPORT. As wit h t he DROP_PRI ORI TY_GROUP procedure, do not at t em pt t o drop a sit e priorit y group t hat is act ing as an UPDATE conflict resolut ion handler for a colum n group. First , use DROP_UPDATE_RESOLUTI ON t o drop t he conflict handler for t he colum n group. Specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.DROP_SITE_PRIORITY (gname IN VARCHAR2 := '', name IN VARCHAR2, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.DROP_SITE_PRIORITY (gname IN VARCHAR2 := '', name IN VARCHAR2)

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group cont aining t he sit e priorit y group

nam e

Nam e of t he sit e priorit y group

snam e ( Oracle7 only) Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

m issingrepgroup

– Replicat ion group gnam e does not exist . 23373

nonm ast erdef

– Calling sit e is not t he m ast er definit ion sit e. 23312

referenced

– Sit e priorit y group is used by exist ing conflict resolut ion 23332 m et hod.

Re st r ict ion s You m ust call DROP_SI TE_PRI ORI TY from t he m ast er definit ion sit e.

D BM S_ REPCAT.D ROP_ SI TE_ PRI ORI TY_ SI TE

456

Oracle Distributed Systems The DROP_SI TE_PRI ORI TY_SI TE procedure rem oves a sit e from a sit e priorit y. The change t akes effect im m ediat ely. Specificat ions for Oracle7 and Oracle8 differ as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.DROP_SITE_PRIORITY_SITE (gname IN VARCHAR2 := '', name IN VARCHAR2, site IN VARCHAR2, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.DROP_SITE_PRIORITY_SITE (gname IN VARCHAR2 := '', name IN VARCHAR2, site IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group t o which sit e priorit y group nam e belongs

nam e

Nam e of t he sit e priorit y group

sit e

Global nam e of t he new sit e

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name

Number

Description

m issingpriorit y

–1403

Sit e priorit y does not exist .

m issingrepgroup

–23373

Replicat ion group gnam e does not exist .

nonm ast erdef

–23312

Calling sit e is not t he m ast er definit ion sit e.

Re st r ict ion s You m ust call DROP_SI TE_PRI ORI TY_SI TE from t he m ast er definit ion sit e.

D BM S_ REPCAT.D ROP_ SN APSH OT_ REPGROUP

The DBMS_REPCAT package’s DROP_SNAPSHOT_REPGROUP procedure is t he count erpart t o t he CREATE_SNAPSHOT_REPGROUP procedure. This procedure drops an exist ing snapshot replicat ion group and, opt ionally, all of it s cont ent s.

457

Oracle Distributed Systems PROCEDURE DBMS_REPCAT>DROP_SNAPSHOT_REPGROUP (gname IN VARCHAR2, drop_contents IN BOOLEAN := FALSE);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he snapshot group.

drop_cont ent s

I f TRUE, obj ect s in gnam e are dropped. I f FALSE ( t he default ) t hey are sim ply no longer replicat ed.

Ex ce pt ion s Exception Name

Number

Description

m issingrepgroup

–23373

Replicat ion group gnam e does not exist .

nonm ast er

–23313

Calling sit e is not a snapshot sit e.

Re st r ict ion s I f drop_cont ent s is set t o FALSE, t he t riggers creat ed t o support snapshot m odificat ions rem ain.

D BM S_ REPCAT.D ROP_ SN APSH OT_ REPOBJECT

The DROP_SNAPSHOT_REPOBJECT procedure drops an obj ect from a snapshot replicat ion group at t he snapshot sit e and, opt ionally, drops t he obj ect and it s dependent s as well. PROCEDURE DBMS_REPCAT.DROP_SNAPSHOT_REPOBJECT (sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, drop_objects IN BOOLEAN := FALSE);. For param et er descript ions, see t he CREATE_SNAPSHOT_REPOBJECT procedure.

Ex ce pt ion s Exception Name

Number

Description

m issingobj ect

– Obj ect onam e does not exist in m ast er’s replicat ion group 23308 gnam e.

nonsnapshot

– Calling sit e is not a snapshot sit e. 23314

t ypefailure

–

I nvalid value for t ype.

458

Oracle Distributed Systems

23319

Re st r ict ion s I f t he t ype param et er is SNAPSHOT and you do not set t he drop_obj ect s param et er t o TRUE, replicat ion t riggers and associat ed packages rem ain in t he schem a, and deferred t ransact ions ( if any) rem ain in t he deft ran queue.

D BM S_ REPCAT.EXECUTE_ D D L

CREATE_MASTER_REPOBJECT and DROP_MASTER_REPOBJECT do not support every t ype of obj ect . For exam ple, you cannot use t hese procedures t o drop and creat e const raint s. Ent er t he EXECUTE_DDL procedure. EXECUTE_DDL allows you t o perform DDL at one or m ore m ast er sit es. The replicat ion group m ay or m ay not be quiesced. You can m onit or t he progress of t he DDL call by m onit oring t he REPCATLOG dat a dict ionary view ( DBA_REPCATLOG) . PROCEDURE DBMS_DEFER_SYS.EXECUTE_DDL (gname IN VARCHAR2 := '', {master_list IN VARCHAR2 := NULL, | master_table IN dbms_utility.dblink_array,} ddl_text IN VARCHAR2, sname IN VARCHAR2 := '');

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ed obj ect group.

m ast er_list

Com m a- separat ed st ring of m ast er sit e global nam es at which DDL is t o be perform ed. I f NULL ( t he default ) , DDL is applied at all m ast er sit es in t he replicat ion group. Use eit her param et er m ast er_list or m ast er_t able.

m ast er_t able

PL/ SQL t able of m ast er sit e global nam es at which DDL is t o be perform ed. Use eit her param et er m ast er_list or m ast er_t able.

ddl_t ext

DDL st at em ent t o apply.

snam e Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y) . ( Oracle7 only)

Ex ce pt ion s Exception Name

Number

Description

com m failure

– Unable t o com m unicat e wit h t he m ast er sit e. 23317

ddlfailure

– Unable t o perform DDL. 23318

459

Oracle Distributed Systems

nonm ast er

– At least one sit e in m ast er_list or m ast er_t able is not a m ast er 23312 sit e.

nonm ast erdef

– Calling sit e is not a m ast er definit ion sit e. 23312

Re st r ict ion s • •

This procedure m ust be called from t he m ast er definit ion sit e. The replicat ion group m ust already exist .

D BM S_ REPCAT.GEN ERATE_ REPLI CATI ON _ PACKAGE

I n som e sit uat ions, you m ay wish t o generat e only replicat ion support packages. GENERATE_REPLI CATI ON_PACKAGE generat es t he t able_nam e$RP package for t he specified obj ect at all m ast er sit es. The package is required for all t ables part icipat ing in low- level replicat ion. PROCEDURE DBMS_REPCAT.GENERATE_REPLICATION__PACKAGE (sname IN VARCHAR2, oname IN VARCHAR2);

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t o which t able onam e belongs

onam e

Nam e of t able for which package is being generat ed

Ex ce pt ion s Exception Name com m failure

Number

Description

–23317 Unable t o com m unicat e wit h all m ast ers.

dbnot com pat ible –23375 One or m ore m ast ers is a pre- 7.3 release. m issingobj ect

–23308 Table onam e does not exist in schem a snam e.

nonm ast erdef

–23312 Calling sit e is not a m ast er definit ion sit e.

not quiesced

–23310 Replicat ion group t o which obj ect belongs is not quiesced.

Re st r ict ion s • • •

You m ust call t his procedure from t he m ast er definit ion sit e. The replicat ion group m ust be quiesced. The Oracle version m ust be 7.3 or lat er.

D BM S_ REPCAT.GEN ERATE_ REPLI CATI ON _ SUPPORT

460

Oracle Distributed Systems

The GENERATE_REPLI CATI ON_SUPPORT procedure generat es support for replicat ed t ables, packages, and package bodies required t o support replicat ion of t he specified obj ect , which can be a t able, procedure, package, or package body. The t ypical use of GENERATE_REPLI CATI ON_SUPPORT is t o regenerat e t he replicat ion support t riggers and procedures aft er changing a replicat ion group’s m ode of propagat ion. I f t he obj ect is a t able, GENERATE_REPLI CATI ON_SUPPORT creat es t he t able_nam e$RT t riggers on t he t able, as well as t he t able_nam e$RP and t able_nam e$RR packages at all m ast er sit es. I f t he obj ect is a procedure, package or package body, GENERATE_REPLI CATI ON_SUPPORT generat es t he requisit e procedure wrappers for it . The nam e of t he wrapper procedure is in t he form at package_prefixonam e for packages and package bodies, and procedure_prefixonam e for procedures. I f t he param et ers package_prefix or procedure_prefix are not supplied, t he default prefix DEFER_ is used. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, package_prefix IN VARCHAR2 := NULL, procedure_prefix IN VARCHAR2 := NULL, distributed IN BOOLEAN := TRUE, gen_objs_owner IN VARCHAR2 := NULL, gen_rep2_trigger IN BOOLEAN := FALSE); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, package_prefix IN VARCHAR2 := NULL, procedure_prefix IN VARCHAR2 := NULL, distributed IN BOOLEAN := TRUE, gen_objs_owner IN VARCHAR2 := NULL, min_communication IN BOOLEAN := TRUE); Alt hough it can t ake t im e for each call t o GENERATE_REPLI CATI ON_SUPPORT t o generat e all required packages at all m ast er sit es, you can call it num erous t im es ( for all obj ect s you are replicat ing) wit hout wait ing for each call t o finish it s work.

461

Oracle Distributed Systems

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t o which t able onam e belongs.

onam e

Nam e of t able for which package is being generat ed.

t ype

Obj ect t ype. Support ed t ypes: TABLE, PROCEDURE, PACKAGE, and PACKAGE BODY.

package_prefix

Prefix used t o nam e generat ed wrapper package for packages and package bodies.

procedure_prefix

Prefix used t o nam e generat ed wrapper package for procedures.

dist ribut ed

I f TRUE ( t he default ) , generat e replicat ion support for t he obj ect at each m ast er; if FALSE, copy t he replicat ion support obj ect s generat ed at t he m ast er definit ion sit e.

gen_obj s_owner

Specifies schem a in which t o generat e replicat ion support obj ect s; if NULL ( t he default ) , obj ect s are generat ed under schem a snam e.

gen_rep2_t rigger ( Oracle7 only)

Provided for backward com pat ibilit y; if any m ast ers are pre7.3 releases, t his m ust be set t o TRUE. The default is FALSE.

m in_com m unicat ion ( Oracle8 only)

I f TRUE ( t he default ) , Oracle propagat es changes wit h t he m inim um com m unicat ion param et er, which avoids sending t he old and new colum n values of unm odified fields.

Ex ce pt ion s Exception Name com m failure

Number

Description

–23317 Unable t o com m unicat e wit h all m ast ers.

dbnot com pat ible –23375 One or m ore m ast ers is a pre- 7.3 release. m issingobj ect

–23308 Table onam e does not exist in schem a snam e.

m issingschem a

–23306 Schem a snam e does not exist .

nonm ast erdef

–23312 Calling sit e is not a m ast er definit ion sit e.

not quiesced

–23310 Replicat ion group t o which obj ect belongs is not quiesced.

t ypefailure

–23319 Specified t ype is not a support ed t ype.

Re st r ict ion s •

• •

•

•

You m ust call t his procedure from t he m ast er definit ion sit e for each obj ect in t he replicat ion group. The replicat ion group m ust be quiesced. I f t he obj ect is not owned by t he replicat ion adm inist rat or account , t he owner m ust have explicit EXECUTE privileges on t he DBMS_DEFER package. I f t he I NI T.ORA param et er COMPATI BLE is 7.3 or higher, t he dist ribut ed param et er m ust be set t o TRUE. I f t he I NI T.ORA param et er COMPATI BLE is less t han 7.3 in any snapshot sit es, t he gen_rep2_t rigger param et er m ust be set t o TRUE, and t he COMPATI BLE param et er at t he m ast er definit ion sit e m ust be set t o 7.3.0.0 or great er.

462

Oracle Distributed Systems

D BM S_ REPCAT.GEN ERATE_ REPLI CATI ON _ TRI GGER

The GENERATE_REPLI CATI ON_TRI GGER procedure allow s you t o generat e replicat ion support t riggers. The procedure generat es t he t able_nam e$TP t rigger and associat ed packages for t he specified obj ect . The specificat ions differ for Oracle7 and Oracle8 as follows. The first form of t he procedure shown here generat es t he obj ect s at all m ast ers. Eit her form can be used t o generat e support at specific m ast er sit es. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.GENERATE_REPLICATION_TRIGGER (sname IN VARCHAR2, oname IN VARCHAR2, gen_objs_owner IN VARCHAR2 := NULL, gen_rep2_trigger IN BOOLEAN := FALSE); PROCEDURE DBMS_REPCAT.GENERATE_REPLICATION_TRIGGER (gname IN VARCHAR2, {master_list IN VARCHAR2 := NULL | master_table IN dbms_utility.dblink_array}, gen_objs_owner IN VARCHAR2 := NULL); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.GENERATE_REPLICATION_TRIGGER (sname IN VARCHAR2, oname IN VARCHAR2, gen_objs_owner IN VARCHAR2 := NULL, min_communication IN BOOLEAN := TRUE); PROCEDURE DBMS_REPCAT.GENERATE_REPLICATION_TRIGGER (gname IN VARCHAR2, gen_objs_owner IN VARCHAR2 := NULL, min_communication IN BOOLEAN := NULL);

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t o which t able onam e belongs.

onam e

Nam e of obj ect for which support obj ect s are being generat ed.

gen_rep2_t rigger ( Oracle7 only)

Provided for backward com pat ibilit y; if any m ast er sit es are pre- 7.3 releases, t his param et er m ust be set t o TRUE ( default is FALSE) .

gnam e

The replicat ion group t o which onam e belongs.

m ast er_list

Com m a- delim it ed st ring of global nam es for m ast ers in which support obj ect s are t o be generat ed.

m ast er_t able

PL/ SQL t able of global nam es for m ast ers in which support

463

Oracle Distributed Systems

obj ect s are t o be generat ed. gen_obj s_owner

Specifies schem a in which t o generat e replicat ion support obj ect s; if NULL ( t he default ) , obj ect s are generat ed under schem a in which t hey current ly reside.

m in_com m unicat ion ( Oracle8 only)

I f TRUE ( t he default ) , t he generat ed t rigger sends t he new value of a colum n only if t he value has changed. Old field values are sent only if t he field is part of t he prim ary key or part of a colum n group for which m em ber colum ns have changed.

Ex ce pt ion s Exception Name

Number

Description

com m failure

– Unable t o com m unicat e wit h all m ast ers. 23317

dbnot com pat ible

– One or m ore m ast ers is a pre- 7.3 release and 23375 gen_rep2_t rigger is not set t o TRUE.

m issingobj ect

– Table onam e does not exist in schem a snam e. 23308

m issingschem a

– Schem a snam e does not exist . 23306

nonm ast erdef

– Calling sit e is not a m ast er definit ion sit e. 23312

not quiesced

– Replicat ion group t o which obj ect belongs is not quiesced. 23310

Re st r ict ion s • • •

You m ust call t his procedure from t he m ast er definit ion sit e. The replicat ion group m ust be quiesced. The GENERATE_REPLI CATI ON_SUPPORT or GENERATE_REPLI CATI ON_PACKAGE m ust previously have been called for t he obj ect specified in t he onam e param et er.

D BM S_ REPCAT.M AKE_ COLUM N _ GROUP

The MAKE_COLUMN_GROUP procedure creat es a new colum n group and designat es colum ns t o it . I t provides t he funct ional equivalent of calling DEFI NE_COLUMN_GROUP followed by ADD_GROUPED_COLUMN. PROCEDURE DBMS_REPCAT.MAKE_COLUMN_GROUP (sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, {list_of_column_names IN VARCHAR2 | list_of_column_names IN dbms_repcat.varchar2s} );

464

Oracle Distributed Systems Not e t hat you m ust specify only one of t he list _of_colum n_nam es param et ers.

Pa r a m e t e r s Parameter Name snam e

Description Nam e of t he schem a t o which t he replicat ed t able belongs.

onam e

Nam e of t he replicat ed t able cont aining t he colum n group.

colum n_group

Nam e of t he colum n group.

A com m a- delim it ed list of colum n nam es or a PL/ SQL t able of list _of_colum n_nam es colum n nam es. Use an ast erisk ( * ) t o add all colum ns in t he t able.

Ex ce pt ion s Exception Name

Number

Description

duplicat ecolum n –23333 Colum n( s) already a m em ber of a different colum n group. duplicat egroup

–23330 colum n_group already exist s.

m issingcolum n

–23334 Colum n( s) specified do not exist in t able onam e.

m issingobj ect

–23308 Obj ect onam e does not exist .

nonm ast erdef

–23312 Calling sit e is not m ast er definit ion sit e.

Re st r ict ion s • •

You m ust call t his procedure from t he quiesced m ast er definit ion sit e. You m ust regenerat e replicat ion support for t he t able aft er defining t he colum n group wit h t he GENERATE_REPLI CATI ON_SUPPORT procedure.

D BM S_ REPCAT.PURGE_ M ASTER_ LOG

The PURGE_MASTER_LOG procedure rem oves records from t he DBA_REPCATLOG dat a dict ionary view. Records m ay be rem oved by I D, originat ing m ast er, replicat ion group, or schem a. I f any of t he param et ers is NULL, it is t reat ed as a wildcard. Specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.PURGE_MASTER_LOG (id IN NATURAL, source IN VARCHAR2, gname IN VARCHAR2 := '', sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.PURGE_MASTER_LOG

465

Oracle Distributed Systems (id IN NATURAL, source IN VARCHAR2, gname IN VARCHAR2); To clear all ent ries from t he DBA_REPCATLOG dat a dict ionary view, set all param et ers t o NULL.

Pa r a m e t e r s Parameter Name

Description

id

I dent ificat ion of t he request ( i.e., t he I D field in DBA_REPCATLOG dat a dict ionary view)

source

Global nam e of originat ing m ast er

gnam e

Nam e of t he replicat ion group for which request was m ade

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name Number nonm ast er

Description

–23312 The gnam e is NULL, and calling sit e is not a m ast er sit e.

Re st r ict ion s The calling sit e m ust be a m ast er sit e.

D BM S_ REPCAT.PURGE_ STATI STI CS

I f you are collect ing conflict resolut ion st at ist ics, you can purge t his inform at ion periodically using t he PURGE_STATI STI CS procedure. This procedure rem oves records from t he DBA_REPRESOLUTI ON.STATI STI CS dat a dict ionary view. Records m ay be specified by dat a range. PROCEDURE DBMS_REPCAT.PURGE_STATISTICS (sname IN VARCHAR2, oname IN VARCHAR2, start_date IN DATE, end_date IN DATE); To clear all ent ries in DBA_REPRESOLUTI ON_STATI STI CS, set t he st art _dat e and end_dat e param et ers t o NULL. There are no rest rict ions on calling PURGE_STATI STI CS.

466

Oracle Distributed Systems

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t hat owns onam e.

onam e

Table whose conflict resolut ion st at ist ics are t o be delet ed.

st art _dat e

Beginning of dat e range for which st at ist ics are t o be delet ed. I f NULL, all ent ries less t han end_dat e are delet ed.

end_dat e

End of dat e range for which st at ist ics are t o be delet ed. I f NULL, all ent ries great er t han end_dat e are delet ed.

Ex ce pt ion s Exception Name

Number

Description

m issingobj ect

–23308

Obj ect onam e does not exist .

m issingschem a

–23306

Schem a snam e does not exist .

D BM S_ REPCAT.REFRESH _ SN APSH OT_ REPGROUP

The REFRESH_SNAPSHOT_REPGROUP procedure refreshes t he snapshot replicat ion group m anually. Specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.REFRESH_SNAPSHOT_REPGROUP (gname IN VARCHAR2, drop_missing_contents IN BOOLEAN := FALSE, refresh_snapshots IN BOOLEAN := FALSE, refresh_other_objects IN BOOLEAN := FALSE, execute_as_user IN BOOLEAN:= FALSE); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.REFRESH_SNAPSHOT_REPGROUP (gname IN VARCHAR2, drop_missing_contents IN BOOLEAN := FALSE, refresh_other_objects IN BOOLEAN := FALSE ) The procedure can opt ionally drop obj ect s t hat are no longer in t he group and/ or refresh t he snapshot s and ot her obj ect s. The REFRESH_SNAPSHOT_REPGROUP procedure replaces t he REFRESH_SNAPSHOT_REPSCHEMA procedure. Alt hough REFRESH_SNAPSHOT_REPSCHEMA st ill exist s ( as of Oracle 7.3.3) , do not use it ; it does not exist in Oracle 8.0.3.

467

Oracle Distributed Systems

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group.

drop_m issing_cont ent s

I f TRUE, drop schem a obj ect s t hat are no longer in t he snapshot group. I f FALSE ( t he default ) , obj ect s are sim ply no longer replicat ed.

refresh_snapshot s

I f TRUE, force a refresh of snapshot s in gnam e. Default is FALSE.

refresh_ot her_obj ect s

I f TRUE, refresh nonsnapshot obj ect s in gnam e, such as views and procedures. Nonsnapshot obj ect s are refreshed by dropping and re- creat ing t hem . Default is FALSE.

execut e_as_user ( Oracle7 only)

FALSE ( default ) indicat es t hat t he rem ot e syst em will aut hent icat e calls using t he aut hent icat ion cont ext user who originally queued t he RPC; TRUE indicat es t hat rem ot e syst em will use aut hent icat ion cont ext of t he session user.

Ex ce pt ion s Exception Name

Number

Description

com m failure

–23317

Unable t o com m unicat e wit h t he m ast er sit e.

nonm ast er

–23313

Mast er is no longer a m ast er dat abase.

nonsnapshot

–23314

Calling sit e is not a snapshot sit e.

Re st r ict ion s REFRESH_SNAPSHOT_REPGROUP m ust be called from a snapshot sit e.

D BM S_ REPCAT.REGI STER_ STATI STI CS

The REGI STER_STATI STI CS procedure enables t he collect ion of dat a about t he successful resolut ion of updat e, uniqueness, and delet e conflict s. This inform at ion is visible in t he DBA_REPRESOLUTI ON_STATI STI CS dat a dict ionary view. PROCEDURE DBMS_REPCAT.REGISTER_STATISTICS (sname IN VARCHAR2, oname IN VARCHAR2); These are no rest rict ions on calling REGI STER_STATI STI CS.

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t o which t he replicat ed t able belongs

onam e

Nam e of t he replicat ed t able

468

Oracle Distributed Systems

Ex ce pt ion s Exception Name

Number

Description

m issingobj ect

–23308

Table onam e does not exist .

m issingschem a

–23306

Schem a snam e does not exist .

D BM S_ REPCAT.RELOCATE_ M ASTERD EF

I f your m ast er definit ion sit e becom es unusable or if you sim ply want anot her sit e t o serve t hat role, you can configure a different m ast er sit e as t he m ast er definit ion sit e wit h t he RELOCATE_MASTERDEF procedure. Follow t hese guidelines: •

•

•

I f your relocat ion is planned ( i.e., all sit es are up and reachable) , set t he not ify_m ast ers and include_old_m ast erdef param et ers t o TRUE. I f t he current m ast er definit ion sit e is not available, set t he not ify_m ast ers param et er t o TRUE, and set include_old_m ast erdef t o FALSE. I f t he m ast er definit ion sit e as well as som e m ast er sit es are unavailable, invoke t he RELOCATE_MASTERDEF procedure from each funct ioning m ast er sit e wit h bot h t he not ify_m ast ers and t he include_old_m ast erdef param et ers set t o FALSE.

Neit her t he current m ast er definit ion sit e nor t he new m ast er definit ion sit e need be reachable t o run t his procedure successfully from any given m ast er sit e. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.RELOCATE_MASTERDEF (gname IN VARCHAR2 := '', old_masterdef IN VARCHAR2, new_masterdef IN VARCHAR2, notify_masters IN BOOLEAN := TRUE, include_old_masterdef IN BOOLEAN := TRUE, sname IN VARCHAR2 := '') Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.RELOCATE_MASTERDEF (gname IN VARCHAR2, old_masterdef IN VARCHAR2, new_masterdef IN VARCHAR2, notify_masters IN BOOLEAN := TRUE, include_old_masterdef IN BOOLEAN := TRUE);

Pa r a m e t e r s Parameter Name gnam e

Description Nam e of t he replicat ion group.

469

Oracle Distributed Systems

old_m ast erdef

Global nam e of t he current m ast er definit ion sit e.

new_m ast erdef

Global nam e of t he new m ast er definit ion sit e.

not ify_m ast ers

I f TRUE ( t he default ) , synchronously m ult icast inform at ion about t he change t o all m ast ers; if FALSE, do not inform m ast ers.

include_old_m ast erdef

I f TRUE ( t he default ) , not ify current m ast er definit ion sit e of t he change.

snam e ( Oracle7 only) Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y) .

Ex ce pt ion s Exception Name

Number

Description

com m failure

– Unable t o com m unicat e wit h m ast er sit e( s) and 23317 not ify_m ast ers is TRUE.

nonm ast er

– The new_m ast erdef is not a m ast er sit e. 23313

nonm ast erdef

– The old_m ast erdef is not t he m ast er definit ion sit e. 23312

Re st r ict ion s You m ust call RELOCATE_MASTERDEF from a m ast er or m ast er definit ion sit e.

D BM S_ REPCAT.REM OVE_ M ASTER_ D ATABASES

The REMOVE_MASTER_DATABASES procedure com plem ent s t he ADD_MASTER_DATABASE procedure by rem oving one or m ore m ast er dat abases from a replicat ion group. The m ast er sit es being rem oved do not need t o be accessible, but all ot her m ast ers do. Aft er rem oving m ast er sit es wit h REMOVE_MASTER_DATABASES, you should call DROP_MASTER_REPGROUP at each of t he m ast er sit es you rem oved. Alt hough you do not need t o quiesce t he replicat ion group t o rem ove one or m ore m ast er dat abase( s) , you are st rongly encouraged t o do so. Ot herwise, you will m anually have t o clear t he RPC queue and resolve any inconsist encies. Specificat ion differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.REMOVE_MASTER_DATABASES (gname IN VARCHAR2 := '', master_list IN VARCHAR2, sname IN VARCHAR2 := '');

470

Oracle Distributed Systems Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.REMOVE_MASTER_DATABASES (gname IN VARCHAR2 := '', master_list IN VARCHAR2);,

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group from which t he m ast er sit e( s) will be rem oved.

m ast er_list

A com m a- delim it ed list of global_nam es of m ast er sit es t o be rem oved; use eit her m ast er_list or m ast er_t able.

snam e ( Oracle7 Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y) . only)

Ex ce pt ion s Exception Name

Number

Description

com m failure

–23317 One or m ore rem aining m ast er sit es is not reachable.

nonm ast er

–23313

One or m ore of t he specified m ast ers is not a m ast er dat abase.

nonm ast erdef –23312 Calling sit e is not t he m ast er definit ion sit e. reconfigerror –23316 One of t he specified m ast ers is t he m ast er definit ion sit e.

Re st r ict ion s The REMOVE_MASTER_DATABASES procedure m ust be run from t he m ast er definit ion sit e.

D BM S_ REPCAT.REPCAT_ I M PORT_ CH ECK

From t im e t o t im e, you m ay need t o rebuild a m ast er sit e from an export dum p file as eit her a recovery or m aint enance procedure. Because obj ect I D num bers ( as seen in SYS.OBJ$.OBJ# and DBA_OBJECTS.OBJECT_I D) change during t hese rebuilds, Oracle supplies a procedure ( REPCAT_I MPORT_CHECK) t hat you m ust run im m ediat ely aft er an im port of any m ast er sit e t o synchronize t he new I D num bers wit h t he dat a st ored in t he t able SYSTEM.REPCAT$_REPOBJECT. Obj ect s wit h a st at us of VALI D in REPCAT$_REPOBJECT are not affect ed. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.REPCAT_IMPORT_CHECK

471

Oracle Distributed Systems (gname IN VARCHAR2 := '', master IN BOOLEAN, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.REPCAT_IMPORT_CHECK (gname IN VARCHAR2 := '', master IN BOOLEAN); There are no rest rict ions on calling REPCAT_I MPORT_CHECK. Call REPCAT_I MPORT_CHECK wit h snam e and m ast er set t o NULL ( or wit h no param et ers) t o validat e all replicat ion groups at t he sit e.

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group being revalidat ed

m ast er

Set t o TRUE if sit e is a m aster, FALSE if it is a snapshot sit e

snam e ( Oracle7 only) Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name Number

Description

m issingobj ect

– Obj ect wit h a st at us of VALI D in REPCAT$_REPOBJECT does 23308 not exist .

m issingschem a

– Schem a snam e does not exist . 23306

nonm ast er

– Mast er is set t o TRUE, but t he calling sit e is not a m ast er or 23312 not t he expect ed dat abase.

nonsnapshot

– Mast er is set t o FALSE but t he calling sit e is not a snapshot 23314 sit e.

D BM S_ REPCAT.RESUM E_ M ASTER_ ACTI VI TY

The RESUME_MASTER_ACTI VI TY procedure st art s up an environm ent t hat has been or is in t he process of being quiesced. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.RESUME_MASTER_ACTIVITY (gname IN VARCHAR2 := '', override IN BOOLEAN := FALSE, sname IN VARCHAR2 := '');

472

Oracle Distributed Systems Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.RESUME_MASTER_ACTIVITY (gname IN VARCHAR2, override IN BOOLEAN := FALSE);

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group for which replicat ion act ivit y is t o be resum ed.

override

I f FALSE ( t he default ) , act ivit y is resum ed only aft er all deferred REPCAT act ivit y is com plet ed; if set t o TRUE, act ivit y is resum ed as soon as possible.

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y) .

Ex ce pt ion s Exception Name

Number

Description

com m failure

–23317 Unable t o com m unicat e wit h one or m ore m ast er sit es.

nonm ast erdef

–23312 Calling sit e is not t he m ast er definit ion sit e.

not quiesced

–23310 Replicat ion group gnam e is not quiesced.

Re st r ict ion s • •

You m ust run t his procedure from t he m ast er definit ion sit e. The replicat ion group m ust be quiesced or quiescing.

D BM S_ REPCAT.SEN D _ AN D _ COM PARE_ OLD _ VALUES ( Or a cle 8 On ly)

The default behavior of advanced replicat ion is t o send t he old and new values of every colum n t o part icipat ing m ast er sit es whenever you updat e a row in a replicat ed t able. At t he dest inat ion sit es, Oracle uses t his inform at ion t o ensure t hat t he version of t he row t hat you updat ed m at ches t he version of t he row current ly at t he dest inat ion. However, if you know t hat cert ain colum ns in a t able will never change, you can avoid sending t he dat a in t hese colum ns when you propagat e updat es t o part icipat ing m ast er sit es. Using t he SEND_AND_COMPARE_OLD_VALUES procedure ( available only in Oracle8) in t his way, you’ll reduce propagat ion overhead. PROCEDURE DBMS_REPCAT.SEND_AND_COMPARE_OLD_VALUES (sname IN VARCHAR2 oname IN VARCHAR2,

473

Oracle Distributed Systems {column_list IN VARCHAR2 | column_table IN dbms_repcat.varchar2s}, operation IN VARCHAR2 := 'UPDATE', send IN BOOLEAN := TRUE); The configurat ion changes you specify wit h t his procedure do not t ake effect unless t he m in_com m unicat ion param et er is TRUE for t he t able in quest ion. That is, you m ust have execut ed GENERATE_REPLI CATI ON_SUPPORT for t he t able wit h m in_com m unicat ion = TRUE. I f you change t he propagat ion m ode in Oracle8, you m ust also regenerat e t he SEND_AND_COMPARE_OLD_VALUES procedure.

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he replicat ion group whose propagat ion m ode is being alt ered.

onam e

Table being alt ered.

colum n_list

Com m a- separat ed list of colum ns whose propagat ion m ode is being alt ered; an ast erisk ( * ) indicat es all nonkey colum ns.

colum n_t able

PL/ SQL t able of cont aining colum ns whose propagat ion is being alt ered.

operat ion

Operat ion for which t his change applies; t his m ay be UPDATE, DELETE, or an ast erisk ( * ) ( indicat ing bot h updat es and delet es) .

send

I f TRUE ( t he default ) , t hen t he old values for t he colum ns are sent ; if FALSE, t hen old values are not sent .

Ex ce pt ion s Exception Name

Number

Description

m issingcolum n

–23334

Colum n( s) specified do not exist in t able onam e.

m issingobj ect

–23308

Obj ect onam e does not exist .

nonm ast erdef

–23312

Calling sit e is not t he m ast er definit ion sit e.

not quiesced

–23310

Replicat ion group gnam e is not quiesced.

t ypefailure

–23319

The onam e is not a t able.

Re st r ict ion s • •

You m ust call t his procedure from t he m ast er definit ion sit e. The replicat ion group snam e m ust be quiesced.

D BM S_ REPCAT.SET_ COLUM N S

474

Oracle Distributed Systems When you replicat e a t able, Oracle m ust be able t o uniquely ident ify each record in t he t able so t hat it can propagat e changes t o t he correct row or rows. By default , t he advanced replicat ion facilit ies use t he prim ary key t o ident ify rows. However, if your t able does not have a prim ary key or if you wish t o use a different crit erion t o uniquely ident ify records, you can use SET_COLUMNS t o designat e a pseudo prim ary key. Colum ns designat ed wit h t his procedure m ay cont ain NULL values. PROCEDURE DBMS_REPCAT.SET_COLUMNS (sname IN VARCHAR2, oname IN VARCHAR2, column_list IN VARCHAR2 | column_table IN dbms_utility.name_array);

Pa r a m e t e r s Parameter Name

Description

snam e

Nam e of t he schem a t hat owns t he replicat ed t able.

onam e

Nam e of t he t able wit h t he colum n_group.

colum n_list

A com m a- delim it ed list of colum n nam es t o use as t he pseudo prim ary key. Use eit her colum n_list or colum n_t able.

colum n_t able

A PL/ SQL t able of colum n nam es. Use eit her colum n_list or colum n_t able.

Ex ce pt ion s Exception Name

Number

Description

m issingcolum n

–23334

Colum n( s) specified do not exist in t able onam e.

m issingobj ect

–23308

Table onam e does not exist .

nonm ast erdef

–23312

I nvoking sit e is not t he m ast er definit ion sit e.

Re st r ict ion s • •

SET_COLUMNS m ust be run from t he m ast er definit ion sit e. The changes do not t ake effect unt il t he next call t o GENERATE_REPLI CATI ON_SUPPORT.

D BM S_ REPCAT.SUSPEN D _ M ASTER_ ACTI VI TY

You m ay have not iced t hat m any of t he DBMS_REPCAT procedures require you t o quiesce t he environm ent before using t hem . Quiescence, as it is called, accom plishes t wo t hings: • •

I t applies all out st anding DML for t he replicat ion group at all m ast er sit es. I t prevent s any addit ional DML on any of t he replicat ed obj ect s at all m ast er sit es.

475

Oracle Distributed Systems I n ot her words, quiescence ensures t hat all sit es are up t o dat e and forces t he replicat ed environm ent t o st and st ill. Do not at t em pt t o quiesce an environm ent t hat has unresolved errors or any ot her serious problem s. I f you cannot com plet e out st anding t ransact ions, you will not be able t o quiesce t he environm ent . The SUSPEND_MASTER_ACTI VI TY procedure quiesces an environm ent . I t propagat es all deferred t ransact ions and RPCs and t hen disables all replicat ion act ivit y. Alt hough t his procedure allows you t o specify a replicat ion group in Version 7.x dat abases, all replicat ion groups whose m ast er definit ion sit e is t he invoking sit e are quiesced. Group- level quiescence is available wit h Oracle8. This call can t ake som e t im e t o com plet e if you have m any m ast er sit es or m any out st anding t ransact ions. You can m onit or t he progress by querying t he st at us field in t he DBA_REPCATLOG dat a dict ionary view. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY (gname IN VARCHAR2 := '', execute_as_user IN BOOLEAN := FALSE, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY (gname IN VARCHAR2, override IN BOOLEAN := FALSE);

Pa r a m e t e r s Parameter Name

Description Nam e of t he replicat ion group for which replicat ion act ivit y is t o be suspended.

gnam e

FALSE ( t he default ) indicat es t hat t he rem ot e syst em will aut hent icat e calls using t he aut hent icat ion cont ext user who execut e_as_user originally queued t he RPC; TRUE indicat es t hat t he rem ot e syst em will use aut hent icat ion cont ext of t he session user. snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y) .

Ex ce pt ion s Exception Name

Number

Description

com m failure

–23317 Unable t o com m unicat e wit h one or m ore m ast er sit es.

nonm ast erdef

–23312 Calling sit e is not t he m ast er definit ion sit e.

not norm al

–23311 Replicat ion group gnam e is not in NORMAL st at e.

476

Oracle Distributed Systems

Re st r ict ion s • •

You m ust run t his procedure from t he m ast er definit ion sit e. Prior t o Oracle8, t his procedure quiesces all replicat ion groups at t he m ast er definit ion sit e, not j ust t he group specified by t he gnam e param et er.

D BM S_ REPCAT.SW I TCH _ SN APSH OT_ M ASTER

The SWI TCH_SNAPSHOT_MASTER procedure let s you swit ch a snapshot replicat ion group t o a different m ast er sit e. This procedure changes t he m ast er sit e for t he specified snapshot group. The new m ast er sit e m ust cont ain a replica of t he replicat ion group gnam e. The next t im e t he snapshot group refreshes, Oracle perform s a full refresh. Put snapshot logs on t he m ast er t ables at t he new m ast er sit e so t hat you can use fast refreshes. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.SWITCH_SNAPSHOT_MASTER (gname IN VARCHAR2 := '', master IN VARCHAR2, execute_as_user IN BOOLEAN := FALSE, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDURE DBMS_REPCAT.SWITCH_SNAPSHOT_MASTER (gname IN VARCHAR2 := '', master IN VARCHAR2)

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he snapshot group.

m ast er

Nam e of t he new m ast er sit e.

execut e_as_user ( Oracle7 only) snam e ( Oracle7 only)

FALSE ( t he default ) indicat es t hat t he rem ot e syst em will aut hent icat e calls using t he aut hent icat ion cont ext user who originally queued t he RPC; TRUE indicat es t hat t he rem ot e syst em will use aut hent icat ion cont ext of t he session user. Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y) .

Ex ce pt ion s Exception Name

Number

Description

477

Oracle Distributed Systems

com m failure

–23317

Unable t o com m unicat e wit h t he m ast er sit e.

nonm ast er

–23312

The m ast er param et er is not a m ast er sit e.

nonsnapshot

–23314

Calling sit e is not a snapshot sit e.

Re st r ict ion s • •

The new m ast er sit e m ust cont ain a replica of t he replicat ion group gnam e. Snapshot s whose query is great er t han 32K cannot be rem ast ered.

D BM S_ REPCAT.VALI D ATE

The VALI DATE funct ion diagnoses t he st at us of your replicat ed environm ent and ret urns any errors in eit her a PL/ SQL array of records ( error_t able) or a pair of arrays wit h error t ext ( error_m sg_t able) and error num bers ( error_num _t able) . FUNCTION validate(gname check_genflags check_valid_objs check_links_sched check_links error_table

IN IN IN IN IN OUT

VARCHAR2, BOOLEAN := FALSE, BOOLEAN := FALSE, BOOLEAN := FALSE, BOOLEAN := FALSE, dbms_repcat.validate_err_table)

FUNCTION validate(gname IN VARCHAR2, check_genflags IN BOOLEAN := FALSE, check_valid_objs IN BOOLEAN := FALSE, check_links_sched IN BOOLEAN := FALSE, check_links IN BOOLEAN := FALSE, error_msg_table OUT dbms_utility.uncl_array, error_num_table OUT dbms_utility.number_array) RETURN BINARY_INTEGER; The ret urn value of t hese funct ions is t he num ber of errors det ect ed. There are no rest rict ions on calling t his funct ion.

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group.

check_genflags

Boolean flag indicat ing whet her t o check t hat all replicat ed obj ect s have replicat ion support generat ed.

check_valid_obj s

Boolean flag which checks whet her or not all replicat ed obj ect s are valid. This check is perform ed at all m ast er sit es.

check_links_sched

Boolean flag t o check if pushes are scheduled t o all m ast er dat abases.

check_links

Boolean flag which checks if t he user invoking t he procedure has

478

Oracle Distributed Systems

valid dat abase links t o all m ast er dat abases. error_t able

PL/ SQL t able of errors found.

error_m sg_t able

Error m essage t ext of any errors found.

error_num _t able

Oracle error num ber for any errors found.

Ex ce pt ion s Exception Name

Number

Description

m issingdblink

– The dat abase link does not exist for t he replicat ion 23396 propagat or account , or pushes are not scheduled.

dblinkm ism at ch

– The dat abase link nam e at t he local sit e does not m at ch 23397 t he global nam e of t he dat abase t o which it connect s.

dblinkuidm ism at ch

– The replicat ion propagat or account s are not t he sam e at 23398 all sit es.

obj ect not generat ed

– Replicat ion support has not been generat ed for t he 23399 obj ect at all m ast er sit es.

opnot support ed

– Not all sit es are Oracle8. 23408

D BM S_ REPCAT.W AI T_ M ASTER_ LOG

You can use t he WAI T_MASTER_LOG procedure t o ascert ain whet her t he changes in t he repcat log queue have reached t he m ast er sit es. However, you m ight find it m ore convenient t o query t he DBA_REPCATLOG dat a dict ionary view direct ly. This procedure has an OUT param et er, t rue_count , which t he procedure populat es wit h t he num ber of out st anding ( incom plet e) t asks. The specificat ions differ for Oracle7 and Oracle8 as follows. Oracle7 specificat ion: PROCEDURE DBMS_REPCAT.WAIT_MASTER_LOG (gname IN VARCHAR2 := '', record_count IN NATURAL, timeout IN NATURAL, true_count OUT NATURAL, sname IN VARCHAR2 := ''); Oracle8 specificat ion: PROCEDUREDBMS_REPCAT.WAIT_MASTER_LOG (gname IN VARCHAR2, record_count IN NATURAL, timeout IN NATURAL, true_count OUT NATURAL); There are no rest rict ions on calling WAI T_MASTER_LOG.

479

Oracle Distributed Systems

Pa r a m e t e r s Parameter Name

Description

gnam e

Nam e of t he replicat ion group

record_count

Num ber of records t o allow t o be ent ered in t he DBA_REPCATLOG dat a dict ionary view before ret urning

t im eout

Num ber of seconds t o wait before ret urning

t rue_count

Out put variable cont aining t he act ual num ber of incom plet e act ivit ies queued in t he DBA_REPCATLOG dat a dict ionary view

snam e ( Oracle7 only)

Schem a nam e ( provided for pre- Oracle 7.3 com pat ibilit y)

Ex ce pt ion s Exception Name nonm ast er

Number –23312

Description Calling sit e is not a m ast er sit e.

A.9 D BM S_ REPCAT_ AD M I N : Se t t in g Up Adm in ist r a t ive Account s The first st ep in creat ing an advanced replicat ion environm ent is t o creat e adm inist rat ive and end user account s. The DBMS_REPCAT_AUTH and DBMS_REPCAT_ADMI N packages cont ain program s t hat grant and revoke t he privileges required in such an environm ent .

A.9 .1 H ow t h e Pa ck a ge I s Use d The replicat ion adm inist rat ion account or a DBA account uses t he procedures in DBMS_REPCAT_ADMI N t o grant or revoke t he specified privileges.

A.9 .2 I n st a lla t ion a n d Acce ss The DBMS_REPCAT_ADMI N package is creat ed when t he Oracle dat abase is inst alled. The dbm srepc.sql script ( found in t he built - in packages source direct ory) cont ains t he source code for t his package’s specificat ion. This script is called by cat rep.sql, which m ust be run t o inst all t he advanced replicat ion packages. The wrapped SQL script prvt repc.sql creat es t he public synonym DBMS_REPCAT_ADMI N. No EXECUTE privileges are grant ed on DBMS_REPCAT_ADMI N; only t he owner ( SYS) and t hose wit h t he EXECUTE ANY PROCEDURE syst em privilege m ay execut e t he package.

A.9 .3 D BM S_ REPCAT_ AD M I N Pr oce du r e s Oracle8 docum ent s only t he REPGROUP procedures list ed here, alt hough t he REPSCHEMA procedures also exist . The funct ionalit y is ident ical. Procedure Name

Description

480

Oracle Distributed Systems

GRANT_ADMI N_ANY_REPGROUP ( Oracle8)

Grant s privileges required t o adm inist er any replicat ion group at t he current sit e

GRANT_ADMI N_ANY_REPSCHEMA

Grant s privileges required t o adm inist er any replicat ion schem a at t he current sit e

Grant s privileges required t o adm inist er t he GRANT_ADMI N_REPGROUP ( Oracle8) replicat ion group for which t he user is t he schem a owner GRANT_ADMI N_REPSCHEMA

Grant s privileges required t o adm inist er t he replicat ion schem a for which t he user is t he schem a owner

REVOKE_ADMI N_ANY_REPGROUP ( Oracle8)

Revokes privileges required t o adm inist er all replicat ion groups

REVOKE_ADMI N_ANY_REPSCHEMA

Revokes privileges required t o adm inist er all replicat ion schem as

REVOKE_ADMI N_REPGROUP ( Oracle8)

Revokes privileges required t o adm inist er t he replicat ion group for which t he user is t he schem a owner

REVOKE_ADMI N_REPSCHEMA

Revokes privileges required t o adm inist er t he replicat ion schem a for which t he user is t he schem a owner

A.9 .4 D BM S_ REPCAT_ AD M I N Ex ce pt ion s The DBMS_REPCAT_ADMI N package m ay raise except ion ORA- 01917 if t he specified user does not exist .

D BM S_ REPCAT_ AD M I N .GRAN T_ AD M I N _ AN Y_ REPGROUP

The GRANT_ADMI N_ANY_REPGROUP procedure grant s t he privileges required t o adm inist er any replicat ion group at t he current sit e. PROCEDURE DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_REPGROUP (userid IN VARCHAR2); userid is t he Oracle user I D for whom you are grant ing privileges. There are no rest rict ions on calling GRANT_ADMI N_ANY_REPGROUP. This procedure replaces GRANT_ADMI N_ANY_REPSCHEMA. The specific privileges grant ed are: ALTER ANY CLUSTER

ALTER ANY I NDEX

ALTER ANY PROCEDURE

ALTER ANY SEQUENCE

ALTER ANY SNAPSHOT

ALTER ANY TABLE

481

Oracle Distributed Systems

ALTER ANY TRI GGER

ALTER SESSI ON

CREATE ANY CLUSTER

CREATE ANY I NDEX

CREATE ANY PROCEDURE

CREATE ANY SEQUENCE

CREATE ANY SNAPSHOT

CREATE ANY SYNONYM

CREATE ANY TABLE

CREATE ANY TRI GGER

CREATE ANY VI EW

CREATE DATABASE LI NK

CREATE SESSI ON

DELETE ANY TABLE

DROP ANY CLUSTER

DROP ANY I NDEX

DROP ANY PROCEDURE

DROP ANY SEQUENCE

DROP ANY SNAPSHOT

DROP ANY SYNONYM

DROP ANY TABLE

DROP ANY TRI GGER

DROP ANY VI EW

EXECUTE ANY PROCEDURE

I NSERT ANY TABLE

SELECT ANY TABLE

UNLI MI TED TABLESPACE Because t he privileges grant ed t o userid are relat ively powerful, recipient s of t hese grant s should be kept t o an absolut e m inim um . Be sure t o set up a replicat ion adm inist rat or account at every m ast er sit e of a m ult im ast er replicat ion environm ent . I n addit ion, adm inist rat ion will be easiest if you use t he sam e account nam e in all locat ions.

Ex ce pt ion s GRANT_ADMI N _ANY_REPGROUP m ay raise except ion ORA- 01917 if t he specified user does not exist .

D BM S_ REPCAT_ AD M I N .GRAN T_ AD M I N _ REPGROUP

The GRANT_ADMI N_REPGROUP procedure grant s t he privileges required t o adm inist er a replicat ion group for which t he user is t he schem a owner. PROCEDURE DBMS_REPCAT_ADMIN.GRANT_ADMIN_REPGROUP (userid IN VARCHAR2); userid is t he Oracle user I D for whom you are grant ing privileges. This procedure replaces GRANT_ADMI N_REPSCHEMA. The specific privileges grant ed are: ALTER SESSI ON

CREATE CLUSTER

CREATE DATABASE LI NK

CREATE PROCEDURE

482

Oracle Distributed Systems

CREATE SEQUENCE

CREATE SESSI ON

CREATE SNAPSHOT

CREATE SYNONYM

CREATE TABLE

CREATE TRI GGER

CREATE VI EW

EXECUTE ON SYS.DBMS_DEFER

EXECUTE ON SYS.DBMS_DEFER_SYS

EXECUTE ON SYS.DBMS_REPCAT

EXECUTE ON SYS.DBMSOBJGWRAPPER

UNLI MI TED TABLESPACE

GRANT_ADMI N_REPGROUP is not useful if your replicat ion group cont ains obj ect s belonging t o m ult iple schem as. Such a replicat ion group has t o be adm inist ered by a user who has been grant ed privileges via GRANT_ADMI N_ANY_REPGROUP. There are no rest rict ions on calling GRANT_ADMI N_REPGROUP.

Ex ce pt ion s GRANT_ADMI N.REPGROUP m ay raise except ion ORA- 01917 if t he specified user does not exist .

D BM S_ REPCAT_ AD M I N .REVOKE_ AD M I N _ AN Y_ REPGROUP

The REVOKE_ADMI N_ANY_REPGROUP procedure revokes t he privileges required t o adm inist er any replicat ion group at t he current sit e ( see GRANT_ADMI N_ANY_REPGROUP for a list of t hese privileges) . Not e t hat REVOKE_ADMI N_ANY_REPGROUP revokes privileges regardless of whet her or not t hey were obt ained via GRANT_ADMI N_ANY_REPGROUP. This procedure replaces REVOKE_ADMI N_ANY_SCHEMA, which is now obsolet e. PROCEDURE DBMS_REPCAT_ADMIN.REVOKE_ADMIN_ANY_REPGROUP (userid IN VARCHAR2); userid is t he Oracle user I D for whom you are revoking privileges. There are no rest rict ions on calling REVOKE_ADMI N_ANY_REPGROUP.

Ex ce pt ion s REVOKE_ADMI N_REPGROUP m ay raise except ion ORA- 01917 if t he specified user does not exist .

D BM S_ REPCAT_ AD M I N .REVOKE_ AD M I N _ REPGROUP

483

Oracle Distributed Systems REVOKE_ADMI N_REPGROUP revokes from userid all privileges required t o adm inist er a replicat ion group wit h t he sam e nam e as userid ( see GRANT_ADMI N_REPGROUP for a list of t hese privileges) . Not e t hat REVOKE_ADMI N_REPGROUP revokes privileges regardless of whet her t hey were obt ained via GRANT_ADMI N_REPGROUP. This procedure replaces REVOKE_ADMI N_REPSCHEMA, which is now obsolet e. PROCEDURE DBMS_REPCAT_ADMIN.REVOKE_ADMIN_REPGROUP (userid IN VARCHAR2); userid is t he Oracle user I D for whom you are revoking privileges. There are no rest rict ions on calling REVOKE_ADMI N_REPGROUP.

Ex ce pt ion s REVOKE_ADMI N_REPGROUP m ay raise except ion ORA- 01917 if t he specified user does not exist .

A.1 0 D BM S_ REPCAT_ AUTH : Se t t in g Up M or e Adm in ist r a t ive Accou n t s DBMS_REPCAT_AUTH grant s and revokes privileges t o a user I D t hat is designat ed at each m ast er sit e t o perform replicat ion act ivit ies on behalf of ot her rem ot e m ast ers. I n effect , t he exist ence of such a user I D elim inat es t he need for SYSowned dat abase links bet ween m ast er sit es.

A.1 0 .1 H ow t h e Pa ck a ge I s Use d The replicat ion adm inist rat ion account and/ or a DBA account uses t he t wo procedures in DBMS_REPCAT_AUTH t o grant or revoke t he specified privileges.

A.1 0 .2 I nst a lla t ion a nd Acce ss The DBMS_REPCAT_AUTH package is creat ed when t he Oracle dat abase is inst alled. The dbm srepc.sql script ( found in t he built - in packages source direct ory) cont ains t he source code for t his package’s specificat ion. This script is called by cat rep.sql, which m ust be run t o inst all t he advanced replicat ion packages. The wrapped SQL script prvt repc.sql creat es t he public synonym DBMS_REPCAT_AUTH. No EXECUTE privileges are grant ed on DBMS_REPCAT_AUTH; only t he owner ( SYS) and t hose wit h t he EXECUTE ANY PROCEDURE syst em privilege m ay execut e t he package.

A.1 0 .3 D BM S_ REPCAT_ AUTH Pr oce du r e s Procedure Name

Description

GRANT_SURROGATE_REPCAT

Grant s required privileges t o a specified user

REVOKE_SURROGATE_REPCAT

Revokes required privileges from a specified user

A.1 0 .4 D BM S_ REPCAT_ AUTH Ex ce pt ion s

484

Oracle Distributed Systems The DBMS_REPCAT_AUTH package m ay raise except ion ORA- 01917 if t he specified user does not exist .

D BM S_ REPCAT_ AUTH .GRAN T_ SURROGATE_ REPCAT

GRANT_SURROGATE_REPCAT grant s userid all privileges required t o perform required replicat ion act ivit ies on behalf of t he SYS user at rem ot e m ast ers. Because t he privileges grant ed t o userid are relat ively powerful, recipient s of t hese grant s should be lim it ed t o a single account t hat is used solely for t his purpose ( i.e., t his account is never used int eract ively) . I t is m ost convenient t o use t he sam e account nam e for t he surrogat e SYS user in all m ast er dat abases. PROCEDURE DBMS_REPCAT_AUTH.GRANT_SURROGATE_REPCAT (userid IN VARCHAR2); userid is t he Oracle user I D for whom you are grant ing privileges. There are no rest rict ions on calling GRANT_SURROGATE_REPCAT.

Ex ce pt ion s The GRANT_SURROGATE_REPCAT procedure m ay raise t he except ion ORA- 01917 if t he specified user does not exist .

D BM S_ REPCAT_ AUTH .REVOKE_ SURROGATE_ REPCAT

REVOKE_SURROGATE_REPCAT revokes from userid all privileges required t o perform required replicat ion act ivit ies on behalf of t he SYS user at rem ot e m ast ers. Not e t hat t hese privileges will be revoked regardless of whet her t hey were obt ained via GRANT_SURROGATE_REPCAT. I n addit ion, any privat e synonym s wit h t he sam e nam e as t hose creat ed by REVOKE_SURROGATE_REPCAT will also be dropped. PROCEDURE DBMS_REPCAT_AUTH.REVOKE_SURROGATE_REPCAT (userid IN VARCHAR2); userid is t he Oracle user I D for whom you are revoking privileges. There are no rest rict ions on calling REVOKE_SURROGATE_REPCAT.

Ex ce pt ion s

485

Oracle Distributed Systems The REVOKE_SURROGATE_REPCAT procedure m ay raise except ion ORA- 01917 if t he specified user does not exist .

A.1 1 D BM S_ REPUTI L: En a blin g a n d D isa blin g Re plica t ion Sit uat ions will arise in which you need t o perform DML on a replicat ed t able wit hout propagat ing t he changes t o ot her m ast er sit es. For exam ple, if you have resolved a conflict and wish t o updat e a row m anually, you would not want t o propagat e your change. Or you m ight have a t rigger on a replicat ed t able t hat you want t o fire only for updat es t hat originat e locally. The DBMS_REPUTI L package allows you t o cont rol whet her updat es propagat e for t he current session. I t does t his by set t ing t he global variable replicat ion_is_on, which t he replicat ion t riggers and packages reference.

A.1 1 .1 H ow t h e Pa ck a ge I s Use d The procedures REPLI CATI ON_ON and REPLI CATI ON_OFF are useful for cont rolling t he replicat ion of DML. A t ypical exam ple is DML t hat is perform ed t o get a local t able synchronized wit h ot her m ast ers.

A.1 1 .2 I nst a lla t ion a nd Acce ss The DBMS_REPUTI L package is creat ed when t he Oracle dat abase is inst alled. The dbm sgen.sql script ( found in t he built - in packages source direct ory) cont ains t he source code for t his package’s specificat ion. This script is called by cat rep.sql, which m ust be run t o inst all t he advanced replicat ion packages. The script creat es t he public synonym DBMS_REPUTI L for t he package and grant s EXECUTE privileges on t he package t o public. All Oracle users can reference and m ake use of t his package.

A.1 1 .3 D BM S_ REPUTI L Pr oce du r e s Procedure Name

Description

REPLI CATI ON_OFF

Turns replicat ion off for t he current session

REPLI CATI ON_ON

Turns replicat ion on for t he current session

A.1 1 .4 D BM S_ REPUTI L N on pr ogr a m Ele m e n t s Element Name/Type

Description

replicat ion_is_on/ BOOLEAN

Flag indicat ing whet her DML should be queued for replicat ion

from _rem ot e/ BOOLEAN

Flag indicat ing whet her DML was init iat ed at anot her m ast er sit e

global_nam e/ VARCHAR2( 128) Global nam e of t he current dat abase

D BM S_ REPUTI L.REPLI CATI ON _ OFF

486

Oracle Distributed Systems The REPLI CATI ON_OFF procedure works by set t ing t he package variable replicat ion_is_on t o FALSE. The replicat ion t riggers and procedures can subsequent ly query t his variable. This procedure is as sim ple as it can be: no param et ers, no except ions, and no rest rict ions. PROCEDURE DBMS_REPUTIL.REPLICATION_OFF;

D BM S_ REPUTI L.REPLI CATI ON _ ON

The REPLI CATI ON_ON procedure reverses t he effect of t he REPLI CATI ON_OFF procedure. I t set s t he package variable replicat ion_is_on t o TRUE.

PROCEDURE DBMS_REPUTIL.REPLICATION_ON; There are no except ions or rest rict ions for t his procedure.

A.1 2 D BM S_ SN APSH OT: M a n a gin g Sn a psh ot s The DBMS_SNAPSHOT package cont ains program s t hat allow you t o m aint ain snapshot s and snapshot logs and t o set and query package st at e variables associat ed wit h t he advanced replicat ion facilit ies.

A.1 2 .1 H ow t h e Pa ck a ge I s Use d The procedures I _AM_A_REFRESH and SET_I _AM_A_REFRESH are used t o check and set t he package variable REP$WHAT_AM_I .I _AM_A_SNAPSHOT, which num erous replicat ion t riggers and procedures reference. The procedures PURGE_LOG and REFRESH are t ypically run by t he DBA and/ or scheduled in t he j ob queue.

A.1 2 .2 I nst a lla t ion a nd Acce ss The DBMS_SNAPSHOT package is creat ed when t he Oracle dat abase is inst alled. The dbm ssnap.sql script ( found in t he built - in packages source direct ory) cont ains t he source code for t his package’s specificat ion. This script is called by cat proc.sql, which is norm ally run im m ediat ely aft er dat abase creat ion. The script creat es t he public synonym DBMS_SNAPSHOT for t he package and grant s t he EXECUTE privilege on t he package t o public. All Oracle users can reference and m ake use of t his package.

A.1 2 .3 D BM S_ SN APSH OT Pr oce du r e s Name

Description

BEGI N_TABLE_REORGANI ZATI ON ( Oracle8 only)

Called prior t o reorganizing a m ast er t able ( e.g., t hrough export / im port ) ; saves dat a required t o refresh snapshot s

END_TABLE_REORGANI ZATI ON

Called aft er reorganizing a m ast er t able ( e.g.,

487

Oracle Distributed Systems

( Oracle8 only)

t hrough export / im port ) ; validat es dat a required t o refresh snapshot s

I _AM_A_REFRESH

Ret urns value of REP$WHAT_AM_I .I _AM_A_SNAPSHOT

PURGE_LOG

Purges snapshot log

REFRESH

Refreshes a snapshot

REFRESH_ALL

Refreshes all snapshot s due t o be execut ed.

REGI STER_SNAPSHOT ( Oracle8 only) SET_I _AM_A_REFRESH UNREGI STER_SNAPSHOT ( Oracle8 only)

Records inform at ion about snapshot s at t he m ast er sit e in t he DBA_REGI STERED_SNAPSHOTS dat a dict ionary view Set s REP$WHAT_AM_I .I _AM_A_SNAPSHOT t o specified value Rem oves inform at ion about snapshot s at t he m ast er sit e from t he DBA_REGI STERED_SNAPSHOTS dat a dict ionary view

All of t he program s in DBMS_SNAPSHOT are available regardless of whet her you are using snapshot groups or t he advanced replicat ion facilit ies. DBMS_SNAPSHOT does not define any except ions.

D BM S_ SN APSH OT.BEGI N _ TABLE_ REORGAN I ZATI ON ( Or a cle 8 On ly)

I f you are reorganizing a t able, call t he BEGI N_TABLE_REORGANI ZATI ON procedure before reorganizing t he t able and t he END_TABLE_REORGANI ZATI ON procedure when you are finished. PROCEDURE DBMS_SNAPSHOT.BEGIN_TABLE_REORGANIZATION (tabowner IN VARCHAR2, tabname IN VARCHAR2); There are no except ions or rest rict ions for t his procedure.

Pa r a m e t e r s Parameter Name

Description

t abowner

Owner of t he m ast er t able

t abnam e

Nam e of t he m ast er t able being reorganized

D BM S_ SN APSH OT.EN D _ TABLE_ REORGAN I ZATI ON ( Or a cle 8 On ly) 488

Oracle Distributed Systems

Call t he END_TABLE_REORGANI ZATI ON procedure when you are finished reorganizing a t able. PROCEDURE DBMS_SNAPSHOT.END_TABLE_REORGANIZATION (tabowner IN VARCHAR2 tablename IN VARCHAR2); Param et ers are t he sam e as t hose for BEGI N_TABLE_REORGANI ZATI ON. This procedure does not raise any except ions, and t here are no rest rict ions on calling it .

D BM S_ SN APSH OT.I _ AM _ A_ REFRESH

The I _AM_A_REFRESH funct ion queries t he REP$I _AM_A_REFRESH package variable. I f t his variable is TRUE, t hen t he session is refreshing a snapshot or applying propagat ed DML t o a replicat ed t able. This DML is perform ed on behalf of a replicat ed t ransact ion t hat was init iat ed at anot her m ast er—t hat is, t he DML perform ed by t his session will not be replicat ed because it is t he local applicat ion of rem ot e DML. I _AM_A_REFRESH is used by num erous replicat ion t riggers and procedures t o det erm ine whet her DML should be replicat ed. FUNCTION DBMS_SNAPSHOT.I_AM_A_REFRESH RETURN BOOLEAN; All row- level replicat ion t riggers are aft er- row t riggers. Alt hough a t able can have m ult iple t riggers of t he sam e t ype, you cannot cont rol t he order in which t hey are fired. Therefore, it is safest t o use before- row t riggers t o perform audit ing on replicat ed t ables; in t his way, you are guarant eed t hat before- row t riggers fire before aft er- row t riggers. The funct ion does not raise any except ions, and t here are no rest rict ions on calling it .

D BM S_ SN APSH OT.PURGE_ LOG

Call t he PURGE_LOG procedure t o delet e snapshot log records. PROCEDURE DBMS_SNAPSHOT.PURGE_LOG (master VARCHAR2, num BINARY_INTEGER DEFAULT 1, flag VARCHAR2 DEFAULT 'NOP' );

489

Oracle Distributed Systems To delet e all records from a snapshot log, set t he num param et er t o a high value ( great er t han t he num ber of snapshot s m ast ered t o t he m ast er t able, specified in t he m ast er param et er) . The PURGE_LOG procedure does not raise any except ions, and t here are no rest rict ions on calling it .

Pa r a m e t e r s Parameter Name

Description

m ast er

Nam e of t he m ast er t able.

num

Delet e records required t o refresh t he oldest num ber of unrefreshed snapshot ; default is 1.

flag

Set t o DELETE t o guarant ee t hat records are delet ed for at least one snapshot regardless of t he set t ing of num .

D BM S_ SN APSH OT.REFRESH

Call t he REFRESH procedure t o force a snapshot refresh. The specificat ions for t he Oracle7 and Oracle8 versions of t he REFRESH procedure differ. Not e t hat t he Version 8.0 im plem ent at ion adds param et ers t hat support parallelism and drops t he execut e_as_user param et er. Bot h versions are overloaded, allowing you t o specify t he list of snapshot s as a com m a- delim it ed st ring in t he list param et er or as a PL/ SQL t able in t he t ab param et er. The ot her param et ers are ident ical for t he t wo versions. Oracle7 specificat ion: PROCEDURE DBMS_SNAPSHOT.REFRESH (list IN VARCHAR2, method IN VARCHAR2 DEFAULT NULL, rollback_seg IN VARCHAR2 DEFAULT NULL, push_deferred_rpc IN BOOLEAN DEFAULT TRUE, refresh_after_errors IN BOOLEAN DEFAULT FALSE, execute_as_user IN BOOLEAN DEFAULT FALSE ); PROCEDURE DBMS_SNAPSHOT.REFRESH (tab IN OUT dbms_utility.uncl_array, method IN VARCHAR2 DEFAULT NULL, rollback_seg IN VARCHAR2 DEFAULT NULL, push_deferred_rpc IN BOOLEAN DEFAULT TRUE, refresh_after_errors IN BOOLEAN DEFAULT FALSE, execute_as_user IN BOOLEAN DEFAULT FALSE ); Oracle8 specificat ion: PROCEDURE DBMS_SNAPSHOT.REFRESH

490

Oracle Distributed Systems (list IN VARCHAR2, method IN VARCHAR2 := NULL, rollback_seg IN VARCHAR2 := NULL, push_deferred_rpc IN BOOLEAN := TRUE, refresh_after_errors IN BOOLEAN := FALSE, purge_option IN BINARY_INTEGER := 1, parallelism IN BINARY_INTEGER := 0, heap_size IN BINARY_INTEGER := 0); PROCEDURE DBMS_SNAPSHOT.REFRESH (tab IN OUT dbms_utility.uncl_array, method IN VARCHAR2 := NULL, rollback_seg IN VARCHAR2 := NULL, push_deferred_rpc IN BOOLEAN := TRUE, refresh_after_errors IN BOOLEAN := FALSE, purge_option IN BINARY_INTEGER := 1, parallelism IN BINARY_INTEGER := 0, heap_size IN BINARY_INTEGER := 0); The REFRESH procedure does not raise any except ions.

Pa r a m e t e r s Parameter Name

Description

list

Com m a- separat ed list of snapshot s t o be refreshed. Use list or t ab.

t ab

PL/ SQL t able of snapshot s t o be refreshed. Use list or t ab. Refresh m et hod: “ ?” uses t he default refresh m et hod. I f you specified a refresh m et hod when you creat ed t he snapshot , t hat is t he default m et hod. Ot herwise, Oracle uses a fast refresh if possible and a com plet e refresh if not .

m et hod

“ F” or “ f” uses fast refresh if possible and ret urns ORA- 12004 if not . “ C” or “ c” uses a com plet e refresh. This param et er should include a single charact er for each snapshot specified in list or t ab, in t he sam e order as t he snapshot nam es appear. I f list or t ab cont ains m ore snapshot s t han t he m et hod list , t he addit ional snapshot s are refreshed wit h t heir default m et hod.

rollback_seg

Opt ional; specifies t he rollback segm ent t o use for t he refresh.

push_deferred_rpc

Opt ional; for updat eable snapshot s only. I f TRUE ( t he default ) , t hen local updat es are sent back t o t he m ast er sit e before t he snapshot is refreshed ( ot herwise, local updat es will be t em porarily overwrit t en) .

Opt ional; for updat eable snapshot s only. I f TRUE, proceed wit h t he refresh even if out st anding errors ( conflict s) are logged in refresh_aft er_errors t he DEFERROR dat a dict ionary view at t he m ast er sit e. Default is FALSE.

491

Oracle Distributed Systems

execut e_as_user ( Oracle7 only)

purge_opt ion ( Oracle8 only)

parallelism ( Oracle8 only)

heap_size ( Oracle8 only)

I f FALSE ( t he default ) , t hen t he call t o t he rem ot e syst em is perform ed under t he privilege dom ain of t he user t hat creat ed t he snapshot . I f TRUE, t he call is perform ed as t he user calling t he refresh procedure. I f push_deferred_rpc is TRUE, t his designat es t he purge m et hod; default is 1. 0 = no purge 1 = lazy purge ( opt im ized for t im e) 2 = aggressive purge ( com plet e) I f push_deferred_rpc is TRUE, t his det erm ines t he m axim um degree of parallelism ; default is 1. 0 = serial 1 = parallel wit h one slave n = parallel wit h n slaves ( n > 1) Used only if parallelism > 0. Set s t he m axim um num ber of t ransact ions t o be exam ined sim ult aneously for det erm ining parallel scheduling. Oracle det erm ines t his value int ernally; you are advised not t o use it .

The purge_opt ion param et er cont rols how Oracle purges t he snapshot sit e’s deferred t ransact ion queue; Oracle8 does not purge t he queue aut om at ically when t he t ransact ions propagat e, so you m ust use DBMS_DEFER_SYS.SCHEDULE_PURGE t o schedule a j ob t o purge t he queue, lest it becom e large and unm anageable. The purge_opt ion param et er in REFRESH provides an opport unit y t o purge t he queue of t ransact ions associat ed wit h t he updat eable snapshot s you are refreshing.

Re st r ict ion s You can call REFRESH only from a snapshot sit e.

D BM S_ SN APSH OT.REFRESH _ ALL

The DBMS_SNAPSHOT. REFRESH_ALL refreshes all snapshot s t hat are due t o be execut ed. PROCEDURE DBMS_REFRESH.REFRESH_ALL This procedure has no param et ers, except ions, or rest rict ions.

D BM S_ SN APSH OT.REGI STER_ SN APSH OT ( Or a cle 8 On ly)

492

Oracle Distributed Systems

Generally, t he regist rat ion and unregist rat ion of snapshot s is aut om at ic if bot h t he m ast er and snapshot dat abases are Oracle8. However, in case t he snapshot sit e is running Oracle7 or if t he aut om at ic regist rat ion fails, you can use t he Oracle8 procedure, REGI STER_SNAPSHOT, t o regist er t he snapshot m anually. One of t he m ost significant im provem ent s in Oracle8 is t he aut om at ic regist rat ion of snapshot s at t he m ast er sit e. I n Oracle7, t here was no easy way t o det erm ine t he locat ion—or even t he exist ence—of snapshot s wit h m ast er t able( s) in your inst ance. But when you creat e a snapshot in Oracle8, Oracle put s a record in t he DBA_REGI STERED_SNAPSHOTS dat a dict ionary view. Sim ilarly, when you drop a snapshot , Oracle delet es t he record from DBA_REGI STERED_SNAPSHOTS. The REGI STER and UNREGI STER procedures let you m anually m aint ain t he DBS_REGI STERED_SNAPSHOTS dat a dict ionary view, shown here: Column Name

Description

OWNER

Snapshot owner.

NAME

Snapshot nam e.

SNAPSHOT_SI TE

Global nam e of dat abase where snapshot resides.

CAN_USE_LOG

I f YES, t hen snapshot refreshes can use snapshot log.

UPDATABLE

I f YES, t hen snapshot is an updat eable snapshot .

REFRESH_METHOD Refresh m et hod; eit her ROWI D or PRI MARY KEY. SNAPSHOT_I D

Unique I D of snapshot used for fast refreshes.

VERSI ON

Version of t he snapshot . Possible values are REG_UNKNOWN, REG_V7_GROUP, REG_V8_GROUP, and REG_REPAPI _GROUP.

QUERY_TXT

Text of t he snapshot ’s query.

The regist rat ion of snapshot s is not m andat ory; it records dat a in DBA_REGI STERED_SNAPSHOTS t hat is for inform at ional use only. You should not rely on t he cont ent s of t his dat a dict ionary view. The REGI STER_SNAPSHOT procedure is overloaded; snapshot _id is a DATE t ype if t he snapshot sit e is an Oracle7 dat abase and BI NARY_I NTEGER if it is an Oracle8 dat abase. PROCEDURE DBMS_SNAPSHOT.REGISTER_SNAPSHOT (snapowner IN VARCHAR2, snapname IN VARCHAR2, snapsite IN VARCHAR2, snapshot_id IN DATE | BINARY_INTEGER, flag IN BINARY_INTEGER, qry_txt IN VARCHAR2, rep_type IN BINARY_INTEGER := dbms_snapshot.reg_unknown); REGI STER_SNAPSHOT does not raise any except ions, and t here are no rest rict ions on calling it .

Pa r a m e t e r s

493

Oracle Distributed Systems

Parameter Name

Description

snapowner

Owner of t he snapshot .

snapnam e

Nam e of t he snapshot .

snapsit e

Global nam e of snapshot sit e dat abase inst ance.

I D of t he snapshot . Use DATE dat at ype for Oracle7 snapshot sit es, snapshot _id BI NARY_I NTEGER for Oracle8 snapshot sit es. The snapshot _id and flag param et ers are m ut ually exclusive. flag

PL/ SQL variable dict at ing whet her fut ure m oves and creat es are regist ered in t he qry_t ext param et er; t his flag does not appear t o be used.

qry_t xt

Up t o 32,000 charact ers of t he t ext of t he snapshot query. Binary int eger indicat ing t he version of t he snapshot . Possible values are:

rep_t ype

REG_UNKNOWN = 0 ( t he default ) REG_V7_GROUP = 1 REG_V8_GROUP = 2 REG_REPAPI _GROUP = 3

D BM S_ SN APSH OT.SET_ I _ AM _ A_ REFRESH

The SET_I _AM_A_REFRESH procedure set s t he REP$WHAT_AM_I .I _AM_A_SNAPSHOT package variable t o a specified value. I f t his variable is TRUE, t hen t he session m aking t he call is perform ing local DML on behalf of a replicat ed t ransact ion t hat was init iat ed at anot her m ast er. That is, t he DML perform ed by t his session will not be replicat ed because it is t he local applicat ion of rem ot e DML. Use t his package carefully, because disabling replicat ion t riggers effect ively disables any conflict resolut ion m echanism s you m ay have defined. PROCEDURE DBMS_SNAPSHOT.SET_I_AM_A_REFRESH

(value IN BOOLEAN);

value is t he value ( Y or N) being set . This procedure does not raise any except ions.

D BM S_ SN APSH OT.UN REGI STER_ SN APSH OT ( Or a cle 8 On ly)

The UNREGI STER_SNAPSHOT procedure is t he flip side of t he REGI STER_SNAPSHOT procedure. You use UNREGI STER_SNAPSHOT when you need t o m anually unregist er

494

Oracle Distributed Systems a snapshot . This procedure unregist ers snapshot s at t he m ast er sit e, regardless of whet her t hey were regist ered m anually or aut om at ically. PROCEDURE DBMS_SNAPSHOT.UNREGISTER_SNAPSHOT (snapowner IN VARCHAR, snapname IN VARCHAR2, snapsite IN VARCHAR2) See t he descript ion of param et ers under t he REGI STER_SNAPSHOT procedure. UNREGI STER_SNAPSHOT does not raise any except ions and t here are no rest rict ions on calling it . Unre gist ering a snapshot has no effect on t he snapshot it self.

495

Oracle Distributed Systems

496

Oracle Distributed Systems

Appe n dix B. Scr ipt s a n d Ut ilit ie s This appendix cont ains a collect ion of script s and ut ilit ies t hat I find useful when adm inist ering dist ribut ed syst em s. Many of t he script s are described, or at least m ent ioned, in t his book. Each cont ains a brief descript ion of it s funct ion. Alt hough I have t est ed t hese script s and ut ilit ies and use t hem on a regular basis, plat form s and configurat ions differ, so be sure t o t est t hem in your own environm ent . These script s and ut ilit ies are also available at t he O'Reilly web sit e; see t he Preface for det ails.

B.1 bu sycir c.sql --------------------------------------------------------------------------- Filename: busycirc.sql -- Purpose: Provides stats indicating whether or not a given circuit -is overly taxed in a Multi-Threaded Server environment. -- Author: Chas. Dye ([email protected]) -- Date: 6-Aug-1998 -------------------------------------------------------------------------column server heading "Server" format a8 column circuit heading "Name" format a8 column status heading "Status" format a8 column message0 heading "Bytes|in|First|Msg|Buf" format 9,999 column message1 heading "Bytes|in|Second|Msg|Buf" format 9,999 column messages heading "Messages|Processed" format 999,999 column queue heading "Queue" format a10 column bytes heading "Bytes" format 9,999,999 column breaks heading "Brks" format 999 SELECT

server, circuit, status, queue, message0, message1, messages, bytes, breaks FROM v$circuit ORDER BY server /

B.2 bu sydisp.sql --------------------------------------------------------------------------- Filename: busydisp.sql -- Purpose: Provides stats indicating whether the dispatcher processes

497

Oracle Distributed Systems -are overly taxed. -- Author: Chas. Dye ([email protected]) -- Date: 6-Aug-1998 -------------------------------------------------------------------------column network heading "Protocol" format a40 column rate heading "Total Busy Rate|>50%=>Add Dispatchers" format 99.99 SELECT

network, 100*(sum(busy)/(sum(busy)+sum(idle))) rate FROM v$dispatcher GROUP BY network / column protocol heading "Protocol" a40 column Wait heading "Average Wait|(hundredths of seconds)" a30

format format

SELECT

network Protocol, decode( sum(totalq), 0, 'No Responses', to_char(sum(wait)/sum(totalq), 'FM9999.90')) Wait FROM v$queue q, v$dispatcher d WHERE q.type = 'DISPATCHER' AND q.paddr = d.paddr GROUP BY network /

B.3 bu syq.sql --------------------------------------------------------------------------- Filename: busyq.sql -- Purpose: Provides stats indicating whether a given queue is overly -taxed in a Multi-Threaded Server environment. -If the COMMON queue is overly taxed, consider adding more -servers. -- Author: Chas. Dye ([email protected]) -- Date: 6-Aug-1998 -------------------------------------------------------------------------column type heading "Queue|Type" format a10 column circuit heading "Name" format a8 column queued heading "Items|Queued" format 999,999 column wait heading "Total|Time|Waited" format 999,999,999 column totalq heading "Total|Items|Processed" format 999,999,999,999 column avgwait heading "Average|Wait" format 9,999.90 set head off set feedback off SELECT FROM

sysdate dual

498

Oracle Distributed Systems / set head on set feedback on SELECT

FROM /

paddr, type, queued, wait, totalq, decode(totalq, 0, 0, wait)/decode(totalq, 0, 1, totalq) avgwait v$queue

B.4 che ck la t e ncy #! /bin/ksh #------------------------------------------------------------------------# Filename: checklatency # Purpose: Notifies dba when more than 150 replicated transactions are # queued. # Author: Chas. Dye ([email protected]) # Date: 21-Oct-1998 # Remarks: Requires OPS$ account for whichever OS user crons this script. #------------------------------------------------------------------------HOST=`/bin/uname -n` MAIL=/bin/mailx DISTLIST="[email protected]" export HOST MAIL DISTLIST # ORACLE_HOME=/u/oracle/product/8.0.4.2 ; export ORACLE_HOME ORACLE_SID=PHQS ; export ORACLE_SID PATH=$ORACLE_HOME/bin:/bin:{PATH} ; export PATH LD_LIBRARY_PATH=$ORACLE_HOME/lib:${LD_LIBRARY_PATH} ; export LD_LIBRARY_PATH # cd ${HOME}/bin # sqlplus -s / 150; spool off EOF # grep 1 latent.log > latent.err if [ -s latent.err ] then

499

Oracle Distributed Systems $MAIL -s"${ORACLE_SID}@${HOST} latency alert" $DISTLIST < latent.log fi # rm -f latent.err rm -f latent.log

B.5 colgr ou ps.sql --------------------------------------------------------------------------- Filename: colgroups.sql -- Purpose: Lists all defined column groups. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------column sname heading "Schema|Name" format a8 column oname heading "Table|Name" format a30 column group_name heading "Column|Group" format a30 column group_comment heading "Comment" format a19 SELECT

sname, oname, group_name FROM dba_repcolumn_group ORDER BY sname, oname, group_name /

B.6 con fst a t s.sql ----------------------------------------------------------------------------- Filename: confstats.sql -- Purpose: Lists conflicts for which statistics are being gathered. -- Author: Chas. Dye ([email protected]) -- Date: 11-Jun-1998 --- Modification History -- -------------------- 11-Jun-1998 : Chas. : Creation -------------------------------------------------------------------------col primary_key_value form a10 col oname form a25 col conflict_type form a10 col method_name form a20 SELECT

FROM /

oname, created, status_update_date dba_represol_stats_control

B.7 cr _ r e gion s.sql --------------------------------------------------------------------------

500

Oracle Distributed Systems -- Filename: cr_regions.sql -- Purpose: Creates the REGIONS table and its public synonym. -- Author: Chas. Dye ([email protected]) -- Date: 12-Jan-1998 -------------------------------------------------------------------------set echo on set termout on spool regions.log DROP PUBLIC SYNONYM regions / DROP TABLE regions CASCADE CONSTRAINTS / CREATE TABLE regions ( region_id NUMBER(6) NOT NULL, country_id NUMBER(6) NOT NULL, region_name VARCHAR2(15) NOT NULL, audit_date DATE NOT NULL, audit_user VARCHAR2(30) NOT NULL, global_name VARCHAR2(20) NOT NULL ) TABLESPACE sprocket_data STORAGE (INITIAL 16K NEXT 16K PCTINCREASE 0) / CREATE PUBLIC SYNONYM regions FOR regions / spool off

B.8 de fca ll.sql ----------------------------------------------------------------------------- Filename: defcall.sql -- Purpose: Reports on all queued calls in defcall. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 --- Modification History -- -------------------- 03-Jun-1998 : Chas. : Removed deferred_tran_db field (not in Oracle8) -------------------------------------------------------------------------col callno heading "Call|No" format 9999 col deferred_tran_id heading "Deferred|Tran|ID" format a12 col schemaname heading "Schema|Name" format a8 col packagename heading "Package|Name" format a25 col procname heading "Procedure|Name" format a10 col argcount heading "Arg|Count" format 999 col dblink heading "Destination" format a17 SELECT

c.callno, c.deferred_tran_id, c.packagename, c.procname, c.argcount,

501

Oracle Distributed Systems

FROM WHERE AND /

d.dblink defcall c, defcalldest d c.callno = d.callno c.deferred_tran_id = d.deferred_tran_id

B.9 de fca llde st .sql ---------------------------------------------------------------------------- Filename: defcalldest.sql -- Purpose: Lists all calls in defcalldest. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 --------------------------------------------------------------------------col callno heading "Call No" format 9999999999999 col deferred_tran_db heading "Deferred|Tran|DB" format a19 col deferred_tran_id heading "Deferred|Tran|ID" format a15 col dblink heading "DB Link" format a20 col start_time heading "Start|Time" format a20 SELECT

FROM WHERE /

c.callno, c.deferred_tran_id, c.dblink, t.start_time defcalldest c, deftran t c.deferred_tran_id = t.deferred_tran_id

B.1 0 de fca llin fo.sql --------------------------------------------------------------------------- Filename: defcallinfo.sql -- Purpose: Lists information about deferred calls. -- Author: Chas. Dye ([email protected]) -- Date: 10-Jul-1998 -------------------------------------------------------------------------set serveroutput on size 100000 set verify off undef callno undef argcnt undef tran_db undef tran_id DECLARE vTypes vVals indx

dbms_defer_query.type_ary; dbms_defer_query.val_ary; NUMBER;

BEGIN dbms_defer_query.get_call_args( callno => '&&callno', startarg => 1, argcnt => &&argcnt,

502

Oracle Distributed Systems argsize tran_db tran_id date_fmt types vals

=> => => => => =>

128, '&&tran_db', '&&tran_id', 'DD-Mon-YYYY HH24:MI:SS', vTypes, vVals );

FOR indx IN 1..&&argcnt LOOP dbms_output.put_line('Arg '|| indx || ' Value '|| vVals(indx)); END LOOP; END; /

B.1 1 de fde st .sql ----------------------------------------------------------------------------- Filename: defdest.sql -- Purpose: Lists data from system.def$_destination. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 ---------------------------------------------------------------------------column dblink heading "DB Link" format a15 column last_delivered heading "Last|Delivered" format 9999999999 column last_enq_tid heading "Last|Enq|TID" format a5 column last_seq heading "Last|Seq" format 999 column disabled heading "D|i|s|a|b|l|e|d" format a1 column job heading "Job" format 9999 column last_txn_count heading "Last|Txn|Count" format 9999 column last_error_number heading "Last|Error|Number" format 999999 column last_error_Message heading "Last|Error|Message" format a19 SELECT

FROM /

dblink, last_delivered, last_enq_tid, last_seq, disabled, job, last_txn_count, last_error_number, last_error_message system.def$_destination

B.1 2 de fe r r or .sql --------------------------------------------------------------------------- Filename: deferror.sql -- Purpose: Reports on deferred transaction with errors and generates -call to dbms_defer_sys.execute_error to clear them. -- Author: Chas. Dye ([email protected])

503

Oracle Distributed Systems -- Date: 28-Jun-1996 -------------------------------------------------------------------------column ORIGIN_TRAN_DB heading "Origin|Tran|DB" format a15 column DEFERRED_TRAN_ID heading "Deferred|Tran|ID" format a15 column DESTINATION heading "Destination" format a15 column ERROR_TIME heading "Error Time" format a22 column ERROR_NUMBER heading "Error#" format 999999 column FIX heading "Run This to Clear" format a80 SELECT

FROM / SELECT

FROM /

deferred_tran_id, origin_tran_db, destination, to_char(start_time, 'DD-Mon-YYYY hh24:mi:ss') error_time, error_number deferror

'EXECUTE dbms_defer_sys.execute_error(' || chr(39) || deferred_tran_id || chr(39) || ', '|| chr(39) || origin_tran_db || chr(39) || ', - '|| chr(10) ||chr(39) || destination || chr(39) || ' )' fix deferror

B.1 3 de fe r r or 8 .sql --------------------------------------------------------------------------- Filename: deferror8.sql -- Purpose: Reports on deferred transaction with errors and generates -call to dbms_defer_sys.execute_error to clear them. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 --- Modification History -- --------------------- 13-Aug-1998 : Chas. : Updated for Oracle8; added commands to delete error. -- 09-Oct-1998 : Chas. : Added ORDER BY start_time -------------------------------------------------------------------------column ORIGIN_TRAN_DB heading "Origin|Tran|DB" format a15 column DEFERRED_TRAN_ID heading "Deferred|Tran|ID" format a15 column DESTINATION heading "Destination" format a15 column ERROR_TIME heading "Error Time" format a22 column ERROR_NUMBER heading "Error#" format 999999 column FIX heading "Run This to Clear" format a80 column DITCH heading "Run This to Delete" format a80 SELECT

deferred_tran_id, origin_tran_db, destination, to_char(start_time, 'DD-Mon-YYYY hh24:mi:ss') error_time,

504

Oracle Distributed Systems error_number FROM deferror ORDER BY start_time / SELECT

'EXECUTE dbms_defer_sys.execute_error(' || chr(39) || deferred_tran_id || chr(39) || ', '|| chr(39) || destination || chr(39) || ' )' fix FROM deferror ORDER BY start_time / SELECT

'EXECUTE dbms_defer_sys.delete_error(' || chr(39) || deferred_tran_id || chr(39) || ', '|| chr(39) || destination || chr(39) || ' )' ditch FROM deferror ORDER BY start_time /

B.1 4 de for igin .sql --------------------------------------------------------------------------- Filename: deforigin.sql -- Purpose: Lists data from system.def$_origin. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------column origin_db heading "Origin|DB" format a15 column origin_dblink heading "Origin|DB Link" format a15 column inusr heading "INUSR" format 99999 column cscn heading "CSCN" format 999999999 column eng_tid heading "Enqueue|Txn ID" format a15 column reco_seq_no heading "Reco|Seq|No" format 99999 SELECT

FROM /

origin_db, origin_dblink, inusr, cscn, enq_tid, reco_seq_no system.def$_origin

B.1 5 de fsch e du le .sql --------------------------------------------------------------------------- Filename: defschedule.sql -- Purpose: Returns information about scheduled transactions. -- Author: Chas.Dye ([email protected]) -- Date: 31-Jul-1996 -------------------------------------------------------------------------column dblink heading "DB Link" format a20

505

Oracle Distributed Systems column column column column column column column column SELECT

FROM /

JOB LAST_DATE NEXT_DATE BROKEN INTERVAL FAILURES WHAT last_txn_count

heading heading heading heading heading heading heading heading

"Job" "Last Date" "Next Date" "B|r|o|k|e|n" "Interval" "F|a|i|l" "What" "Last|Txn|Count"

format format format format format format format format

999 a20 a20 a3 a22 999 a75 999

dblink, job, to_char(next_date, 'DD-Mon-YYYY HH24:mi:ss') next_date, to_char(last_date, 'DD-Mon-YYYY HH24:mi:ss') last_date, disabled, last_txn_count defschedule

B.1 6 de ft r a n .sql --------------------------------------------------------------------------- Filename: deftran.sql -- Purpose: Reports on all deferred transactions in deftran. -- Author: Chas. Dye ([email protected]) -- Date: 11-Jun-1998 --- Modification History -- -------------------- 11-Jun-1998 : Chas. : Creation -------------------------------------------------------------------------col deferred_tran_id heading "Deferred|Tran|ID" format a15 SELECT

deferred_tran_id, delivery_order, destination_list, start_time FROM deftran ORDER BY start_time /

B.1 7 de ft r a n de st .sql ----------------------------------------------------------------------------- Filename: deftrandest.sql -- Purpose: Lists all databases in deftrandest. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 ---------------------------------------------------------------------------col callno 9999999999999 col deferred_tran_db col deferred_tran_id

heading "Call No"

format

heading "Deferred|Tran|DB" heading "Deferred|Tran|ID"

format a20 format a20

506

Oracle Distributed Systems col dblink col start_time SELECT

FROM WHERE AND /

heading "DB Link" heading "Start Time"

format a20 format a20

d.deferred_tran_id, d.delivery_order, d.dblink, t.start_time deftrandest d, deftran t d.deferred_tran_id = t.deferred_tran_id d.delivery_order = t.delivery_order

B.1 8 dispr a t e .sql --------------------------------------------------------------------------- Filename: disprate.sql -- Purpose: Queries v$dispatcher_rate. -- Author: Chas. Dye ([email protected]) -- Date: 24-Nov-1998 -------------------------------------------------------------------------col name format a8 col CUR_MSG_RATE col MAX_MSG_RATE col AVG_MSG_RATE

format 999999 format 999999 format 999999

SELECT name, CUR_MSG_RATE, MAX_MSG_RATE, AVG_MSG_RATE FROM v$dispatcher_rate / col col col col col col

CUR_SVR_BYTE_PER_BUF CUR_CLT_BYTE_PER_BUF MAX_SVR_BYTE_PER_BUF MAX_CLT_BYTE_PER_BUF AVG_SVR_BYTE_PER_BUF AVG_CLT_BYTE_PER_BUF

SELECT

FROM /

format format format format format format

999999 999999 999999 999999 999999 999999

heading heading heading heading heading heading

"CUR|SVR|BYTE|PER|BUF" "CUR|CLT|BYTE|PER|BUF" "MAX|SVR|BYTE|PER|BUF" "MAX|CLT|BYTE|PER|BUF" "AVG|SVR|BYTE|PER|BUF" "AVG|CLT|BYTE|PER|BUF"

name, CUR_SVR_BYTE_PER_BUF, CUR_CLT_BYTE_PER_BUF, MAX_SVR_BYTE_PER_BUF, MAX_CLT_BYTE_PER_BUF, AVG_SVR_BYTE_PER_BUF, MAX_CLT_BYTE_PER_BUF v$dispatcher_rate

B.1 9 e r r or in fo.sql --------------------------------------------------------------------------

507

Oracle Distributed Systems -- Filename: errorinfo.sql -- Purpose: Reports on all errors. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 --- Modification History -- -------------------- 03-Jun-1998 : Chas. : Removed deferred_tran_db field (not in Oracle8) -- 09-Oct-1998 : Chas. : Added ORDER BY e.start_time -------------------------------------------------------------------------col callno heading "Call|No" format 9999 col deferred_tran_id heading "Deferred|Tran|ID" format a12 col schemaname heading "Schema|Name" format a8 col packagename heading "Package|Name" format a25 col procname heading "Procedure|Name" format a10 col argcount heading "Arg|Count" format 999 col origin_tran_db heading "Origin" format a17 SELECT

c.callno, c.deferred_tran_id, c.packagename, c.procname, c.argcount, e.origin_tran_db FROM defcall c, deferror e WHERE c.deferred_tran_id = e.deferred_tran_id AND c.callno = e.callno ORDER BY e.start_time /

B.2 0 fix de fe r .sql --------------------------------------------------------------------------- Filename: fixdefer.sql -- Purpose: Reports on deferred transaction with errors and generates -call to dbms_defer_sys.execute_error to clear them. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column DEFERRED_TRAN_DB heading "Deferred|Tran|DB" format a15 column DEFERRED_TRAN_ID heading "Deffered|Tran|ID" format a15 column DESTINATION heading "Destination" format a15 column ERROR_TIME heading "Error Time" format a22 column ERROR_NUMBER heading "Error#" format 999999 column FIX heading "Run This to Clear" format a80

SELECT

deferred_tran_id, deferred_tran_db, destination, to_char(error_time, 'DD-Mon-YYYY hh24:mi:ss') error_time, error_number

508

Oracle Distributed Systems FROM /

deferror

SELECT

'EXECUTE dbms_defer_sys.execute_error(' || chr(39) || deferred_tran_id || chr(39) || ', '|| chr(39) || deferred_tran_db || chr(39) || ', - '|| chr(10) ||chr(39) || destination || chr(39) || ' )' fix deferror

FROM /

B.2 1 ge n de le r r t r a n .sql --------------------------------------------------------------------------- Filename: gendelerrtran.sql -- Purpose: Generates calls to dbms_defer_sys to delete transactions -that have resulted in errors for a particular table. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------SELECT 'EXECUTE dbms_defer_sys.delete_error(' || chr(39) || deferred_tran_id || chr(39) || ', '|| chr(39) || destination || chr(39) || ' );', 'COMMIT;' FROM deferror e WHERE EXISTS ( SELECT deferred_tran_id FROM defcall c WHERE c.deferred_tran_id = e.deferred_tran_id AND c.packagename like upper('%&target_table%')) /

B.2 2 ge n de lt r a n .sql --------------------------------------------------------------------------- Filename: gendeltran.sql -- Purpose: Generates calls to dbms_defer_sys to delete transactions -for a particular table. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------select 'exec dbms_defer_sys.delete_tran('||chr(39)||deferred_tran_id||chr(39)||','|| chr(39)||'PLV2.EXCITE.COM'||chr(39)||');'||chr(10)||'commit;' from deftran t where exists (select DEFERRED_TRAN_ID from defcall c where c.DEFERRED_TRAN_ID = t.DEFERRED_TRAN_ID and c.packagename like upper('&target_table$%')) /

509

Oracle Distributed Systems

B.2 3 ge n ge n su p.sql --------------------------------------------------------------------------- Filename: gengensup.sql -- Purpose: Generates calls to generate_replication_support. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------undef schema_name SELECT 'EXECUTE dbms_repcat.generate_replication_support( '||chr(10)|| 'sname=>'||chr(39)||upper('&&schema_name')||chr(39)||', '||chr(10)|| 'oname=>'||chr(39)||oname||chr(39)||', -'||chr(10)|| 'type=>'||chr(39)||type||chr(39)||', -'||chr(10)|| 'distributed=>TRUE);' FROM dba_repobject WHERE oname NOT LIKE '%$R%' AND sname = upper('&&schema_name') ORDER BY sname, type, oname / undef schema_name

B.2 4 gr ou pe dcols.sql --------------------------------------------------------------------------- Filename: groupedcols.sql -- Purpose: Lists all grouped columns. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------column sname heading "Schema|Name" format a8 column oname heading "Table|Name" format a25 column group_name heading "Column|Group" format a25 column column_name heading "Column|Name" format a19 clear breaks break on sname on oname skip 1 SELECT

sname, substr(oname, 1, 25) oname, substr(group_name, 1, 25) group_name, substr(column_name, 1, 19) column_name FROM dba_repgrouped_column ORDER BY sname, oname, group_name, column_name / clear breaks

510

Oracle Distributed Systems

B.2 5 in va lids.sql --------------------------------------------------------------------------- Filename: invalids.sql -- Purpose: Lists all invalid objects and provides SQL to (attempt to) -repair them. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column object_name format a25 heading "Object Name" column status format a7 heading "Status" column owner format a12 heading "Owner" column object_type format a12 heading "Object Type" column created format a20 heading "Date Created" column fix format a70 heading "Run these statements to repair" SELECT FROM WHERE /

object_name, status, object_type, owner, created dba_objects status != 'VALID'

SELECT 'ALTER ' || DECODE( object_type, 'PACKAGE BODY', 'PACKAGE', object_type) || ' ' || lower(owner)||'.'|| lower(object_name) || DECODE( object_type, 'PACKAGE BODY', ' COMPILE BODY;', ' COMPILE;') fix FROM dba_objects WHERE object_type IN ( 'FUNCTION', 'PACKAGE', 'PACKAGE BODY', 'PROCEDURE', 'TYPE', 'TRIGGER', 'VIEW' ) AND status = 'INVALID' /

B.2 6 j obs.sql rem ---------------------------------------------------------------------rem Filename: jobs.sql rem Purpose: Returns information about jobs in the job queue. rem Author: [email protected] rem Date: 31-Jul-1996 rem ---------------------------------------------------------------------column JOB heading "Job" format 9999 column LAST_DATE heading "Last Date" format a20 column NEXT_DATE heading "Next Date" format a20

511

Oracle Distributed Systems column column column column SELECT

FROM / SELECT FROM /

BROKEN INTERVAL FAILURES WHAT

heading heading heading heading

"B|r|o|k|e|n" "Interval" "F|a|i|l" "What"

format format format format

a3 a24 99 a74

job, to_char(last_date, 'DD-Mon-YYYY HH24:mi:ss') last_date, to_char(next_date, 'DD-Mon-YYYY HH24:mi:ss') next_date, decode(broken, 'Y', 'Yes', 'No') broken, interval, failures dba_jobs

job, what dba_jobs

B.2 7 k e ycols.sql --------------------------------------------------------------------------- Filename: keycols.sql -- Purpose: Lists columns identified by DBMS_REPCAT.SET_COLUMNS. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------col sname heading "Schema" format a12 col oname heading "Table Name" format a30 col col heading "Column Name" format a30 clear breaks break on sname on oname skip 1 SELECT sname, oname, col FROM dba_repkey_columns ORDER BY sname, oname / clear breaks

B.2 8 la st sn a p.sql --------------------------------------------------------------------------- Filename: lastsnap.sql -- Purpose: Lists registered snapshots (run from master site). -- Author: Chas. Dye ([email protected]) -- Date: 29-Aug-1998 -------------------------------------------------------------------------column owner heading "Owner" format a8

512

Oracle Distributed Systems column a22 column a15 column a11 column a10 column a20 SELECT

FROM WHERE AND /

name

heading "Name"

format

snapshot_site

heading "Snapshot|Site"

format

refresh_method

heading "Refresh|Method"

format

version

heading "Version"

format

current_snapshots

heading "Last|Refresh"

format

r.owner, r.name, r.snapshot_site, r.refresh_method, nvl( to_char(l.current_snapshots, 'DD-Mon-YYYY HH24:MI:SS'), ' -- Unknown --') current_snapshots dba_registered_snapshots r, dba_snapshot_logs l l.log_owner(+) = r.owner l.master(+) = r.name

B.2 9 la t e n t .sql --------------------------------------------------------------------------- Filename: latent.sql -- Purpose: Lists outstanding transactions by destination. -- Author: Chas. Dye ([email protected]) -- Date: 09-Jul-1996 -------------------------------------------------------------------------col dblink heading "Destination" format a16 col earliest heading "Least Recently|Queued Transaction" format a20 col latest heading "Most Recently|Queued Transaction" format a20 col out heading "Total|Txns|Queued" format 999,999 col timenow heading "Current|Time" format a8 col latency heading "Maximum|Latency|dd:hh:mi:ss" format a12 clear breaks clear computes set head off set feedback off select 'Propagation Latency Instance: '||name||'. to_char(sysdate, 'DD-Mon-YY HH24:mi:ss') from v$database / set head on set feedback on

Time: ' ||

compute sum of out on report break on report skip 1 SELECT

d.dblink,

513

Oracle Distributed Systems min(t.start_time) earliest, max(t.start_time) latest, count(*) out, ltrim(to_char(trunc( sysdate - ( min(start_time)) ), '09')) || ':' || ltrim(to_char(trunc(24*((sysdate-min(start_time)) trunc(sysdate-min(start_time)))), '09'))||':' || ltrim(to_char(mod(trunc(1440*((sysdate-min(start_time)) trunc(sysdate-min(start_time)))), 60), '09')) ||':' || ltrim(to_char(mod(trunc(86400*((sysdate-min(start_time)) trunc(sysdate-min(start_time)))), 60), '09')) latency FROM deftrandest d, deftran t WHERE d.deferred_tran_id = t.deferred_tran_id AND d.delivery_order = t.delivery_order GROUP BY d.dblink / clear breaks clear computes

B.3 0 lin k s.sql --------------------------------------------------------------------------- Filename: links.sql -- Purpose: Reports all database links in the database. -- Author Chas. Dye ([email protected]) -- Date: 28-May-1997 -------------------------------------------------------------------------column owner heading "Owner" format a10 column db_link heading "DB Link" format a20 column username heading "Username" format a12 column host heading "Host" format a12 column created heading "Created" format a20 clear breaks break on db_link skip 1 SELECT

db_link, owner, nvl(username, '--------') username, host, TO_CHAR(created, 'DD-Mon-YYYY HH24:MI:SS') created FROM dba_db_links ORDER BY db_link, host, owner / clear breaks

B.3 1 m a st e r sna pinfo.sql --------------------------------------------------------------------------- Filename: mastersnapinfo.sql -- Purpose: Lists info about all registered snapshots. -Requires Oracle8.

514

Oracle Distributed Systems -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1997 -------------------------------------------------------------------------column owner format a10 column name format a20 column snapshot_site format a15 column current_snapshot format a22 SELECT

FROM WHERE /

r.owner, r.name, r.snapshot_site, l.current_snapshots dba_registered_snapshots r, dba_snapshot_logs l r.snapshot_id = l.snapshot_id(+)

B.3 2 m logs.sql --------------------------------------------------------------------------- Filename: mlogs.sql -- Purpose: Generates SELECT statements to find count of entries in all -snapshot logs. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------SELECT 'SELECT count(*) FROM '||lower(owner)||'.'||lower(table_name)||';' FROM dba_tables WHERE table_name like 'MLOG$_%' AND owner not like 'SYS%' ORDER BY owner, table_name /

B.3 3 n e e dsge n .sql --------------------------------------------------------------------------- Filename: needsgen.sql -- Purpose: Lists all replicated objects. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column SNAME heading "Schema" format a8 column ONAME heading "Object" format a30 column TYPE heading "Type" format a15 column STATUS heading "Status" format a9 column ID heading "ID" format 9999 column GNAME heading "Group" format a8

515

Oracle Distributed Systems SELECT id, gname, sname, oname, type, status FROM dba_repobject WHERE generation_status = 'NEEDSGEN' ORDER BY gname, sname, type, oname /

B.3 4 n on r e pobj e ct s.sql --------------------------------------------------------------------------- Filename: nonrepobjects.sql -- Purpose: Lists objects in a schema that are NOT replicated. -Oracle8 only. -- Author: Chas. Dye ([email protected]) -- Date: 29-Aug-1998 -------------------------------------------------------------------------undef table_owner set verify off column a10 column a30 column a30 column a20

owner

heading "Owner"

format

name

heading "Name"

format

table_name

heading "Table Name"

format

tablespace_name

heading "Tablespace"

format

SELECT

t.owner, t.table_name, t.tablespace_name FROM dba_tables t WHERE owner = upper('&&table_owner') AND table_name NOT LIKE 'MLOG$_%' AND table_name NOT LIKE 'SNAP$_%' AND table_name NOT LIKE 'ULOG$_%' AND table_name NOT IN ( SELECT oname FROM dba_repobject WHERE sname = upper('&&table_owner')) AND table_name NOT IN ( SELECT name FROM dba_registered_snapshots ) ORDER BY table_name / undef table_owner

B.3 5 pk _ r e gion s.sql --------------------------------------------------------------------------- Filename: pk_regions.sql -- Purpose: Creates the constraints and indexes on table REGIONS. -- Author: Chas. Dye ([email protected]) -- Date: 12-Jan-1998

516

Oracle Distributed Systems -------------------------------------------------------------------------set echo on set termout on spool pk_regions.log ALTER TABLE regions ADD ( CONSTRAINT pk_regions PRIMARY KEY (region_id) USING INDEX TABLESPACE sprocket_indx STORAGE (INITIAL 16K NEXT 16K PCTINCREASE 0) ) / ALTER TABLE regions ADD ( CONSTRAINT fk_regions_country_id FOREIGN KEY (country_id) REFERENCES countries (country_id) ) / CREATE INDEX i_region_country_id ON regions(country_id) TABLESPACE sprocket_indx STORAGE (INITIAL 16K NEXT 16K PCTINCREASE 0) / spool off

B.3 6 pr ior it ygr ou ps.sql --------------------------------------------------------------------------- Filename: prioritygroups.sql -- Purpose: Lists all defined priority groups. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------column sname heading "Rep|Group" format a15 column priority_group heading "Priority|Group" format a15 column data_type heading "Data|Type" format a9 column priority_comment heading "Comment" format a35 SELECT

sname, priority_group, data_type, substr(priority_comment, 1, 35) priority_comment FROM dba_reppriority_group ORDER BY sname, priority_group /

B.3 7 pr ior it ysit e s.sql --------------------------------------------------------------------------- Filename: prioritysites.sql -- Purpose: Lists all defined priority sites. -- Author: Chas. Dye ([email protected])

517

Oracle Distributed Systems -- Date: 27-May-1998 -------------------------------------------------------------------------column sname heading "Rep|Group" format a15 column priority_group heading "Site|Priority|Name" format a15 column priority heading "Priority" format 9999 column varchar2_value heading "Site|Name" format a20 column priority_comment heading "Comment" format a35 SELECT

sname, priority_group, varchar2_value, priority FROM dba_reppriority ORDER BY sname, priority_group /

B.3 8 pr opm ode .sql --------------------------------------------------------------------------- Filename: propmode.sql -- Purpose: Lists all replication sites and propagation modes. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column SNAME heading "Group" format a8 column DBLINK heading "DB-Link" format a20 column HOW heading "Prop|Mode" format 999,999,999 clear breaks break on dblink skip 1 SELECT FROM WHERE AND /

distinct(l1.dblink) dblink, l2.sname, l2.how dba_repprop l1, dba_repprop l2 l1.dblink = l2.dblink l2.how != 'NONE'

clear breaks

B.3 9 r e fgr ou ps.sql --------------------------------------------------------------------------- Filename: refgroups.sql -- Purpose: Lists all refresh groups in the database. -- Author: Chas. Dye ([email protected]) -- Date: 17-Jan-1997 -------------------------------------------------------------------------column rname heading "Refresh|Group" format a15 column owner heading "Snapshot|Owner" format a10 column name heading "Table Name" format a25 column next_date heading "Next Refresh" format a20

518

Oracle Distributed Systems column parallelism

heading "P|a|r|a|l|l|e|l"

format 99999

clear breaks break on rname skip 1 SELECT

rname, owner, name, next_date, parallelism FROM dba_refresh_children ORDER BY rname, owner, name /

B.4 0 r e gsn a ps.sql --------------------------------------------------------------------------- Filename: regsnaps.sql -- Purpose: Lists registered snapshots (run from master site). -- Author: Chas. Dye ([email protected]) -- Date: 24-Jun-1998 -------------------------------------------------------------------------column owner heading "Owner" format a8 column name heading "Name" format a20 column snapshot_site heading "Snapshot|Site" format a15 column can_use_log heading "Can|Use|Log" format a3 column updatable heading "Upd" format a3 column refresh_method heading "Refresh|Method" format a11 column version heading "Version" format a10 SELECT

FROM /

owner, name, snapshot_site, can_use_log, updatable, refresh_method, substr(version, 1, 8) version dba_registered_snapshots

B.4 1 r e pca t e r r .sql --------------------------------------------------------------------------- Filename: repcaterr.sql -- Purpose: Lists entries in dba_repcatlog with error status. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column ID heading "Id" format 9999 column SOURCE heading "Source" format a20 column SNAME heading "Schema" format a8 column REQUEST heading "Request" format a22 column ONAME heading "Object" format a20

519

Oracle Distributed Systems column ERRNUM column MESSAGE

heading "Error" heading "Message"

format 99999 format a74

SELECT id, status, sname, request, oname, errnum FROM dba_repcatlog WHERE status = 'ERROR' ORDER BY id / SELECT id, message FROM dba_repcatlog WHERE status = 'ERROR' ORDER BY id / set head off SELECT 'Run these commands to purge...' FROM dual / set head on SELECT

FROM WHERE /

'EXECUTE dbms_repcat.purge_master_log('|| id ||', ' ||chr(39)||rtrim(source)||chr(39)||', ' ||chr(39)||gname||chr(39)||');' command dba_repcatlog status = 'ERROR'

B.4 2 r e pca t log.sql --------------------------------------------------------------------------- Filename: repcatlog.sql -- Purpose: Lists all tasks pending in dba_repcatlog queue. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column SOURCE heading "Source" format a6 column MASTER heading "Master" format a6 column SNAME heading "Group" format a10 column STATUS heading "Status" format a14 column REQUEST heading "Request" format a28 column TIMESTAMP heading "Time" format a8

SELECT

substr(source, 1, instr(source, '.', 1) -1 ) source, substr(master, 1, instr(master, '.', 1) -1 ) master, sname, status, request, to_char(timestamp, 'HH24:MI:SS') timestamp FROM dba_repcatlog ORDER BY master /

520

Oracle Distributed Systems

B.4 3 r e pcon flict .sql --------------------------------------------------------------------------- Filename: repconflict.sql -- Purpose: Lists all defined conflict resolution methods. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------column sname heading "Schema|Name" format a10 column oname heading "Table|Name" format a25 column conflict_type heading "Conf|Type" format a10 column reference_name heading "Reference|Name" format a30 SELECT sname, oname, conflict_type, reference_name FROM dba_repconflict ORDER BY sname, oname /

B.4 4 r e pgr ou p.sql --------------------------------------------------------------------------- Filename: repgroup.sql -- Purpose: Lists status of all replication groups. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column MASTER heading "Mast|Site" format a4 column MASTERDEF heading "Mast|Def|Site" format a4 column STATUS heading "Status" format a9 column GNAME heading "Group" format a12 column SCHEMA_COMMENT heading "Comment" format a45 SELECT

FROM WHERE AND /

g.gname, decode(g.master, 'N', 'No', 'Y', 'Yes') master, decode(s.masterdef, 'Y', 'Yes', 'N', 'No') masterdef, g.status, g.schema_comment dba_repgroup g, dba_repsites s g.gname = s.gname s.my_dblink = 'Y'

B.4 5 r e pobj e ct s.sql --------------------------------------------------------------------------- Filename: repobjects.sql -- Purpose: Lists all replicated objects. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column SNAME heading "Schema" format a8

521

Oracle Distributed Systems column column column column column

ONAME TYPE STATUS ID GNAME

heading heading heading heading heading

"Object" "Type" "Status" "ID" "Group"

format format format format format

a30 a15 a7 9999 a10

SELECT id, gname, sname, oname, type, status FROM dba_repobject ORDER BY gname, sname, type, oname /

B.4 6 r e pr e s.sql --------------------------------------------------------------------------- Filename: repres.sql -- Purpose: Lists all conflict resolution techniques. -- Author: Chas. Dye ([email protected]) -- Date: 27-May-1998 -------------------------------------------------------------------------column sname heading "Schema|Name" format a8 column oname heading "Table|Name" format a25 column conflict_type heading "Conflict|Type" format a10 column method_name heading "Method" format a18 column sequence_no heading "Seq" format 99 clear breaks break on sname on oname skip 1 SELECT

sname, substr(oname, 1, 25) conflict_type, method_name, sequence_no FROM dba_represolution ORDER BY sname, oname /

oname,

clear breaks

B.4 7 r e psit e s.sql --------------------------------------------------------------------------- Filename: repsites.sql -- Purpose: Lists all replication sites. -- Author: Chas. Dye ([email protected]) -- Date: 28-Jun-1996 -------------------------------------------------------------------------column GNAME heading "Group" format a15 column DBLINK heading "DB-Link" format a20 column MASTERDEF heading "Master|Def|Site?" format a6 column MASTER heading "Master|Site?" format a6 column PROP_UPDATES heading "Update|Requests" format 999,999,999

522

Oracle Distributed Systems column MY_DBLINK

heading "Is|This|Database?"

format a9

SELECT

gname, dblink, decode(masterdef, 'Y', 'Yes', 'No') masterdef, decode(master, 'Y', 'Yes', 'No') master, prop_updates, decode(my_dblink, 'Y', 'Yes', 'No') my_dblink FROM dba_repsites ORDER BY gname ASC, masterdef DESC /

B.4 8 r e scon fs.sql --------------------------------------------------------------------------- Filename: resconfs.sql -- Purpose: Reports on all resolved conflicts. -- Author: Chas. Dye ([email protected]) -- Date: 11-Jun-1998 --- Modification History -- -------------------- 11-Jun-1998 : Chas. : Creation -------------------------------------------------------------------------col primary_key_value form a10 heading "Primary|Key" col oname form a25 heading "Object Name" col conflict_type form a8 heading "Conflict|Type" col method_name form a18 heading "Resolution|Method" col resolved_date form a15 heading "Resolution|Date" SELECT

FROM /

oname, primary_key_value, conflict_type, method_name, to_char(resolved_date, 'DD-Mon HH24:MI:SS') resolved_date dba_represolution_statistics

B.4 9 sn a ps.sql --------------------------------------------------------------------------- Filename: snaps.sql -- Purpose: Lists all snapshots in the database. -- Author Chas. Dye ([email protected]) -- Date: 17-Jan-1997 -------------------------------------------------------------------------column owner format a9 column name format a15 column table_name format a27 column link format a5 heading "Link" column last_refresh format a20 SELECT

d.owner,

523

Oracle Distributed Systems d.name, d.table_name, substr(d.master_link, 1, 5) link, s.snaptime last_refresh /*-to_char(last_refresh, 'DD-Mon-YYYY hh24:mi:ss') last_refresh --*/ FROM

dba_snapshots d, sys.snap_reftime$ s WHERE d.owner = s.sowner AND d.name = s.vname ORDER BY d.owner, d.name /

B.5 0 sn a ps7 .sql --------------------------------------------------------------------------- Filename: snaps7.sql -- Purpose: Lists all snapshots in the database. -- Author Chas. Dye ([email protected]) -- Date: 17-Jan-1997 -------------------------------------------------------------------------column owner format a9 column name format a15 column table_name format a27 column link format a5 heading "Link" column last_refresh format a20 SELECT

owner, name, table_name, substr(master_link, 1, 5) link, to_char(last_refresh, 'DD-Mon-YYYY hh24:mi:ss') last_refresh FROM dba_snapshots ORDER BY owner, name /

B.5 1 t r g_ r e gions.sql --------------------------------------------------------------------------- Filename: trg_regions.sql -- Purpose: Creates trigger(s) on table REGIONS. -- Author: Chas. Dye ([email protected]) -- Date: 12-Jan-1998 -------------------------------------------------------------------------set echo on set termout on spool trg_regions.log CREATE OR REPLACE TRIGGER t_br_iu_regions BEFORE INSERT OR UPDATE ON regions FOR EACH ROW

524

Oracle Distributed Systems

BEGIN IF (dbms_reputil.from_remote != TRUE) THEN :new.audit_date := SYSDATE; :new.audit_user := USER; :new.global_name := DBMS_REPUTIL.GLOBAL_NAME; END IF; END; / spool off

B.5 2 Use r Adm in The UserAdm in package allows you t o creat e and drop users and grant and revoke privileges. Using procedural replicat ion, t his package provides a m eans t o m aint ain user account s in m ult iple dat abases wit hout having t o act ually log int o each dat abase t o perform t he adm inist rat ive t asks. The package is quit e lengt hy and is already included in Chapt er 14 ( see Sect ion 14.5.1, Sect ion 14.5.2, and Sect ion 14.5.3) , so I have not duplicat ed t he code here. However, you will find it at t he O'Reilly web sit e.

Coloph on Our look is t he result of reader com m ents, our own experim ent at ion, and feedback from dist ribut ion channels. Dist inct ive covers com plem ent our dist inct ive approach t o t echnical t opics, breat hing personalit y and life int o pot ent ially dry subj ect s. But t erflies are feat ured on t he cover of Oracle Dist ribut ed Syst em s. These are t hree of t he t housands of species of but t erfly. But t erflies, along wit h m ot hs and skippers, m ake up t he order Lepidopt era. The word " Lepidopt era" is derived from t he Greek words lepic, m eaning " scale," and pt eron, m eaning " wing." And, in fact , but t erfly and m ot h wings are covered ent irely in t iny, overlapping scales. The colorat ion of t hese fragile scales is what creat es t he spect acular, shim m ering colors of t he but t erfly. The wing m em brane it self is t ransparent and wit hout color. But t erfly scales and hairs are covered in a t hin layer of wax, m aking t hese insect s wat er- repellent . Most but t erflies fly by flut t ering t heir wings at a relat ively slow rat e, som et im es as slowly as 10 beat s per second, approxim at ely four m iles per hour. Unlike m any ot her insect s, who beat t heir wings so fast t hat t hey becom e j ust a blur in flight , t he but t erfly's wings are clearly visible during it s flut t ering flight . But t erflies are as well known for t heir four- st age m et am orphosis as t hey are for t heir colorful wings and graceful flut t ering. An adult fem ale but t erfly lays a large num ber of eggs, usually on or near food plant s. The larva, bet t er known as t he cat erpillar, develops wit hin t he egg and eat s it s way out . I t t hen cont inues t o eat alm ost const ant ly for a period ranging from one m ont h t o t wo years, depending on t he but t erfly species, periodically m olt ing it s skin during t he process. The cat erpillar t hen produces a pupa, or chrysalis, a m um m ylike st ruct ure. When t he adult but t erfly is fully form ed, it breaks out of t he pupa, it s body and wings harden, and it t akes off in search of food.

525

Oracle Distributed Systems Melanie Wang was t he product ion edit or, and Norm a Em ory was t he copy edit or for Oracle Dist ribut ed Syst em s. Sheryl Avruch was t he product ion m anager, and Jane Ellin and Ellie Maden provided qualit y cont rol reviews. Bet t y Hugh and Sebast ian Banker provided product ion support . Chris Reilley creat ed t he illust rat ions using Adobe Phot oshop 5 and Macrom edia FreeHand 8. Mike Sierra provided Fram eMaker t echnical support . Rut h Raut enberg wrot e t he index. Edie Freedm an designed t he cover of t his book, using a 19t h- cent ury engraving from t he Dover Pict orial Archive. The cover layout was produced by Kat hleen Wilson wit h QuarkXPress 3.32 using t he I TC Garam ond font . Kat hleen Wilson designed t he disket t e label. The inside layout was designed by Nancy Priest and Alicia Cech and im plem ent ed in Fram eMaker 5.5 by Mike Sierra. The t ext and heading font s are I TC Garam ond Light and Garam ond Book. This colophon was writ t en by Clairem arie Fisher O'Leary.

526