Tài liệu ORACLE8i- P25 doc

When you call the SET_CONTEXT procedure from your context setting package orfunction, you simply pass it the name of the context you want to use, the name ofthe context variable you wish

Trang 1

CHAPTER 21 • ORACLE8i DATABASE SECURITY

958

context package; user sign-on context package seems like a more appropriate name.)

The context area is an area of private memory that is unique to every session

con-nected to the database You will create placeholders in this memory area to store somevalues that are set at logon Later in the process, you will read the context memoryarea and retrieve these stored memory areas for use This is an optional step Youcould define the context area every time the user accesses the object, but thisapproach is faster, because you do these checks only once

You place values into the context area by creating a package or function that iscalled each time users log on to the database For this project, you will store the user’sassigned security level into a context variable whenever the user logs in This way,you can quickly retrieve this security value from the context area when you need it.This saves multiple trips to the security table to look up the security ID each time youneed that value

Before you can use a context namespace, you must first create the context space, which needs to be done only once for each specific context area The contextnamespace is created using the CREATE CONTEXT command (or you can use CREATE

name-OR REPLACE CONTEXT, if you prefer) When you create the context namespace, youdefine the package that will be used to set the values to be stored in the contextnamespace Typically, when you create the context, the associated package will nothave been created yet, and that’s okay You will create that package next

NOTE Creating the context namespace is similar to programming with a pointer Youfirst create the pointer, and then you allocate memory to it The same is true with a con-text You first create the context, and then the context setting package “allocates” what is

to be stored to the context (Okay, so all comparisons have limitations!)

After you have created the context area, you will use the DBMS_SESSION.SET_CONTEXT package to store a value in a context area This package allows you to cre-ate what amounts to variables and assign values to these variables These variablesand their assigned values are then poked into memory for quick retrieval later TheDBMS_SESSION.SET_CONTEXT procedure takes three parameters Here is the proce-dure definition:

PROCEDURE DBMS_SESSION.SET_CONTEXT( NAMESPACE VARCHAR2,ATTRIBUTE VARCHAR2,VALUE VARCHAR2);

Trang 2

When you call the SET_CONTEXT procedure from your context setting package orfunction, you simply pass it the name of the context you want to use, the name ofthe context variable you wish to create, and the value you wish to store associatedwith that variable

When you create the application context package, this package will take one eter, which is the username of the user who is signing onto the database You use theusername to cross-reference with the TBL_USER_ID table columns USER_NAME andSECURITY_LEVEL to determine what the proper security level setting for the usershould be You then set a context variable called security_level to the correct securitylevel for the user You will use a database logon trigger to call the package

param-Listing 21.7 shows the creation of a context and then the creation of the checking package

context-Listing 21.7: Creating the Context and Context-Checking Package

Grant the required privilege to create the context

CONNECT system/robertGRANT CREATE ANY CONTEXT TO spy_owner;

GRANT DROP ANY CONTEXT TO spy_owner;

GRANT CREATE ANY TRIGGER TO spy_owner;

GRANT ADMINISTER DATABASE TRIGGER TO spy_owner;

Now, connect and create the context We will reference the currently nonexisting package pkg_spy_owner_context_01 as the context-checking package We will write this package next

CONNECT spy_owner/spy_owner

Drop any preexisting context

DROP CONTEXT spy_owner.cont_spy_owner_01;

Create the context Note that we could have used CREATE OR REPLACE instead

CREATE CONTEXT cont_spy_owner_01USING spy_owner.pkg_spy_owner_context_01;

Now, create the pkg_spy_owner_context_01 package header

CREATE OR REPLACE package spy_owner.pkg_spy_owner_context_01AUTHID DEFINER AS

PROCEDURE proc_get_spy_context(p_usern IN VARCHAR2);

END;

ENFORCING ROW-LEVEL SECURITY

Beyond Simple Database Managment

P A R TIII

Trang 3

960

/

Now, create the package body

CREATE OR REPLACE PACKAGE BODY pkg_spy_owner_context_01AS

PROCEDURE proc_get_spy_context(p_usern IN VARCHAR2)IS

V_Spy_clearance NUMBER;

BEGIN

Now, take the p_usern, look it up in our tbl_userid table and get the correct clearance for this spy

SELECT security_levelINTO v_spy_clearanceFROM spy_owner.tbl_user_idWHERE user_name=p_usern;

