当你有需求将一个进程放在后台跑时,切忌使用nohup or screen.
screen需要在你run脚本之前运行,nohup可以修改已经运行的进程。
/usr/bin/nohup command [argument...]
/usr/bin/nohup -p [-Fa] pid [pid...]
/usr/bin/nohup -g [-Fa] gpid [gpid...]
/usr/xpg4/bin/nohup command [argument...]
查看全文当你有需求将一个进程放在后台跑时,切忌使用nohup or screen.
screen需要在你run脚本之前运行,nohup可以修改已经运行的进程。
/usr/bin/nohup command [argument...]
/usr/bin/nohup -p [-Fa] pid [pid...]
/usr/bin/nohup -g [-Fa] gpid [gpid...]
/usr/xpg4/bin/nohup command [argument...]
查看全文如果使用ssh而不是rsh
Failed to upgrade Oracle Cluster Registry configuration
防火墙最好关闭
VIPCA报错
SWAP不足
VIP添加过程中不断offline
DBCA无法在节点2创建数据库
SQLSERVER PLUGIN:
1 介质准备
1.1 从ORACLE官方主页下载OEM agent.
http://www.oracle.com/technology/software/products/oem/index.html
1.2 下载SYSTEM MONITOR PLUGINS
http://www.oracle.com/technology/software/products/oem/htdocs/system-monitoring-connectors.html
2 介质安装
2.1 在将要监控的SQLSERVER端,安装最新的OEM agent.
(确保OS版本和介质版本符合)
安装之前,在/etc/system下面添加OEM的服务器地址
安装完成之后,OEM监控端应该可以看到新的host.
2.2 SQLSERVER建立用户名和密码:
1. 新建管理用户,具有sysadm权限。
2. 确认开启TCP/IP模式,检查端口。
3 OEM配置:
3.1 在 OEM的/etc/hosts下面添加:
3.2 设置首选身份证明(OEM右上端首选项里)
为主机和代理都设置身份证明,即用户名和密码。
3.3 管理插件导入(OEM右上角设置里):
选择导入我们下载的plugin。
3.4 管理插件部署:
确保代理和主机的首选身份证明都正常设置。
部署到我们的代理。
3.5 为目标主机配置数据库监控。
进入目标-主机-目标-代理管理页面。
添加Microsoft SQL Server,填写正确的jdbc url, 确保主机名大小写正确。
验证连接通过即可添加数据库。
4 监控
4.1 主机监控界面。
通过目标-主机进入。
4.2 数据库监控界面。
在主机主页中,进入目标,选择数据库。
Be careful when you're using Date for your java application.
When you have a different timezone setting between your application client and the application server host, you may see time different with what you want.
Like:
Date dt = new Date();
It will show you a time with your local timezone, when you're wring a jsp file which need to get the current time, it will not be the server time.
Try use Calendar instead:
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("GMT-07:00"));
查看全文result_cache_max_size can't be set to big than 0, reason could be:
1. make sure you're using enterprise edition
2. set memory parameter(at least shared_pool_size), sga_target or memory target also helps.
| Modified 06-JAN-2010 Type BULLETIN Status PUBLISHED | |||
In this Document
Purpose
Scope and Application
11g MEMORY_TARGET Parameter Dependency
References
Automatic memory management can be configured using a target memory size initialization parameter MEMORY_TARGET and a maximum memory size initialization parameter MEMORY_MAX_TARGET. Oracle Database then tunes to the target memory size, redistributing memory as needed between the system global area (SGA) and the instance program global area (instance PGA). Before setting any memory pool sizes, consider using the automatic memory management feature of Oracle Database.
This note describes the relationships between the various memory sizing parameters.
Products
| ||
RMAN> duplicate target database for standby nofilenamecheck
...
...
Errors in file /u01/app/oracle/admin/stdby/udump/stdby_ora_794674.trc:
ORA-00600: internal error code, arguments: [krbvalunused_badfno], [64], [85], [], [], [], [], []
Are they the same? Based on documents, the second one will call "checkpoint" so does this mean alter system switch logfile contains alter system checkpoint?
The answer is NO.
Try to test on a busy system, alter system switch logfile several times until it rounds to the logfile that is still active, and you will hung at switch logfile. Check the v$Logfile you will see that your next logfile is active.
Solution is to alter system checkpoint and all uncurrent logfile will be inactive.
This definitely indicates that these two are not the same.
查看全文报错:
"Central Inventory /etc/oracle/oraInventory is on a shared drive, each node among rac1,rac2 should have its own Central Inventory. Central Inventory cannot be shared, this is not supported"
根据604513.1, 尝试修改地址没有效果。oraInventory的目录是在本地磁盘,按道理不应该出现这样的问题。
最终解决方法:
/u01/crs/oracle/product/10/app/oui/bin/attachHome.sh -silent -local -cfs CRS=true -invPtrLoc /u01/crs/oracle/product/10/app/oraInst.loc
检查版本:
crsctl query crs softwareversion
2 cases to recover standby after primary open resetlogs:
It's supported by oracle:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ps.htm#i1026480
| If the standby database. . . | Then. . . | Perform these steps. . . |
|---|---|---|
| Has not applied redo data past the new resetlogs SCN (past the start of the new branch of redo data) | Redo Apply automatically takes the new branch of redo. | No manual intervention is necessary. The MRP automatically resynchronizes the standby database with the new branch of redo data. |
| Has applied redo data past the new resetlogs SCN (past the start of the new branch of redo data) and Flashback Database is enabled on the standby database | The standby database is recovered in the future of the new branch of redo data. |
The MRP automatically resynchronizes the standby database with the new branch. |
| Has applied redo data past the new resetlogs SCN (past the start of the new branch of redo data) and Flashback Database is not enabled on the standby database | The primary database has diverged from the standby on the indicated primary database branch. | Re-create the physical standby database following the procedures in Chapter 3. |
| Is missing intervening archived redo log files from the new branch of redo data | The MRP cannot continue until the missing log files are retrieved. | Locate and register missing archived redo log files from each branch. |
| Is missing archived redo log files from the end of the previous branch of redo data. | The MRP cannot continue until the missing log files are retrieved. | Locate and register missing archived redo log files from the previous branch. |
1. ORA-01009: missing mandatory parameter
2. ORA-16055: FAL request rejected
3. ORA-01034: ORACLE not available
查看全文