缺省情况下， DB Control 的端口是5500, 可以参考下面的说明更改端口。
如果用户想改变oms端口，必须改变以下三个文件，然后重启db control以使得改变生效：
1.编辑$ORACLE_HOME/
oracle.sysman.emSDK.svlt.ConsoleServerPort
oracle.sysman.emSDK.svlt.ConsoleServerHTTPSPort
2.编辑$ORACLE_HOME/
REPOSITORY_URL
emdWalletSrcUrl
3.编辑$ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_
web-site port
注：请在修改前备份。
五、如何使用"Automatic SGA Management"
Automatic SGA Management 是 10G 引入的新特性之一，将初始化参数文件中与内存管理密切有关的几个参数抽取出来,交由数据库去自行管理(由新增加的参数SGA_TARGET来管理),在一定程序上能减轻DBA的负担.
至于参数的合理性，还需要结合AWR Report 去验证.
SGA_TARGET = db_cache_size + db_nk_cache_size(n=2,4,...)
+ db_keep_cache_size + db_recycle_cache_size +
shared_pool_size + java_pool_size + large_pool_size + xxxx
xxx: 是一个保留值，从目前的实验来看，基本是4M
步骤:
1.
alter system set sga_target=300m scope=both
create pfile from spfile;
shutdown immediate;
修改init
db_cache_size, shared_pool_size, java_pool_size,large_pool_size
2. 启动SQLPLUS,以新的pfile文件启动数据库
SQL> startup pfile=''....''
让我们来看看调整的结果:
SQL> select name, block_size, current_size from v$buffer_pool;
name block_size current_size
-------------------------------------------------------------
KEEP 8192 204
SQL> Select pool, sum(bytes)/1024/1024 as "M bytes" from v$SGASTAT
group by pool;
pool M bytes
-------------------------------------------------
java pool 4
large pool 4
shared pool 84
205.002403
205.002403=buffer cache + log buffer + fixed sga + all others ...
改动java pool的值
SQL> alter system set java_pool_size=20M;
SQL> select name, block_size, current_size,prev_size from v$buffer_pool;
name block_size current_size prev_size
----------------------------------------------------------------------------------------------
KEEP 8192 188 204
SQL> Select pool, sum(bytes)/1024/1024 as "M bytes" from v$SGASTAT
group by pool;
pool M bytes
-------------------------------------------------
java pool 20
large pool 4
shared pool 84
189.002403
可以看出, db_cache_size的值已经被自动调小了.
再把java pool 的值改回去
SQL> alter system set java_pool_size=8M;
SQL> select name, block_size, current_size,prev_size from v$buffer_pool;
name block_size current_size prev_size
-----------------------------------------------------------------------------------
KEEP 8192 188 204
SQL> select name, block_size, current_size,prev_size from v$buffer_pool;
pool M bytes
-------------------------------------------------
java pool 20
large pool 4
shared pool 84
189.002403
这一次, db_cache_size的值没有变化 , JAVA_POOL_SIZE的值也没有变化
修改large pool的值为16M
SQL> alter system set large_pool_size=16M;
System altered.
SQL> select name,block_size,current_size,prev_size from v$buffer_pool;
NAME BLOCK_SIZE CURRENT_SIZE PREV_SIZE
-------------------- ---------- ------------ ---------
DEFAULT 8192 176 188
SQL> Select pool, sum(bytes)/1024/1024 as "M bytes" from v$sgastat group by pool;
POOL M bytes
------------ ----------
java pool 20
large pool 16
shared pool 84
177.002403
这次，db_cache_size和large_pool_size的值都变了
同样,调大shared_pool_size后, db_cache_size会自动减小.
虽然db_nk_cache_size的值不会随着workload 的改变而自动调整, 我们还是可以看看手工改动db_nk_block_size 的情况
SQL> alter system set db_2k_cache_size=4m;
System altered.
SQL> select name,block_size,current_size,prev_size from v$buffer_pool;
NAME BLOCK_SIZE CURRENT_SIZE PREV_SIZE
---------------- ----------------- ------------ ----------
DEFAULT 8192 172 176
DEFAULT 2048 4 0
SQL> alter system set db_2k_cache_size=0;
System altered.
SQL> select name,block_size,current_size,prev_size from v$buffer_pool;
NAME BLOCK_SIZE CURRENT_SIZE PREV_SIZE
----------------- ---------------- ------------------ --------------
DEFAULT 8192 176 172
SQL> alter system set db_2k_cache_size=8m;
System altered.
SQL> select name,block_size,current_size,prev_size from v$buffer_pool;
NAME BLOCK_SIZE CURRENT_SIZE PREV_SIZE
-------------------- ---------- ------------ ----------
DEFAULT 8192 168 176
DEFAULT 2048 8 0
结论: 手工调整db_nk_cache_size确实会影响原有的参数.
最后说一点: SGA_TARGET参数与SGA_MAX_SIZE参数有密切关联，基本的原则就是前者的值不能大于后者的值.
总结：设置了SGA_TARGET参数后，数据库会在这个范围内自行调整；但许多情况下, 怎样合理地设置这个参数仍是DBA需要考虑的问题, 他们需要结合AWR Report等辅助的工具来分析.( 当然，我们可以根据Advisor的历史信息而确定一个比较合理的值)。
六、乱码问题
Redhat RHEL AS3 下安装 Oracle DB 10g 中文乱码问题
不少兄弟反映在rhel3下安装oracle10g时出现乱码, 其实在安装和使用时出现乱码的地方有多个, 可以分为三类:
1. 安装时的乱码
2. 一些应用程序的乱码, 比如 dbca, netca
3. 一些基于oc4j的web应用的乱码, 比如 isqlplus, em
造成这些问题的原因都是一个, 就是这些程序都使用jdk, 相应的jdk(或jre) 使用的字体配置文件 font.properties 中的字体和操作系统的字体或者字体配置文件不匹配. 解决的办法是把两者改成一致.
1. 下载, 解包 ship.db.cpio.gz, 生成目录 Disk1
2. cd Disk1/stage/Components/oracle.swd.jre/1.4.2.0.0/1/DataFiles/
unzip all_except_bin.jar (这时生成一个 jre 的目录)
cd jre/1.4.2/lib/
mv font.properties font.properties.bak
cp font.properties.zh_CN.Redhat8.0 font.properties
cd ../../../
zip -r all_except_bin.jar.new jre/
mv all_except_bin.jar.new all_except_bin.jar
(其实就是把 font.properties 文件换掉. 这样安装时汉字显示就没有问题了)
3. 如法炮制, 把Disk1/stage/Components/oracle.jdk/1.4.2.0.0/1/DataFiles/sol_bin.1.1.jar文件里面的font.properties 文件换掉, 创建数据库和执行网络配置时的乱码就没有了. isqlplus 和em 的乱码也解决了。
用IE登录Linux服务器上的em出现的乱码
不知道大家有没有注意到，EM显示的中文翻译很是糟糕，up/down 动不动就翻译成“向上”“向下”，让人哭笑不得.很多朋友都说，干脆给显示英文算了，可是怎么显示呢?
好了，现在我们有一种办法很容易的解决这个问题:
打开你的IE浏览器，选择''工具"-->Internet选项-->常规
选择“语言”，默认只有“中文”，选择“添加”，加入英语(美国),调整顺序，把”英语(美国)“放到最上面
OK ,确定。
打开你的 http://yoururl:5500/em
问题解决了。
