11g New Features For Administrators Student Guide-11 PDF

Example of Repairing a Failure (continued)
Starting recover at 21-DEC-06

using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 5 is already on disk as file

/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2006_12_20/o1_mf_
1_5_2rm50clp_.arc
1_6_2rmsgwyo_.arc
1_7_2rnbosby_.arc
1_8_2rnyc4c5_.arc
1_9_2rolp2b4_.arc
1_10_2rp2gg32_.arc
1_11_2rpllvqk_.arc
archived log file
name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2006_12_20/o
1_mf_1_5_2rm50clp_.arc thread=1 sequence=5
archived log file
name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2006_
12_20/o1_mf_1_6_2rmsgwyo_.arc thread=1 sequence=6
archived log file
1_mf_1_7_2rnbosby_.arc thread=1 sequence=7
archived log file
1_mf_1_8_2rnyc4c5_.arc thread=1 sequence=8
archived log file
1_mf_1_9_2rolp2b4_.arc thread=1 sequence=9
media recovery complete, elapsed time: 00:00:01
Finished recover at 21-DEC-06
sql statement: alter database datafile 5 online

repair failure complete
RMAN>
Oracle Database 11g: New Features for Administrators 13 - 19

Executing Repairs
13 - 20 Copyright © 2007, Oracle. All rights reserved.
Executing Repairs
In Enterprise Manager, the Data Recovery Advisor leads you to this page. The job scheduler
initiates the execution of the RMAN repair script.

Executing Repairs
...
Executing Repairs
The Data Recovery Advisor displays this page. In the preceding example, a successful repair is
completed.

Data Recovery Advisor Views
Querying dynamic data dictionary views:

• V$IR_FAILURE: Listing all failures, including closed
ones (result of the LIST FAILURE command)
• V$IR_MANUAL_CHECKLIST: Listing of manual advice
(result of the ADVISE FAILURE command)
• V$IR_REPAIR: Listing of repairs (result of the ADVISE
FAILURE command)
Data Recovery Advisor Views

See the Oracle Database Reference for details on the dynamic data dictionary views that the
Data Recovery Advisor uses.

Best Practice: Proactive Checks
Invoking proactive health check of the database and its

components:
• Health Monitor or RMAN VALIDATE DATABASE
command
• Checking for logical and physical corruption
• Findings logged in ADR
Best Practice: Proactive Checks

For very important databases, you may want to execute additional proactive checks (possibly
daily during low peak interval periods). You can schedule periodic health checks through Health
Monitor or by using the RMAN VALIDATE command. In general, when a reactive check detects
failure(s) in a database component, you may want to execute a more complete check of the
affected component.
The RMAN VALIDATE DATABASE command is used to invoke health checks for the database
and its components. It extends the existing VALIDATE BACKUPSET command. Any problem
detected during validation is displayed to you. Problems initiate the execution of a failure
assessment. If a failure is detected, it is logged into the Automated Diagnostic Repository (ADR)
as a finding. You can use the LIST FAILURE command to view all failures recorded in the
repository.
The VALIDATE command supports validation of individual backup sets and data blocks. In a
physical corruption, the database does not recognize the block at all. In a logical corruption, the
contents of the block are logically inconsistent. By default, the VALIDATE command checks for
physical corruption only. You can specify CHECK LOGICAL to check for logical corruption as
well.

Best Practice: Proactive Checks (continued)
Block corruptions can be divided into interblock corruption and intrablock corruption. In
intrablock corruption, the corruption occurs within the block itself and can be either physical or
logical corruption. In interblock corruption, the corruption occurs between blocks and can only
be logical corruption. The VALIDATE command checks for intrablock corruptions only.
Example:
RMAN> validate database;
Starting validate at 21-DEC-06

using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00001
name=/u01/app/oracle/oradata/orcl/system01.dbf
name=/u01/app/oracle/oradata/orcl/sysaux01.dbf
name=/u01/app/oracle/oradata/orcl/example01.dbf
name=/u01/app/oracle/oradata/orcl/undotbs01.dbf
name=/u01/app/oracle/oradata/orcl/users01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:15
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1 OK 0 13168 85760 981642
File Name: /u01/app/oracle/oradata/orcl/system01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 60619
Index 0 9558
Other 0 2415
---- ------ -------------- ------------ --------------- ----------
2 OK 0 22892 66720 981662
File Name: /u01/app/oracle/oradata/orcl/sysaux01.dbf
---------- -------------- ----------------
Data 0 10529
Index 0 9465
Other 0 23834

Best Practice: Proactive Checks (continued)
---- ------ -------------- ------------ --------------- ----------
3 OK 0 104 7680 981662
File Name: /u01/app/oracle/oradata/orcl/undotbs01.dbf
---------- -------------- ----------------
Data 0 0
Index 0 0
Other 0 7576
---- ------ -------------- ------------ --------------- ----------
4 OK 0 24 640 963835
File Name: /u01/app/oracle/oradata/orcl/users01.dbf
---------- -------------- ----------------
Data 0 43
Index 0 63
Other 0 510
---- ------ -------------- ------------ --------------- ----------
5 OK 0 1732 12800 745885
File Name: /u01/app/oracle/oradata/orcl/example01.dbf
---------- -------------- ----------------
Data 0 4416
Index 0 1303
Other 0 5349
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
including current control file for validation
including current SPFILE in backup set
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Control File and SPFILE
===============================
File Type Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE OK 0 2
Control File OK 0 594
Finished validate at 21-DEC-06
RMAN>

These
These22slides
slidescould
couldbe
beremoved
removedififthere
thereisistoo
toomuch
muchcontent.
content.
Setting Corruption-Detection Parameters
...
...
NEW
...
NEW
EM > Server > Initialization Parameters