These next two lines will store the username and the user clearance level in the context for later use

SYS.DBMS_SESSION.SET_CONTEXT(’cont_spy_owner_01’,’v_spy_clearance’,v_spy_clearance);

Keep in mind that setting the context, as done in Listing 21.7, and the actualimplementation of FGAC are two different things You are only setting the contextarea with the username and the clearance code because it will make the performance

of your security policy (which truly implements FGAC) better

Trang 4

Executing the Context Package at User Logon

Once the context-checking package is in place, you need to create a database logonevent trigger to call the application context package It is the job of this trigger to firewhen the user logs in to the database The user’s context area will be created, andthen the application context package will be executed, determining the security level

of the user

To create this logon trigger, you use the built-in SQL function SYS_CONTEXT Thisfunction returns the value of a specific context variable to the calling program or SQLstatement Oracle provides a built-in context namespace for each user session calledUSERENV You will use this built-in context namespace to get the username of theuser who is logging in to the database You will then pass that username to the appli-cation context-checking package You will use the values stored in the context areasshortly Listing 21.8 shows the logon trigger

Listing 21.8: Setting the Application Context with a Logon Trigger

CONNECT spy_owner/spy_owner

The logon triggerCREATE OR REPLACE TRIGGER tr_db_logon_01AFTER LOGON ON DATABASE

DECLAREspy_id VARCHAR2(30);

BEGINspy_id:=sys_context(’USERENV’,’SESSION_USER’);

pkg_spy_owner_context_01.proc_get_spy_context(spy_id);

EXCEPTIONWHEN others THENNULL;

END;

/

Creating the Security Enforcement Package

The next step is to create the security enforcement package The security enforcementpackage will be executed when a user attempts to access the table that the securityenforcement package will be assigned to in the next step To enforce the row-level

security, the security enforcement package adds a dynamic predicate to the SQL

state-ment that is being executed The dynamic predicate becomes an additional restriction

to be appended to the SQL statement to be executed (basically, extending the WHEREclause to include restrictions for the implementation of row security)

P A R TIII

Trang 5

962

You can actually take advantage of FGAC by just writing this policy package andtaking the next step, which is to register the package with the database You don’tneed to use contexts to use FGAC

In this example, you will append a predicate that basically says something to thiseffect:

WHERE users_security_level>=tbl_secured_information.min_security_id

Thus, if the user’s security level is greater than the minimum required security level inthe TBL_SECURED_INFORMATION table, the user will be able to perform a givenoperation on that table (such as UPDATE or SELECT) The security enforcement pack-age (called PKG_TBL_SECURED_INFO_01 in this example) will construct this predi-cate and return it as a VARCHAR2 datatype to the database, where it will be applied tothe SQL statement Listing 21.9 provides an example of the creation of the securityenforcement package

NOTE The additional predicate does not appear in data dictionary views of the SQLstatement, such as V$SQL

Listing 21.9: Creating the Security Enforcement Package

CONNECT spy_owner/spy_ownerCREATE OR REPLACE PACKAGE pkg_spy_authAUTHID DEFINER AS

FUNCTION fu_spy_check(p_schema VARCHAR2, p_name VARCHAR2)RETURN VARCHAR2;

IF v_clearance IS NOT NULLTHEN

Trang 6

V_predicate:= ’ min_security_id <= ’||v_clearance;

ELSEV_predicate:= ’ 1 = 2’;

2 is always going to evaluate as FALSE, this guarantees that you prevent access to thetable to unauthorized users Always include this clause to make sure your data is secured

If the clearance is not NULL, the package creates a predicate that indicates that thecolumn MIN_SECURITY_ID should be less than or equal to the clearance levelassigned Once this procedure is associated with the TBL_SECURED_INFORMATIONtable, all queries will have this predicate attached to the end of them, thus enforcingthe security

N OTE Some functions, such as DBMS_OUTPUT, will not execute in FGAC securityenforcement packages The package will compile but no output will be forthcoming Also,autonomous transactions will cause a row-level security package to fail when executed

This is likely seen as a circumvention of security by Oracle The UTL_FILE package, strangelyenough, appears to work fine

Registering the Security Enforcement Package

Now that you have written the security enforcement package, the final step is toenforce the rules represented by this package and relate that package to a table Thesecurity enforcement package is related to the table through the use of the DBMS_RLSpackage

