10/3/22, 7:20 PM
`
`Oracle Distributed Systems
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/cover.html
`
`1/2
`
`Support
`
`Sign Out
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 001
`
`

`

`10/3/22, 7:20 PM
`
`Oracle Distributed Systems | Oracle Distributed Systems
`
`Oracle Distributed Systems
`
`Charles Dye
`
`Editor
`
`Debby Russell
`
`Copyright © 1999 O'Reilly Media, Inc.
`
`Support
`
`Sign Out
`
`©2022 O'REILLY MEDIA, INC. 
`
`TERMS OF SERVICE
`
`PRIVACY POLICY
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/index.html
`
`1/1
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 002
`
`

`

`10/3/22, 7:21 PM
`
`1. Introduction to Distributed Systems | Oracle Distributed Systems
`
`Chapter 1. Introduction to Distributed
`Systems
`
`Any organization that uses the Oracle relational database management
`system (RDBMS) probably has multiple databases. There are a variety of
`reasons why you might use more than a single database in a distributed
`database system:
`
`Different databases may be associated with particular business func-
`tions, such as manufacturing or human resources.
`Databases may be aligned with geographic boundaries, such as a behe-
`moth database at a headquarters site and smaller databases at region-
`al offices.
`Two different databases may be required to access the same data in
`different ways, such as an order entry database whose transactions
`are aggregated and analyzed in a data warehouse.
`A busy Internet commerce site may create multiple copies of the same
`database to attain horizontal scalability.
`A copy of a production database may be created to serve as a develop-
`ment test bed.
`
`Sometimes the relationship between multiple databases is part of a well-
`planned architecture, in which distributed databases are designed and
`implemented as such from the beginning. In other cases, though, the rela-
`tionship is unforeseen; it is quite common for distributed databases to
`evolve as businesses expand, requirements grow, and applications
`spawn. But common to all cases is the need to copy or reference data in
`one or more remote databases.
`
`A distributed database system will meet one or more of the following
`objectives:
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01.html
`
`1/6
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 003
`
`

`

`10/3/22, 7:21 PM
`
`1. Introduction to Distributed Systems | Oracle Distributed Systems
`
`Availability
`Data must be available at the local site even when a remote site is
`unreachable.
`
`Survivability
`The failure of any single database instance must not impact the ongo-
`ing business.
`
`Data collection
`Regional data such as sales receipts is consolidated and aggregated at
`a single site.
`
`Data extraction
`A data warehouse extracts transaction records from an online transac-
`tion processing (OLTP) system.
`
`Decentralized data
`Data may be updated in several databases.
`
`Maintenance
`There must be support for activities such as load testing with data
`from production in a benchmarking database.
`
`Oracle Corporation introduced interdatabase connectivity with SQL*Net
`in Oracle Version 5 and simplified its usage considerably with the data-
`base links feature in Oracle Version 6, opening up a world of distributed
`possibilities. Oracle now supplies a variety of techniques that you can use
`to establish interdatabase connectivity and data sharing. Each technique
`has its advantages and disadvantages, but in many cases the best solution
`is not immediately obvious.
`
`Before delving into Oracle’s offerings in the distributed database systems
`area, I’ll clarify some terminology and concepts.
`
`Terminology and Concepts
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01.html
`
`2/6
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 004
`
`

`

`1. Introduction to Distributed Systems | Oracle Distributed Systems
`10/3/22, 7:21 PM
`I have found thatthere is a great deal of confusion surrounding the vari-
`ous products and terminology from Oracle. I think it’s worthwhile to clar-
`ify some of these terms up front so you’ll get the most benefit from this
`book.
`
`Database/ database instance
`These terms are often used interchangeably, but they are not the same
`thing. In Oracle parlance, a database is the set of physical files contain-
`ing data. These files comprise tablespaces, redo logs, and control files.
`A database instance (or simply instance) is the set of processes and memo-
`ry structures that manipulate a database.
`
`A database may be accessed by one or more database instances, and a
`database instance may access exactly one database.
`
`Oracle parallel server
`Oracle parallel server(OPS) is a technology that allows two or more
`database instances, generally on different machines, to open and ma-
`nipulate one database, as shown in Figure 1.1. In other words, the
`physical data files (and therefore data) in a database can be seen, in-
`serted, updated, and deleted by users logging on to two or more differ-
`ent instances; the instances run on different machines but access the
`same physical database.
`
`Figure 1-1. Parallel server architecture
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01.html
`
`3/6
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 005
`
`