You can use the DB_ULTRA_SAFE parameter for easy manageability. It affects the default
values of the following parameters:
• DB_BLOCK_CHECKING, which initiates checking of database blocks. This check can often
prevent memory and data corruption. (Default: FALSE, recommended: FULL)
• DB_BLOCK_CHECKSUM, which initiates the calculation and storage of a checksum in the
cache header of every data block when writing it to disk. Checksums assist in detecting
corruption caused by underlying disks, storage systems or I/O systems. (Default: TYPICAL,
recommended: TYPICAL)
• DB_LOST_WRITE_PROTECT, which initiates checking for "lost writes". Data block lost
writes occur on a physical standby database, when the I/O subsystem signals the completion
of a block write, which has not yet been completely written in persistent storage. Of course,
the write operation has been completed on the primary database. (Default: TYPICAL,
recommended: TYPICAL)
If you set any of these parameters explicitly, then your values remain in effect. The
DB_ULTRA_SAFE parameter changes only the default values for these parameters.

DB_ULTRA_SAFE OFF DATA_ONLY DATA_AND_INDEX
DB_BLOCK_CHECKING OFF or MEDIUM FULL or TRUE

FALSE
DB_BLOCK_CHECKSUM TYPICAL FULL FULL
DB_LOST_WRITE_PROTECT TYPICAL TYPICAL TYPICAL
Setting Corruption-Detection Parameters (continued)

Depending on your system's tolerance for block corruption, you can intensify the checking for
block corruption. Enabling the DB_ULTRA_SAFE parameter (default: OFF) results in increased
system overhead, because of these more intensive checks. The amount of overhead is related to
the number of blocks changed per second; so it cannot be easily quantified. For a 'high-update'
application, you can expect a significant increase in CPU, likely in the ten to twenty percent
range, but possibly higher. This overhead can be alleviated by allocating additional CPUs.

Summary
In this lesson, you should have learned how to:

• Describe your options for repairing data failure
• Use the new RMAN data repair commands:
– List failures
– Receive repair advice
– Repair failure
• Perform proactive failure checks
• Query the Data Recovery Advisor views

Practice 13 Overview:
This practice covers the following topics:

• Using the Data Recovery Advisor

Security New Features
Copyright © 2007, Oracle. All rights reserved.

Objectives
After completing this lesson, you should be able to:

• Configure the password file to use case sensitive
passwords
• Encrypt a tablespace
• Create a virtual private catalog for RMAN
• Configure fined grained access to network services

Secure Password Support
More Secure Password Support. Passwords

• May be longer (up to 50 characters)
• Are case sensitive
• Contain more characters
• Use more secure hash algorithm
• Use salt in the hash algorithm
Usernames are still Oracle identifiers (up to 30 characters,
case insensitive)
Secure Password Support

You must use more secure passwords to meet the demands of compliance to various security and
privacy regulations. Passwords that very short and passwords that are formed from a limited set of
characters are susceptible to brute force attacks. Longer passwords with more different characters
allowed make the password much more difficult to guess or find. In Oracle Database 11g, the
password is is handled differently than in previous versions;
• Passwords may be longer. 50 character passwords are allowed.
• Passwords are case sensitive. Upper and lower case characters are now different characters
when used in a password.
• Passwords may contain special characters, and multibyte characters. In previous versions of
the database only the ‘$’,’_’, and ‘#’ special characters were allowed in the password without
quoting the password.
• Passwords are always passed through a hash algorithm, then stored as a user credential. When
the user presents a password, it is hashed then compared to the stored credential. In Oracle
Database 11g the hash algorithm is SHA-1 of the public algorithm used in previous versions
of the database. SHA-1 is a stronger algorithm using a 160 bit key.
• Passwords always use salt. A hash function always produces the same output, given the same
input. Salt is a unique (random) value that is added to the input, to insure the output
credential in unique.

Automatic Secure Configuration
• Default password profile

• Default auditing
• Built-in Password complexity checking
Automatic Secure Configuration

Oracle Database 11g installs and creates the database with certain security features recommended
by the CIS (Centre for Internet Security) benchmark. The CIS recommended configuration is
more secure than the 10gR2 default installation; yet open enough to allow the majority of
applications to be successful. Many customers have adopted this benchmark already. There are
some recommendations of the CIS benchmark that may be incompatible with some applications.

Password Configuration
By default:
• Default password profile is enabled
• Account is locked after 10 failed login attempts
In upgrade:
• Passwords are case insensitive until changed
• Passwords become case sensitive by ALTER USER
On creation:
• Passwords are case sensitive
Secure Default Configuration

When creating a custom database using the Database Configuration Assistant (DBCA), you can
specify the Oracle Database 11g default security configuration. By default, If a user tries to log
into an Oracle Database multiple times using an incorrect password, Oracle Database
delays each login after the third try. This protection applies for attempts made from
different IP addresses or multiple client connections. Afterwards, it gradually increases
the time before the user can try another password, up to a maximum of about ten
seconds.
The default password profile is enabled with the settings:
PASSWORD_LIFE_TIME 180
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME 1
PASSWORD_VERIFY_FUNCTION NULL
When an Oracle Database 10g is upgraded, passwords are case insensitive until the ALTER
USER… command is used to change the password.
When the database is created, the passwords will case sensitive by default.

Enable Built-in Password Complexity Checker
Execute the utlpwdmg.sql script to create the password

verify function:
SQL> CONNECT / as SYSDBA

SQL> @?/rdbms/admin/utlpwdmg.sql
Alter the default profile:
ALTER PROFILE DEFAULT

LIMIT
PASSWORD_VERIFY_FUNCTION verify_function_11g;
Enable Built-in Password Complexity Checker

