The following sections explain some of the topics relating to database management in an Oracle Database distributed database system:
Site Autonomy
Site autonomy means that each server participating in a distributed database is administered independently from all other databases. Although several databases can work together, each database is a separate repository of data that is managed individually. Some of the benefits of site autonomy in an Oracle Database distributed database include:
Although Oracle Database permits you to manage each database in a distributed database system independently, you should not ignore the global requirements of the system. For example, you may need to:
Distributed Database Security
The database supports all of the security features that are available with a nondistributed database environment for distributed database systems, including:
The following sections explain some additional topics to consider when configuring an Oracle Database distributed database system:
Authentication Through Database Links
Database links are either private or public, authenticated or nonauthenticated. You create public links by specifying the PUBLIC keyword in the link creation statement. For example, you can issue:
CREATE PUBLIC DATABASE LINK foo USING 'sales';You create authenticated links by specifying the CONNECT TO clause, AUTHENTICATED BY clause, or both clauses together in the database link creation statement. For example, you can issue:
CREATE DATABASE LINK sales CONNECT TO scott IDENTIFIED BY tiger USING 'sales'; CREATE SHARED PUBLIC DATABASE LINK sales CONNECT TO mick IDENTIFIED BY jagger AUTHENTICATED BY david IDENTIFIED BY bowie USING 'sales';Authentication Without Passwords
When using a connected user or current user database link, you can use an external authentication source such as Kerberos to obtain end -to -end security. In end -to -end authentication, credentials are passed from server to server and can be authenticated by a database server belonging to the same domain. For example, if jane is authenticated externally on a local database, and wants to use a connected user link to connect as herself to a remote database, the local server passes the security ticket to the remote database.
Supporting User Accounts and Roles
In a distributed database system, you must carefully plan the user accounts and roles that are necessary to support applications using the system. Note that:
As you create the database links for the nodes in a distributed database system, determine which user accounts and roles each site needs to support server -to -server connections that use the links.
In a distributed environment, users typically require access to many network services. When you must configure separate authentications for each user to access each network service, security administration can become unwieldy, especially for large systems.
Centralized User and Privilege Management
The database provides different ways for you to manage the users and privileges involved in a distributed system. For example, you have these options:
Schema -Dependent Global Users One option for centralizing user and privilege management is to create the following:
For example, you can create a global user called fred with the following SQL statement:
CREATE USER fred IDENTIFIED GLOBALLY AS 'CN=fred adams,O=Oracle,C=England';This solution allows a single global user to be authenticated by a centralized directory.
The schema-dependent global user solution has the consequence that you must create a user called fred on every database that this user must access. Because most users need permission to access an application schema but do not need their own schemas, the creation of a separate account in each database for every global user creates significant overhead. Because of this problem, the database also supports schema -independent users, which are global users that an access a single, generic schema in every database.
Schema -Independent Global Users The database supports functionality that allows a global user to be centrally managed by an enterprise directory service. Users who are managed in the directory are called enterprise users. This directory contains information about:
The administrator of each database is not required to create a global user account for each enterprise user on each database to which the enterprise user needs to connect. Instead, multiple enterprise users can connect to the same database schema, called a shared schema.
For example, suppose jane, bill, and scott all use a human resources application. The hq application objects are all contained in the guest schema on the hq database. In this case, you can create a local global user account to be used as a shared schema. This global username, that is, shared schema name, is guest. jane, bill, and scott are all created as enterprise users in the directory service. They are also mapped to the guest schema in the directory, and can be assigned different authorizations in the hq application. Figure below illustrates an example of global user security using the enterprise directory service:
Global User Security
Assume that the enterprise directory service contains the following information on enterprise users for hq and sales:
Database Role Schema Enterprise Users table
Also, assume that the local administrators for hq and sales have issued statements as follows:
Assume that enterprise user scott requests a connection to local database hq in order to execute a distributed transaction involving sales. The following steps occur (not necessarily in this exact order):
Data Encryption
The Oracle Advanced Security option also enables Oracle Net and related products to use network data encryption and check summing so that data cannot be read or altered. It protects data from unauthorized viewing by using the RSA Data Security RC4 or the Data Encryption Standard (DES) encryption algorithm. To ensure that data has not been modified, deleted, or replayed during transmission, the security services of the Oracle Advanced Security option can generate a cryptographically secure message digest and include it with each packet sent across the network.
Auditing Database Links
You must always perform auditing operations locally. That is, if a user acts in a local database and accesses a remote database through a database link, the local actions are audited in the local database, and the remote actions are audited in the remote database, provided appropriate audit options are set in the respective databases. The remote database cannot determine whether a successful connect request and subsequent SQL statements come from another server or from a locally connected client. For example, assume the following:
Actions performed during the remote database session are audited as if scott were connected locally to hq and performing the same actions there. You must set audit options in the remote database to capture the actions of the username --in this case, scott on the hq database--embedded in the link if the desired effect is to audit what jane is doing in the remote database.
You cannot set local auditing options on remote objects. Therefore, you cannot audit use of a database link, although access to remote objects can be audited on the remote database.
Administration Tools
The database administrator has several choices for tools to use when managing an Oracle Database distributed database system:
Enterprise Manager
Enterprise Manager is the Oracle Database administration tool that provides a graphical user interface (GUI). Enterprise Manager provides administrative functionality for distributed databases through an easy -to -use interface. You can use Enterprise Manager to:
Thus, you can reexecute statements without retyping them, a particularly useful feature if you need to execute lengthy statements repeatedly in a distributed database system.
Third-Party Administration Tools
Currently more than 60 companies produce more than 150 products that help manage Oracle Databases and networks, providing a truly open environment.
SNMP Support
Besides its network administration capabilities, Oracle Simple NetworkManagement Protocol (SNMP) support allows an Oracle Database server to be located and queried by any SNMP -based network management system. SNMP is the accepted standard underlying many popular network management systems such as:
|
|
Oracle 10g Related Tutorials |
|
---|---|
Oracle 9i Tutorial | Oracle 8i Tutorial |
Informatica Tutorial | Oracle 11g Tutorial |
Oracle 10g Related Interview Questions |
|
---|---|
Oracle 10g Interview Questions | Oracle 9i Interview Questions |
Oracle 8i Interview Questions | Informatica Interview Questions |
PL/SQL Interview Questions | Oracle 11g Interview Questions |
SQL Interview Questions | Oracle apps Interview Questions |
Sybase Interview Questions | Oracle Apps ERP Interview Questions |
Oracle 7.3 Interview Questions | Oracle Access Manager Interview Questions |
Oracle Application Framework Interview Questions | Oracle Apps DBA Interview Questions |
Oracle 10g Related Practice Tests |
|
---|---|
Oracle 10g Practice Tests | Oracle 9i Practice Tests |
Oracle 8i Practice Tests | Informatica Practice Tests |
PL/SQL Practice Tests | Oracle 11g Practice Tests |
SQL Practice Tests | Oracle apps Practice Tests |
Sybase Practice Tests | Oracle Apps ERP Practice Tests |
Oracle 7.3 Practice Tests |
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.