`

`10/3/22, 7:21 PM
`
`1. Introduction to Distributed Systems | Oracle Distributed Systems
`Oracle parallel server requires an operating system that supports clus-
`tering and a distributed lock manager because the multiple database
`instances must share information about the data that is updated, the
`lock resources, and so on. For example, if a user on instance A updates
`a row, and a user on instance B performs a query that would return
`that row, instance B must instruct instance A to write the updated data
`to the physical database so that the query will deliver the updated
`information.
`
`Oracle parallel server is intended to provide failover capabilities —capa-
`bilities that allow a second machine to take over the processing being
`performed by the first in the event of machine failure (e.g., CPU or
`motherboard failure). It does not provide any protection from disk
`failure. Occasionally, parallel server technology is used to achieve hor-
`izontal scalability, a concept I’ll discuss later in this chapter.
`
`Standby database
`Oracle introduced the standby database in Version 7.2, although some
`sites had created their own homegrown varieties earlier. A standby
`database is one that shadows a normal database and is always in re-
`covery mode. Whenever a redo log is archived in the primary data-
`base, the archived redo log is applied to the standby database, as
`shown in Figure 1.2. Generally, the standby database resides on a sepa-
`rate machine and uses separate storage.
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01.html
`
`4/6
`
`Figure 1-2. Standby database
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 006
`
`

`

`10/3/22, 7:21 PM
`
`1. Introduction to Distributed Systems | Oracle Distributed Systems
`If the primary database fails, the DBA can open the standby database
`and point users to it instead of to the primary database. Once this oc-
`curs, what had been the standby database becomes the primary data-
`base, and it cannot be put back into standby mode again.
`
`Advanced replication
`A dvanced replication, also known as symmetric replication or multi-master
`replication , refers to maintaining a table or tables in multiple databases
`such that DML (Data Manipulation Language) can be issued in any of
`the databases and applied to the others automatically. The DML may
`be propagated synchronously (i.e., DML is committed locally and remote-
`ly as a single transaction) or asynchronously (i.e., DML committed locally
`is placed in a queue from which it is applied at the remote site later).
`Advanced replication can be used to deliver high availability, in the
`sense that the unavailability of any one site does not affect the others,
`or it may be used as part of a survivability policy in which every database
`has a replicated copy that can be used in the event of failure. Unlike
`parallel server, advanced replication involves numerous databases
`and numerous database instances.
`
`Parallel query
`The parallel query option (PQO) is a technology that can divide compli-
`cated or long-running queries into several independent queries and
`allocate separate processes to execute the smaller queries. A coordina-
`tor process collects the results of the smaller queries and constructs
`the final result set. Parallel queries are effective only on machines that
`have multiple CPUs.
`
`Parallel DML
`Oracle introduced the parallel DML feature in Oracle8. Parallel DML is
`similar to parallel query, except that the independent processes per-
`form DML. For example, an update of several hundred thousand rows
`can be doled out to several processes that execute the update on sepa-
`rate ranges of the table.
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01.html
`
`5/6
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 007
`
`

`

`10/3/22, 7:21 PM
`
`1. Introduction to Distributed Systems | Oracle Distributed Systems
`
`Support
`
`Sign Out
`
`©2022 O'REILLY MEDIA, INC. 
`
`TERMS OF SERVICE
`
`PRIVACY POLICY
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01.html
`
`6/6
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 008
`
`

`

`10/3/22, 7:21 PM
`
`What Is a Distributed Database System? | Oracle Distributed Systems
`
`What Is a Distributed Database
`System?
`
`A distributed database system, illustrated in Figure 1.3, is an environment
`in which data in two or more database instances is accessible as though
`this data were in a single instance. This access may be read-only, or it may
`permit updates to one or many instances. The referenced data may be
`real time, or it may be seconds, hours, or days old. Generally, the different
`database instances are housed on different server nodes, and communi-
`cation between them is via SQL*Net (for Oracle7) or Net8 (for Oracle8).
`Chapter 2, describes this communication.
`
`In addition to database servers, a distributed database system usually in-
`cludes application servers and clients. The focus of this book is on the in-
`teraction among database servers, but a brief review of the entire dis-
`tributed environment will clarify their raison d'être.
`
`Figure 1-3. A distributed database system
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s02.html
`
`1/2
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 009
`
`

`

`What Is a Distributed Database System? | Oracle Distributed Systems
`10/3/22, 7:21 PM
`Application servers, like database servers, typically are high-capacity ma-
`chines that run intensive utilities such as web applications, Oracle’s appli-
`cation cartridges, report generators, and so forth.
`
`The clients in this environment are typically PCs or Macintoshes or other
`lightweight computers running web browsers. The client’s role is to pro-
`vide an interface to the user, such as Forms (in Oracle Developer 2000)
`and web browsers. Client machines are characterized by low cost and the
`absence of a local database.
`
`Implicit in this distributed system architecture is the network . It links data-
`base servers, application servers, and clients. SQL*Net and Net8 are net-
`work interfaces that are protocol-independent and that provide commu-
`nication to networked databases.
`
`Support
`
`Sign Out
`
`©2022 O'REILLY MEDIA, INC. 
`
`TERMS OF SERVICE
`
`PRIVACY POLICY
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s02.html
`
`2/2
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 010
`
`

`

`10/3/22, 7:22 PM
`
`Benefits of Distributed Databases | Oracle Distributed Systems
`
`Benefits of Distributed Databases
`
`The separation of the various system components, especially the separa-
`tion of application servers from database servers, yields tremendous ben-
`efits in terms of cost, management, and performance.
`
`Tunability
`
`A machine’s optimal configuration is a function of its workload. Machines
`that house web servers, for example, need to service a high volume of
`small transactions, whereas a database server with a data warehouse has
`to service a relatively low volume of large transactions (i.e., complex
`queries). Separating the web server from the database server in this ex-
`ample allows the system administrators to optimize these machines with-
`out compromise. A machine configured as a web server will differ from a
`machine configured as a data warehouse database server. If performance
`problems arise in a distributed architecture, it is much easier not only to
`identify problems but also to solve them without the risk of compromis-
`ing other components.
`
`Platform Autonomy
`
`Since applications and databases do not reside on the same machines,
`there is no particular reason why they even need to reside on the same
`type of machine. SQL*Net and Net8 provide a protocol-independent net-
`work interface allowing connectivity among disparate platforms and
`even disparate database engines. This openness allows DBAs, developers,
`and desktop users to choose their platforms without being restricted by
`anybody else’s preferences or requirements. Whether you perform a ma-
`jor platform change such as moving from VMS to Unix or a minor up-
`grade such as from Solaris 2.5 to Solaris 2.6, you can make these changes
`without risking functionality changes in the Oracle database engine.
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s03.html
`
`1/4
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 011
`
`

`