The verify_function_11g is a sample PL/SQL function that can be easily modified to
enforce the password complexity policies at your site. This function does not require special
characters to be embedded in the password. Both the verify_function_11g and the older
verify_function are included in the utlpwdmg.sql file.
To enable the password complexity checking, create a verification function owned by SYS. Use
on of the supplied functions or modify one of them to meet your requirements. The example show
using the utlpwdmg.sql script. With no modification, the script creates the
verify_function_11g.
The verify_function11g function checks that the password: contains at least 8 characters,
contains at least one number and one alphabetic character, and differs from the previous password
by at least 3 characters. The function also checks that the password is not: a username or
username appended with an number 1 to 100, a username reversed, a server name or server name
appended with 1-100, or one of a set of well know and common passwords such as 'welcome1',
'database1', 'oracle123', or oracle(appended with 1-100), etc

Managing Default Audits
Review Audit logs:

• Default audit options cover important security
privileges
Archive Audit records
• Export
• Copy to another table
Remove archived audit records

Review the audit logs. By default, auditing is enabled in Oracle Database 11g for certain
privileges that are very important to security. The audit trail is recorded in the database AUD$
table by default; the AUDIT_TRAIL parameter is set to DB. These audits should not have a large
impact on database performance, for most sites.
Archive audit records. To retain audit records export using Datapump export, or use the
SELECT statement to capture a set of audit records into a separate table.
Remove archived audit records. Remove audit records from the SYS.AUD$ table after review
and archive. Audit records take up space in the SYSTEM tablespace. If the SYSTEM tablespace
cannot grow, and there is not more space for audit records errors will be generated for each
audited statement. Since CREATE SESSION is one of the audited privileges, no new sessions
may be created.
Note: the system tablespace is created with the autoextend on option. So the SYSTEM
tablespace will grow as needed until there is no more space available on the disk.

The following privileges are audited for all users on success and failure, and by access:
CREATE EXTERNAL JOB
CREATE ANY JOB
GRANT ANY OBJECT PRIVILEGE
EXEMPT ACCESS POLICY
CREATE ANY LIBRARY
GRANT ANY PRIVILEGE
DROP PROFILE
ALTER PROFILE
DROP ANY PROCEDURE
ALTER ANY PROCEDURE
CREATE ANY PROCEDURE
ALTER DATABASE
GRANT ANY ROLE
CREATE PUBLIC DATABASE LINK
DROP ANY TABLE
ALTER ANY TABLE
CREATE ANY TABLE
DROP USER
ALTER USER
CREATE USER
CREATE SESSION
AUDIT SYSTEM
ALTER SYSTEM

Adjust Security Settings
Need Beta 5 Screenshot
Adjust Security Settings

When you create a database using the DBCA tool, you are offered a choice of security settings:
• Keep the enhanced 11g default security settings (recommended). These settings include
enabling auditing and new default password profile.
• Revert to pre-11g default security settings. To disable a particular category of enhanced
settings for compatibility purposes choose from the following:
- Revert audit settings to pre-11g defaults
- Revert password profile settings to pre-11g defaults.
These settings can also be changed after the database is created using DBCA.
Secure permissions on software are always set. It is not impacted by user’s choice for ‘Security
Settings’ option.

Setting Security Parameters
Restrict release of server information

• SEC_RETURN_SERVER_RELEASE
Protect against DoS attacks
• SEC_PROTOCOL_ERROR_FURTHER_ACTION
• SEC_PROTOCOL_ERROR_TRACE_ACTION
Protect against old protocols attacks
• SEC_DISABLE_OLDER_ORACLE_RPCS
Protect against brute force attacks
• SEC_MAX_FAILED_LOGIN_ATTEMPTS
Setting Security Parameters

A set of new parameters have been added to the Oracle Database 11g to enhance the default
security of the database. These parameters are system wide and static.
Restrict release of server information
A new parameter SEC_RETURN_SERVER_RELEASE reduces the amount of information about
the server that is available to the client. When set to true the full banner is displayed. When the
value is set to FALSE, a limited generic banner is displayed. (doesn’t work yet in 11.1.0.4 beta)
Protect against denial of Service (DoS) attacks
The two parameters shown specify the actions to be taken when the database receives bad packets
from a client. The assumption is that the bad packets are from a possible malicious client. The
SEC_PROTOCOL_ERROR_FURTHER_ACTION parameter specifies what action is to be taken
with the client connection: Continue, drop the connection, or delay accepting requests. The other
parameter SEC_PROTOCOL_ERROR_TRACE_ACTION specifies a monitoring action: NONE,
TRACE, LOG, or ALERT.
Protect against old protocols attacks
Older protocols that are not as secure are a vector for attacks. If these older protocols are being
used by applications in your database disable these protocols with the
SEC_DISABLE_OLDER_ORACLE_RPCS parameter set to TRUE.
Protect against brute force attacks
A new initialization parameter SEC_MAX_FAILED_LOGIN_ATTEMPTS that has a default
setting ofOracle Database
10 causes 11g:
a connection New
to be Featuresdropped
automatically for Administrators
after the specified14 - 10 of
number
attempts. This parameter is enforced even when the password profile is not enabled.
Setting Database Administrator Authentication
Use password file with case sensitive passwords

Enable Strong authentication for administrator roles
• Grant Administrator ROLE in the Directory
• Use Kerberos tickets
• Use Certificates with SSL
Setting Database Administrator Authentication

The database administrator must always be authenticated. In Oracle Database 11g there are a new
methods make administrator authentication more secure and centralize the administration of these
privileged users
Use case sensitive passwords with a password file for remote connections.
orapwd file=orapworcl entries=5 ignorecase=N
If your concern is that the password file might be vulnerable or that the maintenance of many
password files is a burden, then strong authentication can be implemented:
• Grant OSDBA, or OSOPER roles in the Oracle Internet Directory.
• Use Kerberos tickets
• Use certificates over SSL
To use any of the strong authentication methods the LDAP_DIRECTORY_SYSAUTH
initialization parameter must be set to YES. Set this parameter to NO to disable the use of strong
authentication methods.
Authentication through Oracle Internet Directory or through Kerberos also can provide
centralized administration or single sign-on.
If the password file is configured, it will be checked first. The user may also be authenticated by
the local OS by being a member of the OSDBA or OSOPER groups.

