评论转载
eldersun
2011-4-29 12:01
通过Oracle 的EXP/IMP来转储Content Store时的字符集设置 通过EXP/IMP迁移Cognos资料库，担心字符集不的问题导致数据丢失，最安全的办法是客户端设置成和服务器端相同的字符集，例如数据库一般使用AL32UTF8字符集，系统环境变量设置可设置如下：
NLS_LANG=SIMPLIFIED CHINESE_CHINA.AL32UTF8
这样虽然导入导出的过程中console界面是显示乱码，但是不影响导入导出的数据，日志文件中可以查看正常的显示。 另，从前客户端都是用ZHS16GBK的，虽然有警告但是在使用过程中也没有发现什么异常，这次为了严谨，还是采用了完全相等的字符集。
如果想了解更多的关于Oracle字符集的内容，下面的文章肯定会提供很大的帮助。
http://blog.csdn.net/tianlesoftware/archive/2009/12/02/4915223.aspx #cognos系统管理 评论转载
eldersun
2011-4-14 16:13
Cognos故障排查：RSV-BBP-0038 一、故障描述
访问报表不断出现异步请求失败的错误，如下图： 同时伴有访问效率下降。 二、故障分析
分析Cognos配置，未发现问题。 三、故障处理
gateway所在的服务器使用的web服务器是apache2，检查发现web服务器的日志信息达到4G，清理日志并重启apache后，访问正常。 四、其它
错误提示和实际错误相去甚远，可以说很隐蔽！ #cognos系统管理 评论转载
eldersun
2011-3-4 09:07
Cognos连接Oracle业务库的改进方法 当使用Oracle存储业务数据时，连接Oracle使用的是Oracle的OCI方式，数据库的链接信息通常是通过Oracle的本地命名方法，即在tnsnames.ora文件中配置Oracle的连接别名实现，一个典型的tnsnames.ora配置文件片段如下： # tnsnames.ora NetworkConfiguration File: c:\\Oracle\\product\\10.1.0\\Client_1 \\NETWORK\\ADMIN\\tnsnames.ora
# Generated by Oracleconfiguration tools. MYOracleDB =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT= 1521)) )
(CONNECT_DATA =
(SERVICE_NAME =MYDB) ) )
通过上述配置，可以在Cognos新建数据源时直接输入MYOracleDB，则可以实现数据库访问，使用本地命名的Cognos数据源配置方法如下： STEP1: STEP2： STEP3: STEP4：
通过上述方式可以建立Cognos到指定数据库的连接，但是这种方式在实际使用中有一定的缺陷，首先是每次增加或者变更连接信息都需要在服务器中变更，如果Cognos服务器是一个规模较大的集群，那么维护这些tnsnames.ora配置文件的版本同步和变更也有一定工作量，如果在生产环境中经常变更还可能带来一定的运行风险；其次，如果使用 未完，继续阅读 #cognos系统管理 评论转载
eldersun
2011-1-14 19:41
Cognos故障分析：启动错误 error -1
OS： windows 2003 sp2 Cognos： 8.3 故障描述：正在运行的Cognos，通过Configuration重新启动Cognos时报错 ，错误信息为error -1；通过windows 服务管理器启动Cognos服务，报用户无权启动服务。
故障排查：Cognos系统日志cogserver.log没有错误信息的记录，查看操作系统服务管理器，发现Cognos的启动用户的登录身份不是“本地系统账户”，而是自定义的administrator账户，由于在上次Cognos服务启动后，administrator更改过系统口令，而导致本次启动时，administrator账户无法启动Cognos服务。
故障排除：重新舒服修改后的administrator用户的密码或者使用“本地系统账户”的登录身份启动Cognos服务。
该错误信息和系统服务被禁用的提示信息相同！ 未完，继续阅读 #cognos系统管理 评论转载
eldersun
2010-12-28 09:48
Cognos故障分析：运行错误【CAM-AAA-0071、RQP-DEF-0177】 Cognos：8.3sp2
OS：Windows 2003 SP2
伴随错误：UDA-SQL-0114, UDA-SQL-0107、Out of memory等。 故障原因：Windows 内存碎片过度。
解决方法：修改windows注册表，HeapDecommitFreeBlockThreshold项的16进制值改成：REG_DWORD 0x00040000
建议：在windows下，无论是否出现上述错误都应该修改该参数项 #cognos系统管理 评论转载
eldersun
2010-12-23 15:38
Cognos故障分析：启动错误【CNC-MON-0024， ORA-00942 】 一、环境信息
Cognos版本：8.3sp2
Content Store：Oracle XE 二、错误现象：
Cognos安装后初次启动报错CNC-MON-0024、ORA-00942，但服务能够启动成功；登录Administration后查看服务状态，显示DeliveryService没有正常启动，尝试启动报错CNC-MON-0024、ORA-00942。 三、故障分析：
Oracle XE默认使用了UTF-8字符集，Cognos初始化所使用的表空间也很小，默认的表空间能够支持。检查用于连接Content Sotre的Oracle用户具有Connection、resource角色，有Create Any View和unlimited Tablespaces权限，并且数据库表、视图均已建立。 使用DBA权限查看如下信息：
select value from v$parameter where name = 'processes' select value from v$parameter where name = 'sessions' 发现Oracle XE默认的连接数和线程数为40:50，可能较小。 四、处理方法：
通过如下语句增加Oracle XE的允许连接数和最大线程数 alter system set processes=200 scope=spfile alter system set sessions=220 scope=spfile
设置后重新启动Oracle XE数据库实例，重启Cognos服务器，启动过程没有报错，访问Administration查看服务状态一切正常。 五、经验总结：
排查过程中曾使用如下语句查看连接状态： Select count(*) from v$session Select count(*) fr 未完，继续阅读 #cognos系统管理 评论转载
eldersun
2010-12-22 13:49
Cognos高可用性部署之二：Cotent Manager的集群方式 经验一：Content Manager独立于Cognos的其它模块部署。到8.3位置，Cognos所使用的JRE为32位，所使用内存大小不超出2G，将Cognos的各种模块集中部署后会造成内存挤占而可能无法正常运转，另外，在Cognos的各模块中，维度Content Manager模块是无法横向扩展的，因此，单个JVM的处理能力从某种程度上说决定过了整个集群所能够扩展的上线。 经验二：使用小型机并且和Content Store部署在同一设备上可以减少请求的平均响应时间，提高访问效率。 经验三：对于Cognos 8.3版本，至少使用sp4的补丁版本才能保证稳定运行，并且严重推荐使用Cognos 生命支持级别为Active的操作系统版本。 经验三：部署两套Content Manager而不是更多的Content Manager，因为其无法实现横向扩展，提供容错机制就可以了。
经验四：增加Content Manager所在容器的连接数和线程数到1000，虽然这些不是必须的，但是调整该参数的确能够带来性能和稳定性的提升。 经验五：定期重启，长期运行后可能带来稳定性的下降，定期重启可以提供更好的服务水平。 未完，继续阅读 #cognos系统管理 评论转载
eldersun
2010-12-13 14:33
Cognos高可用部署之一：基于Oracle RAC的Content Store实现 一、前言
资料库（Content Store）的可靠性是Cognos集群可靠性的根本，当使用Oracle作为资料库时，Cognos提供了连接Oracle RAC的方式，通过这种方式，Cognos能够利用Oracle RAC的可靠性实现Content Store的可靠性，继而保证Cognos Content Manager模块的可用性，同时也实现了Cognos Content Store的横向扩展。
二、Oracle RAC的部署要求
对于Oracle的基本要求就是实例要使用UTF-8字符集，另外，RAC集群的规模最好仅为两个实例组成，最好能够提供服务器端的错误转移能力。