`10/3/22, 7:22 PM
`Fault Tolerance
`
`Benefits of Distributed Databases | Oracle Distributed Systems
`
`The failure of a single component in a distributed architecture is much
`less drastic than in an environment in which databases and applications
`are housed on the same machine. Administrators can design failover
`methodologies that are appropriate to each component’s functionality.
`For example, database machines might implement parallel server or syn-
`chronous replication to protect against failure of a database machine,
`whereas application servers may have backup hardware available so that
`the application can run on a new machine if an application server fails.
`Protecting against failure of machines that house data is generally much
`more complicated than protecting against failure of machines that simply
`run applications.
`
`Scalability
`
`A server that houses nothing other than an Oracle database scales very
`predictably; sites taking advantage of the parallel query option (and/or
`parallel DML in Oracle8) can expect performance to be a nearly linear
`function of the number of processors (up to the point of at least 30 proces-
`sors on Solaris). Other applications may or not scale this way, but if the
`applications have their own host, system administrators can understand
`their requirements and allocate hardware resources appropriately.
`
`Location Transparency
`
`Location transparency means that neither applications nor users need to
`be concerned with the logistics of where data actually resides or how it is
`distributed. Needless to say, being shielded from these specifics enhances
`the usability of a database because developers and users do not need to
`consider such details as connect strings. Moreover, data can be relocated
`from one database instance to another with minimal impact on users and
`applications.
`
`Site Autonomy
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s03.html
`
`2/4
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 012
`
`