Setup Directory Authentication
for Administrative Users
1. Create the user in the directory

2. Grant SYSDBA or SYSOPER role to user
3. Set LDAP_DIRECTORY_SYSAUTH parameter in database
4. Check LDAP_DIRECTORY_ACCESS parameter is set to
PASSWORD or SSL.
5. Test the connection
$sqlplus fred/t%3eEGQ@orcl AS SYSDBA
Setup Directory Authentication for Administrative Users

To enable the Oracle Internet Directory (OID) server to authorize SYSDBA and SYSOPER
connections:
1. Configure the administrative user by using the same procedures you would use to configure a
typical user.
2. In OID, grant SYSDBA or SYSOPER to the user for the database the user will administer.
3. Set the LDAP_DIRECTORY_SYSAUTH initialization parameter to YES. When set to YES, the
LDAP_DIRECTORY_SYSAUTH parameter enables SYSDBA and SYSOPER users to authenticate
to the database, by a strong authentication method.
4. Ensure that the LDAP_DIRECTORY_ACCESS initialization parameter is not set to NONE. The
possible values are PASSWORD or SSL.
5. Afterwards, the administrative user can log in by including the net service name in the
CONNECT statement. For example, for Fred to log on as SYSDBA if the net service name is
orcl:
CONNECT fred/t%3eEGQ@orcl AS SYSDBA
Note: If the database is configured to use a password file for remote authentication, the password
file will be checked first.

Setup Kerberos Authentication
1. Create the user in the Kerberos domain

2. Configure OID for Kerberos authentication
3. Grant SYSDBA or SYSOPER role to user in OID
5. Set LDAP_DIRECTORY_ACCESS parameter
$sqlplus /@orcl AS SYSDBA
Setup Kerberos Authentication for Administrative Users

To enable Kerberos to authorize SYSDBA and SYSOPER connections:
1. Configure the administrative user by using the same procedures you would use to configure a
typical user. For more information on configuring Kerberos authentication, see the Oracle
Database Advanced Security Administrator’s Guide 11g.
2. Configure OID for Kerberos authentication. See Oracle Database Enterprise User
Administrator's Guide 11g Release 1
5. Ensure that the LDAP_DIRECTORY_ACCESS initialization parameter is not set to NONE. This
will be set to either PASSWORD or SSL
CONNECT statement. For example, to log on as SYSDBA if the net service name is orcl:
CONNECT /@orcl AS SYSDBA

Setup SSL Authentication
1. Configure client to use SSL

2. Configure server to use SSL
3. Configure OID for SSL user authentication
4. Grant SYSOPER or SYSDDBA to the user
$sqlplus /@orcl AS SYSDBA
Setup SSL Authentication for Administrative Users

To enable SYSDBA and SYSOPER connections using certificates and SSL (for more information
on configuring SSL authentication see the Oracle Database Advanced Security Administrator’s
Guide 11g.) :
1. Configure the client to use SSL
• Setup client wallet and user certificate. Update wallet location in sqlnet.ora.
• Configure Oracle net service name to include server distinguished names and use TCP/IP
with SSL in tnsnames.ora.
• Configure TCP/IP with SSL in listener.ora.
• Set the client SSL cipher suites and required SSL version, set SSL as an authentication
service in sqlnet.ora.
2. Configure the server to use SSL:
• Enable SSL for your database listener on TCPS and provide a corresponding TNS name.
• Stored your database PKI credentials in the database wallet.
• Set the LDAP_DIRECTORY_ACCESS initialization parameter to SSL
3. Configure OID for SSL user authentication. See Oracle Database Enterprise User
Administrator's Guide 11g Release 1.
CONNECT statement. For example, to log on as SYSDBA if the net service name is orcl:
Transparent Data Encryption
Support for Log Miner

Support for Logical Standby
Tablespace Encryption
Hardware based Master key protection
Transparent Data Encryption

Several new features enhance the capabilities of Transparent Data Encryption, and build on the
same infrastructure.

TDE and Log Miner
Log Miner supports Transparent Data Encryption

encrypted columns.
Restrictions:
• The wallet holding the TDE master keys must be open
• Hardware Security Modules are not supported
• User Held Keys are not supported
TDE and Log Miner

With Transparent Data Encryption (TDE), the encrypted column data is encrypted in the data
files, the undo segments and the redo logs. Oracle Logical Standby depends on the log miner
ability to transform redo logs into SQL statements for SQL Apply. Log Miner has been enhanced
to support TDE. This enhancement provides the ability to support TDE on a logical standby
database.
The wallet containing the master keys for TDE must be open for Log Miner to decrypt the
encrypted columns. The database instance must be mounted to open the wallet, therefore Log
Miner cannot populate V$LOGMNR_CONTENTS to support TDE if the database instance is not
mounted..
Log Miner populates V$LOGMNR_CONTENTS for tables with encrypted columns, displaying the
column data unencrypted for rows involved in DML statements. Note that this is not a security
violation: TDE is a file-level encryption feature and not an access control feature. It does not
prohibit DBAs from looking at encrypted data.
At Oracle Database 11g, Log Miner does not support TDE with hardware support module (HSM)
for key storage. User held keys for TDE are PKI public and private keys supplied by the user for
TDE master keys. User held keys are not supported by Log Miner.

TDE and Logical Standby
Logical Standby database with TDE:

• Wallet on the standby is a copy of the wallet on the
primary
• Master key may be changed only on the primary
• Wallet open and close commands are not replicated
• Table key may be changed on the standby
• Table encryption algorithm may be changed on the
standby
TDE and Logical Standby

