什么是Oracle BRM?
BRM 指的是Billing and Revenue Management (BRM) ，是一套专门针对通信行业设计的集成的终端到终端的企业软件套件。
Oracle 公司在2006年收购了Portal Software软件公司后，成为了Portal BRM产品的拥有者。 BRM最早被叫做Infranet(版本6.5, 6.7和更早)，之后被称作Portal(在版本7.0, 7.2, 7.3, 7.4时代)， 官方第一次使用BRM这一代号是从版本7.3.1开始。
客户有一套BRM系统运行在4节点的Exadata X2-8 Half Rack上，数据库版本是11.2.0.1 。
但是这套系统使用了Exadata默认的配置参数，而没有使用BRM系统专用的初始化参数。
这里我有必要提一下，一般来说大型的应用程序(Application)特别是Oracle自身的产品都会有经过Oracle公司自身验证过的一套推荐参数，譬如说Oracle Ebs Suite 11i 最早是在Oracle database 8i/9i 上设计的，一般来说在安装介质上就会附带有11i 在databse 8i/9i上的推荐配置参数，而如果你要将11i 迁移到10g上那么就需要到MOS上找出是否这一软件组合已经经过Oracle公司的认证，如果认证了那么一般都会有推荐参数。
假设计划在Oracle Database 11gR2上部署Oracle EBS R12的应用，那么可以从MOS上找到<Interoperability Notes EBS R12 with Database 11gR2 [ID 1058763.1]> 这个指南。
其他一些非Oracle的应用程序产品，如Sap这类流行的大型应用，Oracle也会进行一系列的认证，但是未必就有非常完整的Recommended Parameter列表了，当然如果您是SAP的用户的话，也可以从Sap哪里获得必要的支持。
<Questions About BRM Support For Oracle DB 11GR2 And Exadata [ID 1319678.1]>介绍了BRM应用程序在11GR2+Exadata上的一些常见问题和推荐的参数设置，这里引用一下：
Applies to:
Oracle Communications Billing and Revenue Management – Version: 7.3.1.0.0 to 7.4.0.0.0 – Release: 7.3.1 to 7.4.0
Information in this document applies to any platform.
Purpose
The purpose is to address some common queries around the supportability of BRM with respect to 11gR2 plus Exadata.
Questions and Answers
1) About 10G client support: BRM(731 and 74) is certified against 11G R2 DB environment using the provided 10G R2 client software. We would like to know about the support for the client itself; because the 10G server environment is out of support end of this year(2011), so does this out of support phrase also apply to the client software.
From BRM point of view , YES , we will support customers using BRM 731 + 11gR2(server) + 10gR2(client)
2) We would like to know of any pre-requisite patches of the BRM application to support the 11G database.
On BRM, there is no specific patches needed for 11G support. You would still continue to use the dm_oracle10g.so library (using the 10gR2 DB client).
3) Is it correct that a base installation of oracle 11G Release 2 is needed, and no additional patches are needed on the DB ( to successfully support pipeline batch processing on the BRM side) ?
Yes, 11gR2 is enough for BRM. Please check with the database group if they would advice any later patches for performance improvements.
4) This question is more on the relationship between the Application (BRM) connecting with ExaData ; are there are no specific patches on Exadata with respect to BRM?
BRM is certified on Exadata . It is certified against 11gR2 only and with BRM 7.3.1 onwards. No DB patches are required from a BRM perspective. You would need to check with the Exadata team/documentation to see if that particular product has any pre-requisites.
5) The certification overview does not specially mention RAC support on 11G, can you confirm if RAC is supported on the 11G database environment?
Yes, we do support RAC also on 11G database.
6) Can you elaborate on the AQ consequences in running them on the 11G environment?
There is nothing about consequences that we can tell. However we do support it ( AQ ) even in 11g.
7) As per the recent press release at : http://www.oracle.com/us/corporate/press/364536 ; about the BRM certification and benchmarking against Exadata; this is referring to BRM 7.4 and not to 7.3.1 . How about the same with respect to BRM731 in combination with Exadata?
We did not benchmark BRM 731 on Exadata; therefore, we cannot tell if it will show the same performance figures as seen in the tests on 74. However, the reason of good performance on BRM 7.4 is because Exadata offers an excellent database server capability, not that BRM 7.4 has made specific code change to take advantage of the Exadata hardware. For example, the optimization technique such as using FLASH disk to handle Redo log is equally applicable to BRM 731. Therefore, we envision that Exadata will also provide performance benefit to BRM 731.
8) Are there any specific settings we need to configure in BRM 7.3.1 or in Exadata itself besides the logical ones like DB hostname to work properly with Exadata and gain (more) of the advantages of Exadata?
Please see the white paper at the location “http://www.oracle.com/us/industries/communications/brm-exadata-performance-wp-362789.pdf”. This is also part of the press release mentioned before.
While there are no general guidelines about specific settings on BRM or Exadata ; below is a set of the DB configuration for the benchmark, if you may be interested. However, please note that this configurations work well for the benchmark, with the hardware setup that is specific to the benchmark. While doing similar testing at your end, it is advisable to review this configuration and obtain professional services opinion before deploying the configuration in a production system.
BRM DB Configuration :
Important parameters from init.ora in alphabetic order are:
_disk_sector_size_override=true
_file_size_increase_increment=2143289344
_gc_policy_time=0
_optimizer_skip_scan_enabled=false
cluster_database_instances=2
compatible=’11.2.0.2.0′
db_block_size=8192
db_cache_size=511101108224
fast_start_mttr_target=3600
lock_sga=true
log_buffer=1073741824
open_cursors=2000
optimizer_index_caching=90
optimizer_index_cost_adj=25
pga_aggregate_target=102400M
pre_page_sga=false
processes=2048
session_cached_cursors=400
sga_target=524288M
shared_pool_size=32768M
_b_tree_bitmap_plans=false so the BRM sqls donât get executed using plans that involve bitmap conversions, which in general result in longer sql execution time for BRM.
_disk_sector_size_override=true so db objects like redo logs can be created in the Flash Disk Group using larger BLOCKSIZE like 4KB, which improves log flush efficiency from the default 512B BLOCKSIZE.
_file_size_increase_increment=2143289344 for faster db backup / restore.
_gc_policy_time=0 to disable DRM.
_optimizer_skip_scan_enabled=false so the BRM SQL does not get executed using plans that opt for index skip scan, which is usually not the optimal access path for BRM SQL.
compatible must be ‘11.2.0.2.0’ to get the DB created. Because the ASM Disk Groups were created
to be 11.2.0.2 compatible which enabled extra functionality, but restricted usage to databases with
this level of compatibility or higher.
pre_page_sga=false. False is the default setting of this parameter. Hugepage was configured for
the DB SGA.
可以看到以上对几个隐藏参数有了更具体的描述，值得注意的是_disk_sector_size_override和_gc_policy_time；
_gc_policy_time是11.1之后才出现的参数,他的前身是_gc_affinity_time(_gc_policy_time in 11g)，最大的作用是禁用DRM
_disk_sector_size_override决定了创建在Flash Disk Group 上 redo log的BlockSize。
Depending on the type of file being written, and the type of output device, RMAN might be required to pre-allocate the space that it is writing to. The most common situation where pre-allocation is required is when writing datafile backup pieces into ASM. By default, when allocation is required, RMAN allocates space in 64MB increments as the file is written. In high-performance environments such as Exadata, the default allocation increment should be increased. In Exadata environments we have gotten good results with values of 1-2 GB. This is controlled with parameter _file_size_increase_increment.
PROBLEM:
——–
Customer experienced a complete DB hang because an rman backup operation
inundated the file system which affected other filesystems such that archive
logs were unable to switch and the DB ran out of online redo logs.
DIAGNOSTIC ANALYSIS:
——————–
As per analysis done by Veritas engineering, this is caused by inefficient
I/O increments of 50MB. Suggestion by Veritas is to use 32MB or multiples of
32MB for VxFS.
WORKAROUND:
———–
_file_size_increase_increment=64MB
The recommendation from Oracle was to turn off SKIP SCAN access method in Oracle versions 9.2.0.4, 9.2.0.6 and 9.2.0.7 by setting the following parameter _optimizer_skip_scan_enabled = false. A test case was setup in the PeopleSoft database HRQA and after implementing the setting above the SQL statement
Set _optimizer_skip_scan_enabled=FALSE or use the NO_INDEX_SS hint.
by setting “parameter _optimizer_skip_scan_enabled” to FALSE customer was seeing performance issues, so it was suggested customer to set “parameter _optimizer_skip_scan_enabled” back to TRUE and apply the 9.2.0.8.0 Patch 6 that contains the fix for this issue in development environment, perform tests and apply it to production environment.