`

`Benefits of Distributed Databases | Oracle Distributed Systems
`10/3/22, 7:22 PM
`Distributed databases allow various locations to share their data without
`conceding administrative control. If a database instance at headquarters
`contains particularly sensitive information or has high availability re-
`quirements, it can still share data without compromising its security or
`availability. In addition, any given site in a distributed database environ-
`ment can follow its own administrative procedures and upgrade paths,
`within reason. Of course, we hope that administrators from various sites
`are in communication with one another and that they coordinate their
`activities, but they are in no way handcuffed to one another.
`
`Enhanced Security
`
`The components of the distributed architecture are completely indepen-
`dent of one another, which means that every site can be maintained inde-
`pendently. You can share data without sharing accounts and passwords.
`Each site can have its own administrators and its own sets of accounts,
`and private data can be kept private.
`
`As an example, you can implement a replicated environment with up-
`dateable snapshots that would allow users at a branch office to update
`something as sensitive as the salary table without having any access to
`the salary data for headquarters (horizontal partitioning) . As another exam-
`ple, you can use workflow partitioning (discussed in Chapter 15) in a multi-
`master replicated environment to limit the set of rows that can be updat-
`ed at any given site.
`
`You also can configure a distributed environment to provide security in
`the sense of survivability—that is, you can maintain two or more versions
`of entire schema by replicating them to different machines at different
`locations.
`
`There is no reason for developers or end users to have accounts on a
`database server, because all database access is through network APIs (Ap-
`plication Programming Interfaces). The database server’s exposure to ma-
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s03.html
`
`3/4
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 013
`
`

`

`Benefits of Distributed Databases | Oracle Distributed Systems
`10/3/22, 7:22 PM
`licious intruders and careless users is minimal. In fact, it is not uncom-
`mon for users to have no idea whatsoever where the database resides!
`
`Support
`
`Sign Out
`
`©2022 O'REILLY MEDIA, INC. 
`
`TERMS OF SERVICE
`
`PRIVACY POLICY
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s03.html
`
`4/4
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 014
`
`

`

`10/3/22, 7:22 PM
`
`Multiple Schema Versus Multiple Databases | Oracle Distributed Systems
`
`Multiple Schema Versus Multiple
`Databases
`
`Most designers and database administrators associate one schema with
`one application. (By schema, I mean an Oracle database account that owns
`the database objects that an application uses.) Whenever a new schema is
`introduced, the designers and DBAs must choose between giving the
`schema its own database or placing it with other schema in an existing
`database. A number of factors affect this decision
`
`The Single Database with Multiple Schema
`
`Quite often,it makes sense to let schema and applications share a data-
`base instance. The two primary advantages of this approach are lower
`administrative overhead and lower hardware costs. Every Oracle data-
`base instance carries a certain amount of overhead: disk space must be
`allocated to system, temporary, and rollback tablespaces; and memory
`must be allocated to the SGA (System Global Area). In addition, a DBA
`must manage users, SQL*Net configuration, database links, and so on. If
`you can minimize this overhead, by all means do so.
`
`If the schemas share data, then you may realize additional benefits. For
`example, an inventory application that shares a VENDORS table with an
`accounts payable application can access the table without depending on
`the availability of two databases. The administrative work is simplified
`because no database links are required, and application code is simplified
`because no error trapping need exist to handle the unavailability of the
`VENDORS table.
`
`Even if applications do not share data, you should consider placing differ-
`ent schema in the same database if you can answer “Yes” to all questions
`in Table 1.1.
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s04.html
`
`1/3
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 015
`
`

`

`Multiple Schema Versus Multiple Databases | Oracle Distributed Systems
`10/3/22, 7:22 PM
`Table 1-1. Conditions for Locating Application Schema in the Same
`Database Instance
`
`Requirement
`
`Yes
`
`No
`
`Are most users in the same location or using the same
`access path?
`
`Do the applications have the same administrative sup-
`port staff?
`
`Do the applications have compatible availability
`requirements?
`
`Do the applications have compatible database and OS
`version requirements and upgrade paths?
`
`Are the applications reasonably similar in functionality
`and load characteristics?
`
`Do the applications have the same usage level (e.g., QA,
`development, production, maintenance, etc.)?
`
` 
`
` 
`
` 
`
` 
`
` 
`
` 
`
` 
`
` 
`
` 
`
` 
`
` 
`
` 
`
`As a general rule, it is more economical to house schemas in a single data-
`base instance than to devote an instance to every application that comes
`down the pike. Don’t create additional instances without good reason.
`
`Database Instances Devoted to a Single
`Application
`
`If you answered “No” to any of the conditions in Table 1.1, then your
`schemas probably belong in separate database instances, even if they
`share data.
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s04.html
`
`2/3
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 016
`
`

`

`10/3/22, 7:22 PM
`
`Multiple Schema Versus Multiple Databases | Oracle Distributed Systems
`
`Support
`
`Sign Out
`
`©2022 O'REILLY MEDIA, INC. 
`
`TERMS OF SERVICE
`
`PRIVACY POLICY
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s04.html
`
`3/3
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 017
`
`

`

`10/3/22, 7:22 PM
`
`Options for Distributed Data | Oracle Distributed Systems
`
`Options for Distributed Data
`
`Oracle provides several methods for accessing data that is distributed
`among two or more database instances. All of these methods provide loca-
`tion transparency , which means that users and applications can manipulate
`data as though it were all in one single database instance. These various
`methods are summarized here and are described in detail throughout
`this book.
`
`Export/Import
`
`The Oracle export and import utilities (illustrated in Figure 1.4) are the
`most primitive method of sharing data among databases and are also
`used as part of a backup and recovery strategy. Export ( exp ) creates a
`file that is essentially a set of SQL statements that invoke the DDL (Data
`Description Language) and DML (Data Manipulation Language) required
`to create objects and insert data. Import ( imp ) is the utility that reads
`this file and executes the SQL statements to re-create the objects and pop-
`ulate tables. A full database export creates a file that you can use to re-
`create the entire database.
`
`Figure 1-4. Export/import
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s05.html
`
`1/9
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 018
`
`