The same wallet is required for both databases. The wallet must be copied from the primary
database to the standby database every time the master key has been changed using the "alter
system set encryption key identified by <wallet_password>“. An error
is raised if the DBA attempts to change the master key on the standby database.
If auto-login wallet is not used. The wallet must opened on the standby. Wallet open and close
commands are not replicated on standby. A different password can be used to open the wallet on
the standby. The wallet owner can change the password to be used for the copy of the wallet on
the standby.
The DBA will have the ability to change the encryption key or the encryption algorithm of a
replicated table at the logical standby This does not require a change to the master key or wallet..
This operation is performed with:
ALTER TABLE table_name REKEY USING '3DES168';
There can be only one algorithm per table. Changing the algorithm at the table changes the
algorithm for all the columns. A column on the standby can have a different algorithm than the
primary or no encryption. To change the table key the guard setting must be lowered to NONE.
TDE can be used on local tables in the logical standby independently of the primary, if encrypted
columns are not replicated into the standby.

Using Tablespace Encryption
Create an encrypted tablespace

1. Create or open the encryption wallet
SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY

"welcome1";
2. Create a tablespace with the encryption keywords
SQL> CREATE TABLESPACE encrypt_ts

2> DATAFILE '$ORACLE_HOME/dbs/encrypt.dat' SIZE 100M
3> ENCRYPTION USING '3DES168'
4> DEFAULT STORAGE (ENCRYPT);
Tablespace Encryption
Tablespace encryption is based on block level encryption that encrypts on write and decrypts on
read. The data is not encrypted in memory. The only encryption penalty is associated with I/O.
The SQL access paths are unchanged and all data types are supported.
To use tablespace encryption the encryption wallet must be open.
The CREATE TABLESPACE command has an ENCRYPTION clause that sets the encryption
properties, and an ENCRYPT storage parameter that causes the encryption to be used. You specify
USING 'encrypt_algorithm' to indicate the name of the algorithm to be used. Valid
algorithms are 3DES168, AES128, AES192, and AES256. The default is AES128. You can view
the properties in the V$ENCRYPTED_TABLESPACES view.
The encrypted data is protected during operations like JOIN and SORT. This means that the data
is safe when it is moved to temporary tablespaces. Data in undo and redo logs is also protected.
Restrictions:
• Temporary and undo tablespaces cannot be encrypted. (selected blocks are encrypted)
• Bfiles and external tables are not encrypted.
• Transportable tablespaces across different endian platforms is not supported.
• The key for an encrypted tablespaces cannot be changed at this time. A workaround is: create
a tablespace with the desired properties and move all objects to the new tablespace.

Hardware Security Module
Encrypt and decrypt operations

are performed on the Hardware
hardware security module Security
Module
Encrypted Data
Client Database Server
Hardware Security Module

A hardware security module (HSM) is a physical device that provides secure storage for
encryption keys. It also provides secure computational space (memory) to perform encryption and
decryption operations. HSM is a more secure alternative to the Oracle wallet.
Transparent data encryption can use HSM to provide enhanced security for sensitive data. An
HSM is used to store the master encryption key used for transparent data encryption. The key is
secure from unauthorized access attempts as the HSM is a physical device and not an operating
system file. All encryption and decryption operations that use the master encryption key are
performed inside the HSM. This means that the master encryption key is never exposed in
insecure memory.
There are several vendors that provide Hardware Security Modules. The vendor must supply the
appropriate libraries.

Using a Hardware Security Module
with TDE
1. Decrypt encrypted data before switching to HSM

2. Configure sqlnet.ora
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM))
3. Copy the PKCS#11 library to the correct path

4. Set up the HSM
5. Generate a master encryption key for HSM-based
encryption
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY
user_Id:password
6. Ensure that the HSM Is accessible
Beta Only
Using HSM involves an initial setup of the HSM device. You also need to configure transparent
data encryption to use HSM. Once the initial setup is done, HSM can be used just like an
Oracle software wallet. The following steps discuss configuring and using hardware security
modules:
• Decrypt Encrypted Data Before Switching to HSM
• Set the ENCRYPTION_WALLET_LOCATION Parameter in sqlnet.ora
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM))
• Copy the PKCS#11 Library to It's Correct Path
• Set Up the HSM
• Generate a Master Encryption Key for HSM-Based Encryption
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY user_Id:password
• Ensure that the HSM Is Accessible

Encryption for LOB Columns
CREATE TABLE test1 (doc CLOB

ENCRYPT USING 'AES128')
LOB(doc) STORE AS SECUREFILE
(CACHE NOLOGGING );
• LOB encryption is allowed only for SECUREFILE LOBS

• All LOBs in the LOB column are encrypted
• LOBs can be encrypted on per-column or per-partition
basis
– Allows for the co-existence of SECUREFILE and
BASICFILE LOBs
Encryption for LOB Columns

Oracle Database 11g introduces a completely reengineered large object (LOB) data type that
dramatically improves performance, manageability, and ease of application development. This
SecureFiles implementation (of LOBs) offers advanced, next-generation functionality such as
intelligent compression and transparent encryption. The encrypted data in SecureFiles is stored in-
place and is available for random reads and writes.
You must create the LOB with the SECUREFILE parameter, with encryption enabled(ENCRYPT)
or disabled(DECRYPT—the default) on the LOB column. The current TDE syntax is used for
extending encryption to LOB data types.
LOB implementation from prior versions is still supported for backward compatibility and is now
referred to as BasicFiles. If you add a LOB column to a table, you can specify whether it should
be created as SecureFiles or BasicFiles. The default LOB type is BasicFiles to ensure backward
compatibility.
Valid algorithms are 3DES168, AES128, AES192, and AES256. The default is AES192.
Note: For further discussion on SecureFiles, please see the “ Managing Storage” lesson.

Using Kerberos Enhancements
• Use stronger encryption algorithms (no action

required)
• Interoperability between MS KDC and MIT KDC (no
Action required)
• Longer principal name
CREATE USER KRBUSER IDENTIFIED EXTERNALLY AS

