| « | 三月 2010 | » | ||||
|---|---|---|---|---|---|---|
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
Most structural changes made to a primary database are automatically propagated through redo data to a physical standby database. Table 9-1 lists primary database structural and configuration changes which require manual intervention at a physical standby database.
1. Add a datafile or create a tablespace
No action is required if the STANDBY_FILE_MANAGEMENT database initialization parameter is set to AUTO. If this parameter is set to MANUAL, the new datafile must be copied to the physical standby database.
2.Drop or delete a tablespace or datafile
Delete datafile from primary and physical standby database after the redo data containing the DROP or DELETE command is applied to the physical standby.
3.
Use transportable tablespaces
Move tablespace between the primary and the physical standby database.
4. Rename a datafile
Rename the datafile on the physical standby database.
5. Add or drop a redo log file group
Evaluate the configuration of the redo log and standby redo log on the physical standby database and adjust as necessary.
6.Perform a DML or DDL operation using the NOLOGGING or UNRECOVERABLE clause
Copy the datafile containing the unlogged changes to the physical standby database.
7.Grant or revoke administrative privileges or change the password of a user who has administrative privileges
If the REMOTE_LOGIN_PASSWORDFILE initialization parameter is set to SHARED or EXCLUSIVE, replace the password file on the physical standby database with a fresh copy of the password file from the primary database.
8.Reset the TDE master encryption key
Replace the database encryption wallet on the physical standby database with a fresh copy of the database encryption wallet from the primary database.
9.Change initialization parameters
Evaluate whether a corresponding change must be made to the initialization parameters on the physical standby database.
1 概述
对于ORACLE数据库的联机数据,ORACLE主要采用用户验证、访问控制和审计等技术,提供了多个层次的数据安全保护措施,而且随着数据库版本的更新,这些技术在不断的完善,总体上而言,ORACLE数据库是安全性方面最完备的数据库产品。 然而,对于数据库数据文件中的数据和各种数据备份的安全性一直是一个薄弱的环节,窃密者完全可以绕过数据库的安全防护层,不用访问产品数据库,而直接获取数据库文件、数据库逻辑备份或物理备份,利用ORACLE 的技术支持工具如dul/aul可以恢复脱机文件中的数据,或利用ORACLE的恢复技术,使用备份可在另外的计算机上恢复整个数据库。例如,下面列出了一些容易被窃取的文件。
1.1 数据库的热备份或冷备份。数据库备份是产品库的拷贝,一方面使用这些备份和日志文件可以很容易的恢复数据库;另一方面使用ORACLE 的技术支持工具如dul/aul可以恢复脱机文件中的数据。
1.2 ORACLE 导出工具的导出文件。应用该文件能够容易的在数据库之间迁移数据,窃密者可以在自己的数据库中导入这些文件中包含的数据,而且,全库导出包含所有的账户和密码,利用这些帐户和密码可以随意的访问产品库。
1.3 ORACLE联机和归档日志。可以用LOGMINER看到redo logs中存储的数据库的变化,因此也应当保护好日志文件。
查看全文
摘要 当用resetlogs选项打开ORACLE数据库的时,要重置联机日志文件序号,产生一个新的数据库形态((incarnation),本文着中介绍在各种oracle数据库版本下,如何利用resetlogs点之前的备份进行数据库恢复操作。
查看全文
摘要:在日常的oracle数据库管理中,经常有同行问到oracle数据库逻辑损坏的恢复问题,而这类问题oracle文档没有提供解决方法。本文针对该问题探讨了在oracle数据库不同版本下的恢复方法,主要方法有数据库时间点恢复、日志挖掘技术、数据库闪回技术。
查看全文
摘要 随着数据库的持续运行,数据库的大小不断扩大,要求不断增大系统的存储容量,对于普通的文件系统,增加存储的过程非常复杂。Oracle
本文详细论述了oracle数据库升级的升级前的准备、升级过程和升级后的测试与调整工作,并对各种升级方法在多种操作系统平台上作了测试。
查看全文
1 概述
许多信息中心一般运行多个数据库系统,这些数据库系统所用数据库种类,数据库版本和操作系统平台也都不完全相同,这样就对不同系统间的数据交换提出了挑战;另一方面,对于长期运行的系统需要定期把过期数据转移到历史服务器或是数据仓库中,进行历史查询,报表以及数据挖掘等处理。这些数据交换,或是在不同种类数据库之间异构数据传输,比如sqlserver与oracle之间;或是在同种数据库的不同版本之间,如各种版本的oracle数据库之间;还有可能是数据库同种,但数据库运行的操作系统平台不同。后两种都属于同构数据传输。本文主要探讨不同版本,不同操作系统平台下的oracle数据库之间同构数据传输的工具和方法。
查看全文
Using Views to Monitor Primary, Physical, and Snapshot Standby Databases
1.V$DATABASE
The following query displays the data protection mode, data protection level, database role, and switchover status for a primary, physical standby or snapshot standby database:
SELECT PROTECTION_MODE, PROTECTION_LEVEL, –
DATABASE_ROLE ROLE, SWITCHOVER_STATUS –
FROM V$DATABASE;
The following query displays fast-start failover status:
SELECT FS_FAILOVER_STATUS "FSFO STATUS", -
FS_FAILOVER_CURRENT_TARGET TARGET, -
FS_FAILOVER_THRESHOLD THRESHOLD, -
FS_FAILOVER_OBSERVER_PRESENT "OBSERVER PRESENT" –
FROM V$DATABASE;
2. V$MANAGED_STANDBY
The following query displays Redo Apply and redo transport status on a physical standby database:
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#,-
BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
------- ------------ ---------- ---------- ---------- ----------
RFS ATTACHED 1 947 72 72
MRP0 APPLYING_LOG 1 946 10 72
The sample output shows that a RFS process completed archiving a redo log file with a sequence number of 947 and that Redo Apply is actively applying an archived redo log file with a sequence number of 946. Redo Apply is currently recovering block number 10 of the 72-block archived redo log file.
3.V$ARCHIVED_LOG
The following query displays information about archived redo log files that have been received by a physical or snapshot standby database from a primary database:
SQLSELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, -
NEXT_CHANGE# FROM V$ARCHIVED_LOG;
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 945 74651 74739
1 946 74739 74772
1 947 74772 7474
The sample output shows that three archived redo log files have been received from the primary database.
4. V$LOG_HISTORY
The following query displays archived log history information:
SQLSELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, -
NEXT_CHANGE# FROM V$LOG_HISTORY;
5.V$DATAGUARD_STATUS
The following query displays messages generated by Data Guard events that caused a message to be written to the alert log or to a server process trace file:
SQLSELECT MESSAGE FROM V$DATAGUARD_STATUS;
To be fair to the 10046 trace, the v$active_session_history does not catch session activity that is extremely fast, but it should catch activity that causes the most waits and resource consumption and will, therefore, be useful to the DBA. Statistically, the v$active_session_history does catch extremely fast operations if they occur sufficiently often to contribute to user time.
查看全文
转载:http://blogs.ittoolbox.com/database/solutions/archives/control-file-reads-writes-14718
查看全文
cardinality(基数,集的势):表示一个行集的行数。
1. Base cardinality is the number of rows in a base table.
2. Effective cardinality is the number of rows that are selected from a base table.
3. Join cardinality is the number of rows produced when two row sets are joined together.
4. Distinct cardinality is the number of distinct values in a column of a row set.
5. Group cardinality is the number of rows produced from a row set after the GROUP BY operator is applied.
This section contains detailed guidance for evaluating each section of an AWR report. An AWR report is very similar to the STATSPACK report from Oracle9i, and it contains vital elapsed-time information on what happened during particular snapshot range. The data in an AWR or STATSPACK report is the delta, or changes, between the accumulated metrics within each snapshot.
查看全文
oracle10gr2有258个参数,oracle11g有289个参数
来自:http://www.dizwell.com/prod/node/936
查看全文
10.2.0.1 11.1.0.6
Supported Parameters 258 289
Unsupported Parameters 1127 1631
Supported Optimizer Environment Parameters 25 37
Unsupported Optimizer Environment Parameters 184 259
Dynamic Performance (V$) Views 393 481
Fixed (X$) Tables 597 767
Background Processes 157 212
Statistics Levels 16 24
Statistics 363 485
Segment Statistics 15 15
Service Statistics 28 28
PGA Statistics 19 19
Operating System Statistics 9 18
Latches 382 496
Wait Classses 12 13
Wait Events 874 961
Lock Types 155 187
Metric Groups 10 12
Metrics 163 192
Time Model Statistics 19 19
Keywords 1129 1733
Audit Actions 160 173
ORADEBUG DUMPLIST options 146 165
(abstract from juliandyke)
1。表空间加密(Tablespace encryption)加密整个表空间,创建在加密表空间中的所有对象自动加密。
2。表空间加密保护整个表空间中的数据的安全,如:数据文件或数据文件备份若被窃取,没有密钥不可能
查看到其中的数据,这对于保护诸如军用级别的数据、his系统的病人数据等非常重要。
3。表空间加密(Tablespace encryption)使用透明数据加密结构(transparent data encryption architecture )
也就是使用与tde(transparent data encryption )类似的方法。表空间加密的密钥再次由一个称为主密钥的密钥二次加密,
主密钥存储在wallet中。加密后的表空间加密的密钥存储在数据库中的字典表中。
4。对加密数据的操作过程中,加密数据同样受到保护:
(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)
5。不能对已经在使用的表空间进行加密,但是可以通过向加密表空间中利用data pump导入数据,或
使用create table.. as select..或alter table.. move ..把已经存在数据转储到加密表空间。
6。表空间加密的使用:
a。设置主密钥,主密钥存储在wallet中。
修改sqlnet.ora文件,设置ENCRYPTION_WALLET_LOCATION (or WALLET_LOCATION) 参数,例如:
ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=FILE)(METHOD_DATA=
(DIRECTORY=/u01/app/oracle/product/11.1.0/db_1/)))
b。打开wallet
SQL> STARTUP MOUNT;
SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY password;
SQL> ALTER DATABASE OPEN;
(关于wallet的使用可以参考ningoo的Oracle10R2新特性之Transparent Data Encryption )
c。创建加密表空间
语法:
CREATE
[ BIGFILE | SMALLFILE ]
{ permanent_tablespace_clause
| temporary_tablespace_clause
| undo_tablespace_clause
} ;
Where,
permanent_tablespace_clause=
TABLESPACE tablespace
.........
ENCRYPTION [USING algorithm]
.........
storage_clause
.........
Where,
storage_clause=
.........
[ENCRYPT]
.........
storage_clause中的ENCRYPT关键字表示加密表空间。
加密算法包括:其中可以指定加密算法,也可以不指定加密算法,默认使用AES128算法。
3DES168
AES128
AES192
AES256
例:指定加密算法
CREATE TABLESPACE securespace
DATAFILE '/home/user/oradata/secure01.dbf'
SIZE 150M
ENCRYPTION USING '3DES168'
DEFAULT STORAGE(ENCRYPT);
不指定加密算法:
CREATE TABLESPACE securespace2
DATAFILE '/home/user/oradata/secure01.dbf'
SIZE 150M
ENCRYPTION
DEFAULT STORAGE(ENCRYPT);
7。可以从DBA_TABLESPACES或USER_TABLESPACES的ENCRYPTED 列查看表空间是否加密。