NOTE Oracle does not allow any security policies to apply to the SYS schema

P A R TIII

Trang 7

964

The DBMS_RLS package is used to register your security enforcement package withthe table that you wish that package to administer, as well as to manage the securityenforcement packages This package includes the DBMS_RLS.ADD_POLICY, DBMS_RLS.DROP_POLICY, DBMS_RLS.ENABLE_POLICY, and DBMS_RLS.REFRESH_POLICYprocedures In this example, you use the DBMS_RLS.ADD_POLICY procedure to regis-ter the security enforcement package Let’s take a quick look at that procedure:

PROCEDURE dbms_rls.add_policyArgument Name Type In/Out Default?

- - OBJECT_SCHEMA VARCHAR2 IN DEFAULTOBJECT_NAME VARCHAR2 IN

-POLICY_NAME VARCHAR2 INFUNCTION_SCHEM VARCHAR2 IN DEFAULTPOLICY_FUNCTION VARCHAR2 IN

STATEMENT_TYPES VARCHAR2 IN DEFAULTUPDATE_CHECK BOOLEAN IN DEFAULTENABLE BOOLEAN IN DEFAULT

Listing 21.10 shows how to use this procedure to register the security enforcementpackage created with the database so it will execute on any DML statement that isexecuted on the table TBL_SECURED_INFORMATION

Listing 21.10: Adding the Policy with the DBMS_RLS.ADD_POLICY Procedure

CONNECT SYS/yourpassword