'KerberosUser@SOMEORGANIZATION.COM';
Kerberos Enhancements
The Oracle client Kerberos implementation now makes use of secure encryption algorithms like
3DES and AES in place of DES. This makes using Kerberos more secure. The Kerberos
authentication mechanism in Oracle Database now supports the following encryption types:
• DES3-CBC-SHA (DES3 algorithm in CBC mode with HMAC-SHA1 as checksum)
• RC4-HMAC (RC4 algorithm with HMAC-MD5 as checksum)
• AES128-CTS (AES algorithm with 128-bit key in CTS mode with HMAC-SHA1 as
checksum)
• AES256-CTS (AES algorithm with 256-bit key in CTS mode with HMAC-SHA1 as
checksum)
The Kerberos implementation has been enhanced to interoperate smoothly with Microsoft and
MIT Key Distribution Centers.
The Kerberos principal name can now contain more than 30 characters. It is no longer restricted
by the number of characters allowed in a database user name. If the Kerberos principal name is
longer than 30 characters use:
CREATE USER KRBUSER IDENTIFIED EXTERNALLY AS
'KerberosUser@SOMEORGANIZATION.COM';

Managing TDE with
Enterprise Manager
Managing TDE with Enterprise Manager

The administrator using Enterprise Manager can open and close the wallet, move the location of
the wallet and generate a new master key.
The example shows that TDE options are part of the Create or Edit Table processes. Table
encryption options allow you to choose the encryption algorithm and salt.
The table key can also be reset.
The other place where TDE changed the management pages is Export and Import Data. If TDE is
configured, the wallet is open, and the table to exported has encrypted columns, the export wizard
will offer data encryption. The same arbitrary key(password) that was used on export must be
provided both on import in order to import any encrypted columns. A partial import that does not
include tables that contain encrypted columns does not require the password.

Managing Tablespace Encryption
with Enterprise Manager
Managing Tablespace Encryption with Enterprise Manager

You can manage tablespace encryption from the same console as you manage Transparent
Database Encryption. Once encryption has been enabled for the database, the DBA can set the
encryption property of a tablespace on the Edit Tablespace page or create

Managing Virtual Private Database
Managing Virtual Private Database

With Enterprise Manager 11g you can now manage the Virtual Private Database policies from the
console. You can enable, disable, add, and drop polices. The console also allows you to manage
application contexts. The application context page is not shown.

Managing Label Security
Managing Label Security with Database Control

Oracle Label Security (OLS) Management is integrated with Enterprise Manager Database
Control. The Database Administrator can manage OLS from the same console that is used for
managing the database instances, listeners and host. The differences between database control and
grid control are minimal.
Oracle Label Security (OLS) Management is integrated with Enterprise Manager Grid control.
The Database Administrator can manage OLS from the same console that is used for managing
the database instances, listeners and other targets.

with Oracle Internet Directory
Need beta 5 screen shot
Label Security with OID

Oracle Label Security policies can now be created and stored in the Oracle Internet Directory
using Enterprise Manager, then propagated to one or more databases. A database will subscribe to
a policy making the policy available to the database, and the policy can be applied to tables and
schemas in the database.
Label authorizations can be assigned to enterpriser users in the form of profiles.

Managing Enterprise Users
Enterprise Users / Enterprise Manager

The functionality of the Enterprise Security Manager has been integrated into Enterprise Manager.
Enterpriser manager allows you to create and configure enterprise domains, enterprise roles, user
schema mappings and proxy permissions. Databases can be configured for enterprise user security
after they have been registered with OID. The registration is performed through the DBCA tool.
Enterprise Users and groups can also be configured for enterprise user security. The creation of
enterprise users and groups can be done through Delegated Administration Service (DAS).
Administrators for the database can be created and given the appropriate roles in OID through
Enterprise Manager.
Enterpriser manager allows you to manage enterprise users and roles, schema mappings, domain
mappings, and proxy users.

Enterprise Manager Security Management
Enterprise Manager Security Management

Security management has been integrated into Enterprise Manager. Oracle Label Security,
Application Contexts, and Virtual Private Database previous administered through Oracle Policy
Manager tool are managed through the Enterprise Manager. Enterprise User Security is also now
managed though Enterprise Manager instead of a separate tool. A graphical interface for
managing Transparent Data Encryption has been added.

Enterprise Manager
Policy Manager
Screen shot of policy manager
Need Beta5
Screenshot
Enterprise Manager Policy Manager

Enterprise Manager Policy manager allows you to compare your database configuration against a
set of Oracle best practices. The Oracle best practices are in line with CIS and PCI requirements
(CHECK before release possible better wording). For reviewers: Can the recommendations that
are being used as a baseline be changed to match PCI or CIS recommendations?

with Oracle Internet Directory
Label Security with OID

Oracle Label Security policies can now be created and stored in the Oracle Internet Directory,
then applied to one or more databases. A database will subscribe to a policy making the policy
available to the database, and the policy can be applied to tables and schemas in the database.
Label authorizations can be assigned to enterpriser users in the form of profiles.

Managing Enterprise Users
Enterprise Users / Enterprise Manager

The functionality of the Enterprise Security Manager has been integrated into Enterpriser
Manager. Enterprise Users can be created and configured. Databases can be configured for
enterprise user security after they have been registered with OID. The registration is performed
through the DBCA tool.
Administrators for the database can be created and given the appropriate roles in OID through
Enterprise Manager.
Enterpriser manager allows you to manage enterprise users and roles, schema mappings, domain
mappings, and proxy users.

Oracle Audit Vault Enhancements
Harden Streams (configuration?)

DML/DDL capture on SYS schema
** Capture actions against SYS, SYSTEM, and CTXSYS
schema *** maybe TMI ***
Capture changes to SYS.AUD$ and SYS.FGA_LOG$
Oracle Audit Vault Enhancements