`

`Options for Distributed Data | Oracle Distributed Systems
`10/3/22, 7:22 PM
`Unlike any of the other options, export and import are static. An export
`file contains the data from the time of the export and cannot be updated.
`In fact, an export file could easily be out of date before the export job is
`finished. In addition, you must specify the export option CONSISTENT=Y
`in order for all of the data in the export file to be consistent as of a single
`point in time. Exports are only one part of a comprehensive backup
`strategy.
`
`Database Links
`
`Database links are the invisible glue that makes location transparency
`possible. In more technical terms, a database link defines a connection
`from one database instance to another, and this definition is stored in the
`Oracle data dictionary. Since database link connections log in to a normal
`account in the remote database instance, you have complete control over
`its privileges and quotas.
`
`Used in conjunction with synonyms, database links (shown in Figure 1.5)
`can make remote objects appear to be local as far as applications and
`users are concerned.
`
`Figure 1-5. Database links
`
`If your inventory application at a manufacturing site needs to reference
`the VENDORS table at headquarters, you could provide location trans-
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s05.html
`
`2/9
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 019
`
`

`

`Options for Distributed Data | Oracle Distributed Systems
`10/3/22, 7:22 PM
`parency with the following three SQL statements:
`
`CREATE PUBLIC DATABASE LINK D8CA.BIGWHEEL.COM
` USING 'hqaccounting.bigwheel.com'
`
`CREATE PUBLIC SYNONYM vendors FOR vendors@D8CA.BIGWHEEL.COM
`
`GRANT SELECT ON vendors TO inventory_reader
`
`Since the CREATE DATABASE LINK statement in this example creates a
`PUBLIC link without specifying an account to connect to in the D8CA.BIG-
`WHEEL.COM database, this particular implementation assumes that
`every application user in the inventory database has an account in the re-
`mote database with the same password and with privileges to see the
`VENDORS table. If the remote database is unavailable, the VENDORS table
`also will be unavailable.
`
`Of course, there are several ways to provide location transparency; these
`are described in greater detail later in this book.
`
`Read-Only Snapshots
`
`If you have an application that cannot risk a dependency on the availabil-
`ity of a remote database, you could use a read-only snapshot (shown in
`Figure 1.6). A read-only snapshot is essentially a local table whose data is
`refreshed at specified intervals by performing a query against one or
`more remote tables. The inventory application could create the same
`functionality as the database link described in the previous section by fol-
`lowing these steps:
`
`CREATE PUBLIC DATABASE LINK D8CA.BIGWHEEL.COM
` USING 'hqaccounting.bigwheel.com'
`
`CREATE SNAPSHOT vendors
` REFRESH COMPLETE
` START WITH SYSDATE
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s05.html
`
`3/9
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 020
`
`

`