BEGINDbms_rls.add_policy(’SPY_OWNER’,’TBL_SECURED_INFORMATION’,

Trang 8

TABLE 21.5: PARAMETERS FOR THE DBMS_RLS.ADD_POLICY PROCEDURE

Argument Default Value Description

Object_schema NULL The schema that contains the table or view that you

wish to register the policy for If NULL, the currentuser schema will be used

Object_name None The name of the table or view that the policy is

being added to

Policy_name None The name of the policy being assigned to the table

or view This name must be unique for each object

Function_schema NULL The name of the schema that owns the policy

func-tion that is to be used If NULL, the current user thatyou are logged in as will be used

Policy_function None The name of the function/package that is used to

create the dynamic predicate (this is the securityenforcement package)

Statement_types All The statement types that the policy should apply to

(SELECT, INSERT, UPDATE, DELETE)

Update_check FALSE Causes the value to be checked again after an

UPDATE or INSERT statement completes

Enable TRUE Enables the policy The policy can be selectively

enabled or disabled with the DBMS_RLS.ENABLEprocedure

NOTE When you begin planning your security with FGAC, you may end up crafting tiple policies for the same table Oracle supports this type of approach, allowing you toregister multiple policies for the same table

mul-The other procedures in the DBMS_RLS package allow you to manage your cies You can drop policies with the DROP_POLICY procedure, enable or disable poli-cies with the ENABLE_POLICY procedure, and use the REFRESH_POLICY procedure tocause all SQL statements associated with the policy to be re-parsed

poli-Testing the Security Enforcement Package

So, you’ve written code, set up logon triggers, created the security enforcement age, and added it as a security policy You’re ready to go! Listing 21.11 provides the

pack-ENFORCING ROW-LEVEL SECURITY

P A R TIII

Trang 9

SQL> SELECT * FROM tbl_secured_information;

MIN_SECURITY_ID SECRET_INFORMATION - -

0 This is boring public information

10 Men are NOT from Mars!!

20 But the Aliens are from Mars!!

100 And they are here to take over the world

SQL> CONNECT public_access/public_accessConnected

SQL> /

no rows selected

SQL> CONNECT secret_spy/secret_spyConnected

SQL> /

SQL> CONNECT top_secret_spy/top_secret_spyConnected

SQL> /

SQL> CONNECT license_to_kill/license_to_kill

Trang 10

Connected

SQL> /

100 And they are here to take over the world

The Good, the Bad, and the Ugly about FGAC

As is typical of any new feature, there are some good things and some bad thingsabout using FGAC The fact that FGAC works in the background, so that it is invisible

to the user, is one of the advantages of using FGAC And, of course, there is the fit of making your database more secure

bene-The main negative aspect to FGAC is the complexity involved in implementing thefeature However, once you have done it a couple of times, it becomes easier

Another issue with FGAC is the fact that it has the potential to negatively impactperformance Since the predicate to be added changes the SQL statement, you canend up with an execution plan that is different from what you expected Since youhave almost no way of knowing what predicate is being attached to the SQL state-ment, it makes tuning that SQL statement much more difficult The complete SQLstatement, with the predicate, doesn’t show up in the V$SQL view, and the predicatedoesn’t appear if you enable Autotrace If you look in a trace file, you will not see apredicate associated with your session

Predicates can impact performance Depending on the predicate to be added, youcould end up with more table joins than you expected, quickly turning a simple twotable join into a three- or four-table join (or more) As a developer, DBA, or databasearchitect, you need to consider the impacts of predicates and make sure that indexesare created to assist the database in properly handling the addition of the predicates

There is one way to determine what predicate is being added when you are ning SQL statements: Add event 10730 Setting this event will provide you with atrace file that contains the complete SQL statement you issued This SQL statementwill also include the dynamic FGAC predicate attached If you are using Oracle ver-sion 8.1.5, your output will look somewhat different in that only the predicate willappear In Oracle version 8.1.6 and later, you will find that the entire SQL statementappears, as shown here:

run-ALTER SESSION SET EVENTS= ‘10730 trace name context forever, level 10’;

P A R TIII

Trang 11

968

*** 2001-06-03 09:51:16.034

*** SESSION ID:(8.3) 2001-06-03 09:51:16.014 -Logon user : SPY_OWNER

Table or View : SPY_OWNER.TBL_SECURED_INFORMATIONPolicy name : SPY_OWNER

Policy function: SPY_OWNER.PKG_SPY_AUTH.FU_SPY_CHECKRLS view :

SELECT “MIN_SECURITY_ID”,”SECRET_INFORMATION” FROM “SPY_OWNER”

“TBL_SECURED_INFORMATION” “TBL_SECURED_INFORMATION”

WHERE ( min_security_id <= 10000)

Enforcing Column-Level Security

Do you need to secure your data even more? You may want to go an additionalstep and encrypt the data within the columns of the tables in your Oracle database.This functionality is facilitated through triggers and the DBMS_OBFUSCATION_TOOLKIT package

Oracle8i does not install the OBFUSCATION toolkit by default You will need torun the catobtk.sql script, stored in the $ORACLE_HOME/rdbms/admin directory Youshould run this script only when connected as INTERNAL or as SYS; otherwise, thetoolkit will not work properly

After you run the script, you will find that your database has a new package calledDBMS_OBFUSCATION_TOOLKIT This package contains two overloaded procedures(thus, it’s just like having four scripts) Here is a description of the four scripts:

SQL> DESC dbms_obfuscation_toolkitPROCEDURE DESDECRYPT

Argument Name Type In/Out Default?

- - - INPUT RAW IN

-KEY RAW INDECRYPTED_DATA RAW OUT

PROCEDURE DESDECRYPTArgument Name Type In/Out Default?

- - INPUT_STRING VARCHAR2 IN

Trang 12

KEY_STRING VARCHAR2 INDECRYPTED_STRING VARCHAR2 OUT

PROCEDURE DESENCRYPTArgument Name Type In/Out Default?

- - INPUT RAW IN

-KEY RAW INENCRYPTED_DATA RAW OUT

PROCEDURE DESENCRYPTArgument Name Type In/Out Default?

- - INPUT_STRING VARCHAR2 IN

-KEY_STRING VARCHAR2 INENCRYPTED_STRING VARCHAR2 OUT

Notice that the two main themes of the procedures are to encrypt data and decryptdata There is one set of procedures for string data and another set for RAW datatypes

The parameter names are different for each procedure When using an OBFUSCATIONtoolkit procedure, you must use named notation to refer to the correct parametername; otherwise, Oracle may generate an error because it will not be sure which script

to use

Encrypting Data

To encrypt data, use the DESENCRYPT procedure It’s fairly straightforward, as shown

in Listing 21.12 This listing creates a table called USER_INFORMATION We want

to encrypt the data going into one of the columns of this table, the INFORMATIONcolumn We do this by creating a trigger that fires each time a row is inserted into the table

Listing 21:12: Encrypting Data Using the DESENCRYPT Procedure

SQL> DESC user_informationName Null? Type - - -USER_NAME VARCHAR2(30)INFORMATION VARCHAR2(2000)

CREATE OR REPLACE TRIGGER tr_user_information_01BEFORE INSERT ON user_information

ENFORCING COLUMN-LEVEL SECURITY

P A R TIII

Trang 13

970

FOR EACH ROWDECLAREv_stuff varchar2(2048);

dbms_obfuscation_toolkit.desencrypt(

input_string => v_temp,key_string=>v_keystring,encrypted_string=>v_stuff);

After loading this trigger, any time a user inserts data into the table, it will be tected SELECT statements on the table will reveal only gibberish in the securedcolumns (unless they are decrypted), as in this example:

pro-SQL> INSERT INTO user_information VALUES (‘SYS’,’TEST’);

1 row created

SQL> SELECT * FROM user_information;

USER_NAME INFORMATION - -SYS =| |_ ↕♥M

You will see an example of decrypting the data in the next section The same basicprocess applies to RAW data encryption

Trang 14

Decrypting Data

One of the problems with decrypting data is that it cannot be done simply in a SQLstatement Because of the way the procedure is written, the return value for the unen-crypted string comes to us by way of an IN/OUT variable that must be defined Thus,PL/SQL is about the only way to get at what you need Listing 21.13 provides anexample of retrieving encrypted data from the database and displaying its contents

Listing 21.13: Retrieving Encrypted Data

SET SERVEROUTPUT ONDECLARE

input_string=>v_cursor_one.information,key_string=>v_key,

decrypted_string=>v_stuff);