Oracle Audit Vault provides auditing in a heterogeneous environment. Audit Vault consists of a
secure database to store and analyze audit information from various sources such as databases, OS
audit trails etc.
Oracle Streams is an asynchronous information sharing infrastructure that facilitates sharing of
events within a database or from one database to another. Events could be DML or DDL changes
happening in a database. These events are captured by Streams implicit capture and are
propagated to a queue in a remote database where they are consumed by a subscriber which is
typically the Streams apply process.
Oracle Streams can already capture all DML on participating tables and all DDL to the database.
Streams is enhanced to capture the events that change the database audit trail, forwarding that
information to Audit Vault.
Harden the transfer and collect configuration. The configuration of audit vault is driven entirely
from the Audit Vault instance. Audit sources will require only an initial configuration to enable.
(Is this what is intended? JLS interpretation of FS)

Using RMAN Enhancements
Configure Backup Shredding

CONFIGURE ENCRYPTION EXTERNAL KEY STORAGE ON;
• Create and use Virtual Private Catalog
RMAN Security Enhancements

Backup shredding is a key management feature, that allows the DBA to delete the encryption key
of transparent encrypted backups, without physical access to the backup media. The encrypted
backups are rendered in accessible if the encryption key is destroyed. This does not apply to
password protected backups.
Configure Backup Shredding with:
CONFIGURE ENCRYPTION EXTERNAL KEY STORAGE ON;
Or
SET ENCRYPTION EXTERNAL KEY STORAGE ON;
The default setting is OFF, and backup shredding is not enabled. To shred a backup no new
command is needed, use:
DELETE FORCE;
Virtual Private Catalog. The RMAN catalog has been enhanced create virtual private RMAN
catalogs for groups of databases and users. The catalog owner creates the base catalog, and grants
RECOVERY_CATALOG_OWNER to the owner of the virtual catalog. The catalog owner can
either grant access to registered database to the virtual catalog owner or grant REGISTER to the
virtual catalog owner. The virtual catalog owner can then connect to the catalog for a particular
target or register a target database. Once the virtual private catalog is configured the virtual
private catalog owner uses it just like a standard base catalog.
This feature allows a consolidation of RMAN repositories and maintains a separation of
responsibilities.
The catalog ownerDatabase
Oracle can access all
11g:the New
registered databasefor
Features information in the catalog.
Administrators 14 -The
34 catalog
owner can see a listing of all databases registered with the SQL*Plus command:
SELECT DISTINCT db_name FROM DBINC;
Using RMAN Virtual Private Catalog
1. Create an RMAN base catalog

RMAN> CONNECT CATALOG catowner/oracle@catdb;
RMAN> CREATE CATALOG;
2. Grant RECOVERY_CATALOG_OWNER to VPC owner
SQL> CONNECT SYS/oracle@catdb AS SYSDBA
SQL> GRANT RECOVERY_CATALOG_OWNER to vpcowner
3. Grant REGISTER to the VPC owner or

RMAN> CONNECT CATALOG catowner/oracle@catdb;
RAMN> GRANT REGISTER DATABASE TO vpcowner;
Grant CATALOG FOR DATABASE to the VPC owner

RMAN>GRANT CATALOG FOR DATABASE db10g TO vpcowner
Using RMAN Virtual Private Catalog

The RMAN catalog has been enhanced. You create virtual private RMAN catalogs for groups of
databases and users.
1. The catalog owner creates the base catalog.
2. The DBA on the catalog database creates the user that will own the virtual private catalog and
grants RECOVERY_CATALOG_OWNER to the owner of the virtual catalog.
3. The catalog owner can grant access for previously registered databases to the virtual catalog
owner or grant REGISTER to the virtual catalog owner. The GRANT CATALOG command
is:
GRANT CATALOG FOR DATABASE prod1, prod2 TO vpcowner;
The GRANT REGISTER command is:
GRANT REGISTER DATABASE TO vpcowner;
The virtual catalog owner can then connect to the catalog for a particular target or register a
target database. Once the virtual private catalog is configured the virtual private catalog owner
uses it just like a standard base catalog.

Using RMAN Virtual Private Catalog (cont)
4. Create a virtual catalog for 11g clients or

RMAN> CONNECT CATALOG vpcowner/oracle@catdb;
RMAN> CREATE VIRTUAL CATALOG;
Create a virtual catalog for pre-11g clients

SQL> CONNECT vpcowner/oracle@catdb
SQL> exec catowner.dbms_rcvcat.create_virtual_catalog;
4. REGISTER a not previously cataloged database

RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catdb;
RAMN> REGISTER DATABASE;
5. Use the virtual catalog

RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catdb;
RAMN> BACKUP DATABASE;
Using RMAN Virtual Private Catalog (cont)

4. Create a virtual private catalog.
• If the target database is an Oracle Database 11g and the RMAN client is an 11g client. You
can use the RMAN command:
CREATE VIRTUAL CATALOG;
• If the target database is Oracle Database 10g Release 2 or earlier, using a compatible client.
You must execute the supplied procedure from SQL*Plus:
base_catalog_owner.dbms_rcvcat.create_virtual_catalog;
5. Connect to the catalog using the VPC owner login, and use it as a normal catalog.
This feature allows a consolidation of RMAN repositories and maintains a separation of
responsibilities. The catalog owner can access all the registered database information in the
catalog. The catalog owner can see a listing of all databases registered with the SQL*Plus
command:
SELECT DISTINCT db_name FROM DBINC;
The virtual catalog owner can only see the databases that have been granted. If the catalog owner
has not been granted SYSDBA or SYSOPER on the target database, then most RMAN operations
cannot be performed by catalog owner.

Managing Fine-Grained Access to External
Network Services
1. Create an ACL and its privileges
BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
acl => 'us-oracle-com-permissions.xml',
description => ‘Permissions for oracle network',
principal => ‘SCOTT',
is_grant => TRUE,
privilege => 'connect');
END;
Managing Fine-Grained Access to External Network Services