`10/3/22, 7:22 PM
`
`Options for Distributed Data | Oracle Distributed Systems
` NEXT TRUNC(sysdate + 1) + 10/1440
`AS
`SELECT vendor_id, company_name
`FROM
` vendors@D8CA.BIGWHEEL.COM
`
`CREATE PUBLIC SYNONYM vendors FOR vendors
`
`GRANT SELECT ON vendors TO inventory_reader
`
`This snapshot is populated when the CREATE SNAPSHOT statement exe-
`cutes, and is then refreshed every day from that point on at 10 minutes
`after midnight. Again, this is just one example of how the technique could
`be implemented; the details come later. Snapshots use the Oracle built-in
`package DBMS_JOB to schedule refreshes and require the INIT.ORA pa-
`rameter JOB_QUEUE_PROCESSES to be greater than zero.
`
`Figure 1-6. Read-only snapshot
`
`The benefit of read-only snapshots over database links and public syn-
`onyms is that the snapshot is available even when the remote site is not.
`The disadvantages are that the data is neither real time nor updateable.
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s05.html
`
`4/9
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 021
`
`

`

`10/3/22, 7:22 PM
`
`Options for Distributed Data | Oracle Distributed Systems
`
`NOTE
`Oracle introduced read-only snapshots with Oracle Ver-
`sion 7.0. The infrastructure this feature required has
`been expanded with each subsequent release, with addi-
`tional functionality such as updateable snapshots and ad-
`vanced replication. The base components include the job
`queue and triggers. The feature set is continuing to
`expand.
`
`Updateable Snapshots
`
`If your application needs to change data in a snapshot and send the
`changes back to the master site, you can use updateable snapshots,
`shown in Figure 1.7. A trigger on the snapshot table logs updates that are
`applied at the master site when the snapshot refreshes. Updateable snap-
`shots require the advanced replication facilities. A common use of up-
`dateable snapshots is an application that consolidates data from various
`sites into a single master site. For example, a bicycle company might col-
`lect sales transactions from its distributors every night, or travelling
`salespeople might enter customer leads on their laptops and upload this
`information to the headquarters database when they return to the office.
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s05.html
`
`5/9
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 022
`
`

`

`10/3/22, 7:22 PM
`
`Options for Distributed Data | Oracle Distributed Systems
`
`Figure 1-7. Updateable snapshots
`
`Two important characteristics of updateable snapshots, which distinguish
`them from multi-master replicated tables, are:
`
`They update only the master site.
`They can be disconnected from the master site for extended periods.
`
`You also can configure an updateable snapshot such that the updates are
`not sent back to the master. You can use this configuration to perform
`“What if " analyses against the local data without fear of overwriting the
`definitive values at the master site.
`
`Advanced Replication
`
`Advanced (or multi-master) replication (shown in Figure 1.8) is the most
`powerful of the replication options. You can use it to maintain a table at
`numerous sites, with updates at any one location being applied at all the
`other locations. There is no single “master” table, although there is a mas-
`ter definition site, from which schema maintenance must be performed.
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s05.html
`
`6/9
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 023
`
`

`

`Options for Distributed Data | Oracle Distributed Systems
`10/3/22, 7:22 PM
`Unlike the situation with snapshots, you can configure a multi-master en-
`vironment to provide real-time data; this technique is known as syn-
`chronous replication. If you use asynchronous replication (by far the more com-
`mon implementation), updates to a table are placed in the deferred queue
`and pushed to other participating sites at user-defined intervals.
`
`Figure 1-8. Multi-master replication
`
`Since updates can occur at several locations, these updates can conflict
`with one another. Oracle provides a number of built-in methods to assist
`in resolving these conflicts, such as Latest Timestamp and Site Priority,
`but these techniques must be selected carefully to guarantee that data al-
`ways converges. Conflict resolution, described in detail in Chapter 15, is
`usually the biggest challenge to creating and maintaining a successful
`implementation.
`
`Advanced replication also has some significant limitations:
`
`No support for sequences
`No support for LONG or LONG RAW or HHCODE data, although
`Oracle8 supports replication of binary large objects (BLOBs) and char-
`acter large objects (CLOBs)
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s05.html
`
`7/9
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 024
`
`

`

`10/3/22, 7:22 PM
`
`Options for Distributed Data | Oracle Distributed Systems
`Not recommended for applications performing massive updates (i.e.,
`updates to tens of thousands of rows per hour)
`
`Procedural Replication
`
`Procedural replication (shown in Figure 1.9) is the preferred way to per-
`form the massive updates that are not recommended with advanced
`replication. Instead of queuing up row-level changes and sending them to
`the other database instances, procedural replication queues calls to pro-
`cedures and sends them to the other participants. If, for example, you
`wanted to mark up the prices of all your products by five percent, you
`could replicate the procedure call UPDATE_PRICES(pct_increase => 5). The
`procedure will execute at every site with the same parameters.
`
`Figure 1-9. Procedural replication
`
`Oracle does not provide any conflict handlers that work in conjunction
`with procedural replication, so any routines that you want to use in this
`way must account for conflicts. In the price increase example, suppose
`that a price for one item had been changed at a remote site, and the
`change had not yet propagated to the site initiating the UPDATE_PRICES
`call. The data would not converge to the same values at both sites. Table
`
`https://learning.oreilly.com/library/view/oracle-distributed-systems/1565924320/ch01s05.html
`
`8/9
`
`Meta Platforms, Inc.
`Exhibit 1027
`Page 025
`
`

`

`Options for Distributed Data | Oracle Distributed Systems
`10/3/22, 7:22 PM
`1.2 summarizes the kinds of conflicts that may occur with procedural
`replication.
`
`Table 1-2. Potential Conflicts with Procedural Replication
`
`Time
`
`Activity
`
`12:00
`
`Sites agree
`
`CA
`Price
`
`NY
`Price
`
`$100
`
`$100
`
`12:05
`
`CA calls UPDATE_PRICES(pct_increase =>
`5)
`
`$105
`
`$100
`
`12:10
`
`NY site updates price to $120 before pro-
`cedure replicates
`
`$105
`
`$120
`
`12:15
`
`Procedure call replicates to NY site
`
`$105
`
`$126
`
`12:20
`
`Update from NY at 12:10 arrives at CA site
`
`$120
`
`