dbms_output.put_line(‘User name ‘||v_cursor_one.user_name);

dbms_output.put_line(‘Information ‘||v_stuff);

END LOOP;

END;

/Enter value for 1: SYSold 8: for v_cursor_one in(select * from user_information where user_name=’&1’)new 8: for v_cursor_one in

(select * from user_information where user_name=’SYS’)User name SYS

Information TESTPL/SQL procedure successfully completed

As you can see, we retrieved the row from the table that we created earlier Then wedecrypted the data before we displayed it

ENFORCING COLUMN-LEVEL SECURITY

P A R TIII

Trang 15

CHAPTER 22

SQL*Loader

F E A T U R I N G : Introduction to SQL*Loader 974 The input files 979 The “output”: discards and rejects 991 SQL*Loader log files 994 Loading objects, collections, LOBs, and partitioned objects 996 Running SQL*Loader 1001

Trang 16

In SQL*Loader, Oracle has provided a tool that enables us to take data from an

external source and load it into Oracle This is generally accomplished with flatfiles that are in both a comma-delimited as well as fixed-length format Over theyears, our personal experience with SQL*Loader has been good, and we’vefound it an efficient tool for converting databases from many different sources intoOracle

This chapter explains the elements and operations of SQL*Loader You’ll examinethe parts of the important control file and all of its options that are available, and seeexamples of creating a control file We’ll discuss the input datafile, the output files(BADFILE and DISCARDFILE), and the log file You’ll read about the various methods

of loading data, and how to execute SQL*Loader from the command line or using ascript

NOTE The case studies in the Oracle documentation are good examples that will helpyou understand how to use SQL*Loader

Introduction to SQL*Loader

SQL*Loader will bring data in from a source external to Oracle and place that datainto Oracle tables There are two sources of input: the control file and the actual inputdatafile The datafile, of course, contains the data you wish to load into Oracle Thecontrol file describes the data to be loaded, its location, how it is to be loaded thedata, and more

There’s a log file, as well, that tracks information about the load from beginning

to end

Discarded and rejected rows are placed in two separate files for your convenience.Discarded rows are the items that did not match the selection criteria of the controlfile, and rejected rows are items containing incorrect data and have been rejected byeither Oracle processing or by the SQL*Loader utility

Figure 22.1 represents the relationship between SQL*Loader and the input and put files

Trang 17

• It is a prebuilt Oracle utility, supported by Oracle.

• Choice of three different record formats for the input datafiles

• You can filter out unwanted data

• You can load data from one input source into multiple Oracle tables

• You can validate and transform data as it is being loaded

• Data is loaded speedily and accurately into your tables

• Ability to reuse the control file for multiple runs

All of these features and more are discussed in this chapter We’ll cover the logicalareas of input (control file and data files), the “output” (bad file, discard file, and logfile), and the types of data loads possible (direct, conventional, and parallel)

Conventional and Direct Path Loads

With SQL*Loader you have two methods of loading data: the conventional path loadand the direct path load You specify the load path when creating the control file, inthe OPTIONS section of the control file If you specify the DIRECT parameter, then

Database

DataInput Files

DiscardFile

ControlFile

LogFile

BadFilesSQL*Loader

975

INTRODUCTION TO SQL*LOADER

P A R TIII

Trang 18

privi-Although direct path load can load data into the Oracle table faster, the direct pathmethod has more restrictions Conventional path is what is used most often.

For more information about all three load methods, consult Oracle’s tion on SQL*Loader

documenta-Conventional Path Load

Conventional path load is the default load type and will be used if you do not specify a

load method You can use any of the record formats with this method (VariableRecord Format, Fixed Record Format, and Stream Record Format) Oracle parses eachrow in accordance with the control file’s INTO TABLE clause specifications Each row

is then loaded into a series of bind arrays that match the columns specified in thecontrol file When the bind array is full, an array INSERT is executed, and the processcontinues until all data has been processed

NOTE If any errors occur on a LOB field, the column is left empty for the row beinginserted

Since SQL*Loader competes with all other processes for buffer space and resources,the same conventional path load may run for five minutes one time and half an hourthe next In addition to competing for the buffer space, SQL*Loader incurs extra over-head for creating the SQL INSERT statements that are actually sent to Oracle forinserting rows into the table

Trang 19

When to Use a Conventional Path Load

There are many reasons to use conventional path load and circumstances underwhich it will most benefit database processing

• When speed is not important; that is, it doesn’t matter how long theSQL*Loader session takes

• When space is an issue (conventional path load will insert data under the water mark)

high-• When direct path load cannot be utilized

• When the table into which you are loading has a column type of LOB

• When the table into which you are loading has a column type of VARRAY

• When table constraints are present

Direct Path Load

Direct path load handles the input data differently than does conventional path load.

Instead of filling a bind array buffer, direct path load parses the input data in dance with the control file’s layout and field specifications Oracle then converts thedata for each and every field into a matching column array structure Next, the col-umn array structures are created to form an Oracle data block and build index keys

accor-These database blocks are then written directly to the database Multiple buffers areused for these formatted blocks

Writing the data blocks directly to the database bypasses most of the overheadassociated with conventional path load Bypassing the multiple inserts constraintchecking that is associated with the conventional path load makes direct path loadfaster However, after direct patch load you will have to rebuild the indexes andreestablish the primary and foreign key constraints to make the tables useful again

To run SQL*Loader with direct path loading, just set DIRECT=TRUE on the mand line or in the OPTIONS clause of the control file Also, the catldr.sql scriptmust already have been run This script is generally run when the database is created

com-as part of the procedure CATPROC.SQL

Restrictions on Direct Path Load

The direct path load has several restrictions, including the following (For a completelist, consult the Oracle documentation.)

• SQL strings are not allowed in the control file

• The table into which you are loading data cannot contain LOB or VARRAY umn types

col-INTRODUCTION TO SQL*LOADER

P A R TIII

Trang 20

CHAPTER 22 • SQL*LOADER

978

• The table into which you are loading data cannot contain object columns,nested table columns, or clustered tables

• Table constraints cannot be enabled

• Triggers are not fired

Parallel Direct Path Load

The main difference between direct path load and parallel direct path load is that the

load is performed in parallel (see Chapter 18 for a full explanation of parallel ing) All the restrictions on using direct path load also apply for parallel direct pathload In addition, there are a few other limitations:

process-• Local and global indexes are not maintained during parallel direct path load.That means all indexes on the table being loaded will need to be re-created

• All triggers on the table being loaded must be disabled

• All referential integrity and check constraints must be disabled on the tablebeing loaded

• Only the APPEND loading method is allowed

Reserved Words

Like SQL, SQL*Loader uses reserved words (keywords) when identifying its tions If you have a table, column, or any other object named with a SQL*Loaderreserved word, you must place quotation marks around that object name Table 22.1

instruc-is an alphabetical linstruc-ist of these reserved words

TABLE 22.1: SQL*LOADER RESERVED WORDS

Tiêu đề	Oracle8i Database Security
Chuyên ngành	Database Security
Thể loại	Lecture Notes

Định dạng
Số trang	40
Dung lượng	502,32 KB