The network utility family of PL/SQL packages such as UTL_TCP, UTL_INADDR, UTL_HTTP,
UTL_SMTP, and UTL_MAIL allow Oracle users to make network callouts from the database
using raw TCP or using higher level protocols built on raw TCP. A user either did or did not have
EXECUTE privilege on these packages and there was no control over which network hosts were
accessed. The new package DBMS_NETWORK_ACL_ADMIN allows fine-grained control using
access control lists (ACL) implemented by XML DB.
The first step is to create an access control list (ACL). The ACL is a list of users and privileges
held in an XML file. The XML document named in the acl parameter is relative to the
/sys/acl/ folder in the XML DB. In the example, SCOTT is granted connect. The username
is case sensitive in the ACL and must match the username of the session. There are only
resolve and connect privileges. The connect privilege implies resolve. Optional
parameters can specify a start and end timestamp for these privileges. To add more users and
privileges to this ACL use the ADD_PRIVILEGE procedure.

Managing Fine-Grained Access to External
Network Services
2. Assign an ACL to one or more network hosts
BEGIN
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
acl => ‘us-oracle-com-permissions.xml',
host => ‘*.us.oracle.com',
lower_port => 80,
upper_port => null);
END
Managing Fine-Grained Access to External Network Services

Assign an ACL to one or more network hosts. The ASSIGN_ACL procedure associates the
ACL with a network host and optionally a port or range of ports. In the example, the host
parameter allows wild card character for the host name to assign the ACL to all the hosts of a
domain. The use of wild cards affect the order of precedence for the evaluation of the ACL. Fully
qualified host names with ports are evaluated before hosts with ports. Fully qualified host names
are evaluated before partial domain names, and sub-domains are evaluated before the top level
domain level.
Multiple hosts can be assigned to the same ACL and multiple users can be added to the same ACL
in any order after the ACL has been created.

Summary

• Configure the password file to use case sensitive
passwords
• Encrypt a tablespace
• Create a virtual private catalog for RMAN
• Configure fined grained access to network services
Summary
A summary list appears at the end of each course, unit, module, and lesson. You can format the
summary slide in two ways. For example, you can summarize the lesson or unit in a short
paragraph, or you can simply restate the objectives. Whichever format you choose, use it
consistently for every lesson and unit in your course.
If you decide to simply restate the objectives, try not to repeat them verbatim. Use the following
guidelines for the bulleted list:
• Begin the summary list with this introduction: “In this lesson, you should have learned how
to:”
• Under this introduction, create list items that are sentence fragments beginning with
imperative (action) verbs. Do not use end punctuation.
• If the summary covers only one topic, incorporate that topic in the “In this lesson…”
sentence. Do not create a one-bullet list. For example:
In this lesson, you should have learned how to define a parameter. (Note the end
punctuation.)
not
- Define a parameter

11g New Features For Administrators Student Guide-11 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

11g New Features For Administrators Student Guide-11 PDF

Uploaded by

Copyright:

Available Formats

Example of Repairing a Failure (continued)

Starting recover at 21-DEC-06

starting media recovery

archived log for thread 1 with sequence 5 is already on disk as file

sql statement: alter database datafile 5 online

Oracle Database 11g: New Features for Administrators 13 - 19

13 - 20 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 13 - 20

13 - 21 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 13 - 21

Querying dynamic data dictionary views:

13 - 22 Copyright © 2007, Oracle. All rights reserved.

Data Recovery Advisor Views

Oracle Database 11g: New Features for Administrators 13 - 22

Invoking proactive health check of the database and its

13 - 23 Copyright © 2007, Oracle. All rights reserved.

Best Practice: Proactive Checks

Oracle Database 11g: New Features for Administrators 13 - 23

Starting validate at 21-DEC-06

Oracle Database 11g: New Features for Administrators 13 - 24

Oracle Database 11g: New Features for Administrators 13 - 25

Setting Corruption-Detection Parameters

EM > Server > Initialization Parameters

13 - 26 Copyright © 2007, Oracle. All rights reserved.

Setting Corruption-Detection Parameters

Oracle Database 11g: New Features for Administrators 13 - 26

DB_ULTRA_SAFE OFF DATA_ONLY DATA_AND_INDEX

DB_BLOCK_CHECKING OFF or MEDIUM FULL or TRUE

DB_BLOCK_CHECKSUM TYPICAL FULL FULL

DB_LOST_WRITE_PROTECT TYPICAL TYPICAL TYPICAL

13 - 27 Copyright © 2007, Oracle. All rights reserved.

Setting Corruption-Detection Parameters (continued)

Oracle Database 11g: New Features for Administrators 13 - 27

In this lesson, you should have learned how to:

13 - 28 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 13 - 28

This practice covers the following topics:

13 - 29 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 13 - 29

Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 14 - 1

After completing this lesson, you should be able to:

14 - 2 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 14 - 2

More Secure Password Support. Passwords

14 - 3 Copyright © 2007, Oracle. All rights reserved.

Secure Password Support

Oracle Database 11g: New Features for Administrators 14 - 3

• Default password profile

14 - 4 Copyright © 2007, Oracle. All rights reserved.

Automatic Secure Configuration

Oracle Database 11g: New Features for Administrators 14 - 4

14 - 5 Copyright © 2007, Oracle. All rights reserved.

Secure Default Configuration

Oracle Database 11g: New Features for Administrators 14 - 5

Execute the utlpwdmg.sql script to create the password

SQL> CONNECT / as SYSDBA

Alter the default profile:

ALTER PROFILE DEFAULT

14 - 6 Copyright © 2007, Oracle. All rights reserved.

Enable Built-in Password Complexity Checker

Oracle Database 11g: New Features for Administrators 14 - 6

Review Audit logs: