【11g体系结构，6】参数文件和一些参数

九.静态参数和动态参数：

九.隐藏参数：

SEC_PROTOCOL_ERROR_FURTHER_ACTION specifies the further execution of a server process when receiving bad packets from a possibly malicious client.

Values:

• CONTINUE

  The server process continues execution. The database server may be subject to a Denial of Service (DoS) if bad packets continue to be sent by a malicious client.

• (DELAY,integer)

  The client experiences a delay of integer seconds before the server process accepts the next request from the same client connection. Malicious clients are prevented from excessive consumption of server resources while legitimate clients experience a degradation in performance but can continue to function.

• (DROP,integer)

  The server forcefully terminates the client connection after integer cumulative bad packets. The server protects itself at the expense of the client (for example, a client transaction may be lost). The client may reconnect and attempt the same operation.

  
  
  来源： <http://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams227.htm#REFRN10282>
   

Purpose

The purpose of this article is to cover the new parameter DB_ULTRA_SAFE which is a new parameter introduced in 11g.

Through the creation of a new initialization parameter, DB_ULTRA_SAFE={off, data_only, data_and_index}, this capability provides an integrated mechanism to offer protection from various possible data corruptions that may impact Oracle Database. This feature improves the data protection capabilities of Oracle Database by offering an integrated mechanism to control various levels of protection from data corruptions. By making it possible to detect data corruptions in a timely manner, this feature also provides critical high availability benefits for Oracle Database.

New Parameter DB_ULTRA_SAFE introduce In 11g

Set DB_ULTRA_SAFE initialization parameter to automatically configure the appropriate data protection block checking level in the database.
Controls the setting of other related initialization parameters, including DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, and DB_LOST_WRITE_PROTECT.

Different values that can be set for this parameter are

DB_ULTRA_SAFE = { OFF | DATA_ONLY | DATA_AND_INDEX }

By default its OFF.

Description of these values are given below

Values:

+ OFF

When any of DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, or
DB_LOST_WRITE_PROTECT are explicitly set, no changes are made.

+ DATA_ONLY

DB_BLOCK_CHECKING will be set to MEDIUM.

DB_LOST_WRITE_PROTECT will be set to TYPICAL.

DB_BLOCK_CHECKSUM will be set to FULL.

+ DATA_AND_INDEX

DB_BLOCK_CHECKING will be set to FULL.

DB_LOST_WRITE_PROTECT will be set to TYPICAL.

DB_BLOCK_CHECKSUM will be set to FULL.

This parameter cannot be changed dynamically .

For example :

alter system set db_ultra_safe=data_only scope=spfile;

Restart the database for the new change to come into effect

LOG_ARCHIVE_FORMAT is applicable only if you are using the redo log in ARCHIVELOG mode. Use a text string and variables to specify the default filename format when archiving redo log files. The string generated from this format is appended to the string specified in the LOG_ARCHIVE_DEST parameter.

The following variables can be used in the format:

%s log sequence number

%S log sequence number, zero filled

%tthread number

%Tthread number, zero filled

%a activation ID

%d database ID

%r resetlogs ID that ensures unique names are constructed for the archived log files across multiple incarnations of the database

Using uppercase letters for the variables (for example, %S) causes the value to be fixed length and padded to the left with zeros. An example of specifying the archive redo log filename format follows:

LOG_ARCHIVE_FORMAT = ‘log%t_%s_%r.arc‘

Neither LOG_ARCHIVE_DEST nor LOG_ARCHIVE_FORMAT have to be complete file or directory specifiers themselves; they only need to form a valid file path after the variables are substituted into LOG_ARCHIVE_FORMAT and the two parameters are concatenated together.