仓酷云

标题: MYSQL网站制作之DataGuard - ORA-10567毛病 [打印本页]

作者: 透明 时间: 2015-1-16 22:40
标题: MYSQL网站制作之DataGuard - ORA-10567毛病
MySQL对硬件的较低要求是其最大的优势之一，不过需要注意的是：内存越多越好，因为所有的重要数据存储都在内存中完成。毛病
数据库已晋级到9205，操纵体系是SunSolaris8

在DataGuard情况中作Primary真个数据导进，也许有2G的dmp文件

导进过程当中在Primary端增加一个数据文件

因为设置了standby_file_nanagement=auto，该数据文件主动在Standby端也创立了

可是立即接上去的recover就报ORA-10567毛病

全部报错信息以下：

Errorsinfile/export/home/oracle/app/oracle/admin/ctsdb/bdump/ctsdb_mrp0_823.trc:
ORA-00600:internalerrorcode,arguments:[3020],[113246216],[1],[7617],[164],[72],[],[]
ORA-10567:Redoisinconsistentwithdatablock(file#27,block#8)
ORA-10564:tablespaceSTK_TS
ORA-01110:datafile27:/global/oradata/ctsdb/stk_ts03.dbf
ORA-10560:blocktypeKTFBBitmappedFileSpaceBitmap
MonAug3015:37:392004
MRP0:BackgroundMediaRecoveryterminatedwitherror600

查metalink没有解答
要想在MySQL与其他数据库之间进行一个面面俱到的功能设置对比，并不是一件容易的MySQL学习教程。随着新软件版本的发布或一些补丁的推出。

作者: 飘灵儿 时间: 2015-1-19 21:07
如果，某一版本可以提供强大的并发响应，但是没有Oracle的相应版本稳定，或者价格较贵，那么，它就是不适合的。

作者: 柔情似水 时间: 2015-1-28 10:42
还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。

作者: 莫相离 时间: 2015-2-5 20:41
其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。

作者: 精灵巫婆 时间: 2015-2-13 13:22
having子句的作用是筛选满足条件的组，即在分组之后过滤数据，条件中经常包含聚组函数，使用having条件显示特定的组，也可以使用多个分组标准进行分组。

作者: 乐观 时间: 2015-3-3 22:04
Mirror可以算是SQLServer的Dataguard了。但是能不能被大伙用起来就不知道了。

作者: 仓酷云 时间: 2015-3-11 14:13
需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。

作者: 第二个灵魂 时间: 2015-3-18 19:11
原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。

作者: 小妖女 时间: 2015-3-26 13:30
作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！

欢迎光临仓酷云 (http://ckuyun.com/)