Flashback Logging generates an additional 2% of I/O load
All changed blocks will be written to Flashback Logs (Based on Flashback Logs)
As of November 18, 2009: Source: SAP AG, www.sap.com/benchmark
The SAP SD-Parallel Standard Application Benchmark performed on November 26, 2007 by IBM in Beaverton, OR, USA has been certified with the following data: 37,040 SAP SD-Parallel Benchmark users, 1.86 seconds average dialog response time, 3,749,000 fully processed order line items per hour, 11,247,000 dialog steps per hour, 187,450 SAPS. Server configuration: IBM System p 570, 8 processors/16 cores/32 threads, POWER6, 4.7 GHz, 128 KB L1 cache and 4 MB L2 cache per core, 32 MB L3 cache per processor, 128 GM main memory, running AIX 5L version 5.3, Oracle 10g Real Application Clusters and SAP ERP 6.0. Certification Number 2008013.
The SAP SD 2-tier Standard Application Benchmark performed on June 28, 2008 by Sun Microsystems and Fujitsu has been certified with the following data: 39,100 SAP SD Benchmark users, 1.94 seconds average dialog response time, 3,931,330 fully processed order line items per hour, 11,794,000 dialog steps per hour, 196,570 SAPS. Server configuration: SPARC Enterprise Server M9000, 64 processors/256 cores/512 threads, SPARC 64 VII, 2.52 GHZ, 64 KB (D) + 64 KB (1) L1 cache per core, 6 MB L2 cache per processor, 1024 GB main memory, running Solaris 10, Oracle Database 10g and SAP ERP 6.0. Certification Number 2008042.
The SAP BI-D Standard Application Benchmark performed on October 132009 by Fujitsu in Walldorf, Germany has been certified (certification number 2009045) with the following data: Throughput/hour (query navigation steps): 1,165,742. Operating system all servers: SuSE Linux Enterprise Server 10. RDBMS: Oracle 10g Real Application Clusters (RAC). Technology platform release: SAP NetWeaver® 7.0 (non-Unicode). Configuration: 4 servers (4 active nodes): Fujitsu PRIMERGY RX300-S5, 2 processors / 8 cores / 16 threads, Intel Xeon Processor X5570, 2.93 GHz, 64 KB L1 cache and 256 KB L2 cache per core, 8 MB L3 cache per processor, 96 GB main memory.
The Database Replay feature enables users to perform real-world testing by capturing the actual database workload on the production system and replaying it on the test system. The replay on the test system can be done with production characteristics including timing and concurrency. It also provides analysis and reporting to highlight potential problems (for example, errors encountered and divergence in performance) and recommend ways to remedy the problems.
SQL Performance Analyzer can be used to predict and prevent potential performance problems for any database environment change that affects the structure of SQL execution plans. The changes can include any of the following (but not limited to):
Database upgrades
Implementation of tuning recommendations
Schema changes
Statistics gathering
Database parameter changes
OS/ hardware changes
The REMOTE_LOGIN_PASSWORDFILE initialization parameter must have the value SHARED or EXCLUSIVE for all databases in the Data Guard configuration, and the password for SYS should be identical at all sites
Open read/write: A physical standby database can also be opened for read/write access for purposes such as creating a clone database or for read/write reporting. While opened in read/write mode, the standby database does not receive redo data from the primary database and cannot provide disaster protection. The physical standby database can be opened temporarily in read/write mode for development, reporting, or testing purposes, and then flashed back to a point in the past to be reverted back to a physical standby database. When the database is flashed back, Data Guard automatically synchronizes the standby database with the primary database, without the need to re-create the physical standby database from a backup copy of the primary database.
A snapshot standby database is a fully updatable standby database that is created by converting a physical standby database into a snapshot standby database. A snapshot standby database receives and archives, but does not apply, redo data from a primary database. Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.
A snapshot standby database typically diverges from its primary database over time because redo data from the primary database is not applied as it is received. Local updates to the snapshot standby database will cause additional divergence. The data in the primary database is fully protected however, because a snapshot standby can be converted back into a physical standby database at any time, and the redo data received from the primary will then be applied.
A snapshot standby database provides disaster recovery and data protection benefits that are similar to those of a physical standby database. Snapshot standby databases are best used in scenarios where the benefit of having a temporary, updatable snapshot of the primary database justifies additional administrative complexity and increased time to recover from primary database failures.
Converting a Physical Standby Database into a Snapshot Standby Database
Perform the following steps to convert a physical standby database into a snapshot standby database:
1. Stop Redo Apply, if it is active.
2. On an Oracle Real Applications Cluster (RAC) database, shut down all but one instance.
3. Ensure that the database is mounted, but not open.
4. Issue the following SQL statement to perform the conversion: SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
The database is dismounted after conversion and must be restarted.
At the physical level, Oracle Flashback Database provides a more efficient direct alternative to database point-in-time recovery. If you have datafiles which merely have unwanted changes, then you can use Flashback Database to cause your current datafiles revert to their contents at a past time. The end product is much like the result of a point-in-time recovery, but is generally much faster because it does not require restoring datafiles from backup, and requires only limited application of redo compared to media recovery.
Flashback Database uses flashback logs to access past versions of data blocks, as well as some information from the archived redo log. Flashback Database requires that you configure a flash recovery area for your database, because the flashback logs can only be stored there. Flashback logging is not enabled by default. Space used for flashback logs is managed automatically by the database, and balanced against space required
for other files in the flash recovery area.
the administrator may decide to use Flashback Database on both the primary and standby databases to quickly revert the databases to an earlier point-in-time to back out such user errors.
Another benefit that such integration provides is during failovers. In releases prior to 10g, following any failover operation, the old primary database must be recreated (as a new standby database) from a backup of the new primary database, if the administrator intends to bring it back in the Data Guard configuration. This may be an issue when the database sizes are fairly large, and the primary/standby databases are hundreds/thousands of miles away. However, in Data Guard 10g, after the primary server fault is repaired, the primary database may simply be brought up in mounted mode, “flashed back” (using flashback database) to the SCN at which the failover occurred, and then brought back as a standby database in the Data Guard configuration. No reinstantiation is required.
The components that creates different backup and recovery-related files have no knowledge of each other or of the size of the file systems where they store their data. With Automatic Disk-Based Backup and Recovery, you can create a flash recovery area, which automates management of backup-related files. Choose a location on disk and an upper bound for storage space, and set a retention policy that governs how long backup files are needed for recovery, and the database manages the storage used for backups, archived redo logs, and other recovery-related files for your database within that space. Files no longer needed are eligible for deletion when RMAN needs to reclaim space for new files.
Using a flash recovery area minimizes the need to manually manage disk space for your backup-related files and balance the use of space among the different types of files. Oracle recommends that you enable a flash recovery area to simplify your backup management.
If running on top of Oracle, SAP BI installs and uses partitioning by default, which gives customers a huge benefit in terms of manageability, availability, and query performance. SAP ERP supports Oracle Partitioning, but it does not come with a default setup.
The main reason for partitioning not being used by default in ERP systems is the fact that, depending on the modules used, different tables should be partitioned in different systems. To overcome this obstacle, the Oracle for SAP Services and Support team developed a methodology and a set of tools which can be applied to determine the best candidates and the appropriate partitioning strategies. The service offering has been available since 2007, and customers who made use of it found that it resulted in remarkable improvements.
Application DBA: Attributes
An application DBA is a user that is able to perform the typical administration duties for the database objects related only to a specific application, or functional area, of the database. An example is a sales DBA, who is responsible for all the sales data. There may be other type of data in the database, such as HR data, but the sales DBA is responsible only for the sales data.
The sales DBA:
Can view the schema definitions of the protected objects
Can modify definitions of protected objects, including performing these commands, among others:
ALTER TABLE
ALTER TABLESPACE
CREATE INDEX
Cannot view data in application tables
Cannot make a copy of application tables
An application user must still be able to run the application and view and modify data.
Let’s first take a look at Database Vault Realms. Here we have a database, let’s assume that this is a consolidated database. As you would expect you have the DBA as well as several other applications, here we’ve included an HR and Financial application. One of the problems faced in this type of situation is that the DBA can, if he or she wished to do so, use their powerful privileges to take a look at application data. Even the possibility of this happening can be prevented using Database Vault Realms. Simply place a Realm around the HR application and the DBA will no longer be able to use his powerful privileges to access the application.
The other situation is one I eluded to earlier. Application owners tend to have very powerful privileges. In a consolidated environment, it’s very likely that you’ll have more than one application and thus several powerful users in the database above and beyond the DBA. In this example, it’s possible for the HR DBA to look at the Financial application data. Obviously this wouldn’t be a good situation, especially if it was during the financial reporting quite period. Using a Database Vault Realm, the Financial application can be protected from powerful application owners.
Summary, Realms can be easily applied to existing applications and with minimal performance impact.
Oracle Database Vault is the newest and most advanced access control product from Oracle. Oracle Database Vault is particularly important for restricting highly privileged users from even accidentally accessing application data. Another area pushing demand for Database Vault technology is Database Consolidation and Data Warehouses. Database Consolidation provides great cost savings but it also requires greater security.
Oracle Database Vault addresses the least privilege problem by restricting the use of all powerful privileges from users such as the DBA. Privileges such as “Select Any” that can allow a DBA to intentionally or even accidentally view sensitive application data are blocked using a new security mechanism called a REALM. Second, Oracle Database Vault super imposes separation of duty on the database separating out Database Vault security management from Overall Database Administration and Account Management. Once installed, Database Vault prevents even those with the CREATE USER privilege from using that powerful privilege. Oracle Database Vault also provides real time access control over who, when, where & how applications, databases and data are accessed. using command rules combined with multi-factor authorization allow security polices to be associated with commands inside the database. For example, DDL commands can be restricted to specific IP addresses or subnets. An IP address is an example of a Factor.
Here we see how command rules and multi-factor authorization can work together to enforce business policies within the IT organization and even help reduce the risk of Insider threats. Multi factor authorization significantly increases security by combining more than one environmental factor before allowing access. This is kind of like multi-factor authentication but instead is focused on authorizations.
One requirement customers frequently have is restricting access to application data to a specific application or application server. Using Database Vault, a “trusted path” can be established between the application server or middle tier and the database. Preventing logins to the database from outside a specific range of IP addresses. Changes to databases might also be restricted to specific business hours or pre-approved patching dates.
Command rules can be associated with over two dozen individual database commands, such as create table, create view, drop table….
© 2011, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.
相关文章 | Related posts:
- Oracle Database 11g: High Availability Student Guide
- Upgrading to Oracle Database 11g
- Protecting Applications Using Oracle 11g Database Vault
- Oracle Database 11g:Next Generation High Availability
- How we created a clone database from the datafiles image copies of a physical standby database
- Oracle Database 11g: Change Management Overview eStudy
- Advanced Compression in Oracle Database 11g
- Oracle database 11g release2发布
- Why Standardize on Oracle database 11g?
- Oracle Database 11g-Don’t Get Left Behind!
最新评论