这么多复杂view,怎么办?

[xlongbuilder]

我们的现在这个项目是优sqlserver转到oracle 同时c/s模式到b/s

原系统中有几个大的视图,每个A4纸得打个5页左右.视图还套着视图.这些视图都是系统的关键视图,基本没有什么优化余地,
而且查询返回数据有时需要多,有时需要少,即很难确定到底使用不使用索引.
sqlserver 查询很快大约在1秒左右.
oracle 大约10秒左右.

而且这些报表由要求实时性没法物化视图.
其中主要涉及的几张表 大概 40万左右.

也试了好多办法了,但效果甚微.
怎么办 给个思路? 没辙了 难道oracle 还要输给sqlserver 没法跟客户讲啊,丢人

[又是违规昵称]

之前的表和事务是按sql server设计的，
现在迁到oracle, 不大动设计性能不会有本质提高

oracle 70%的性能设计时就决定了，
再怎么优化只是争那30%的空间

[yf520gn]

[Quote=引用楼主 xlongbuilder 的帖子:]
我们的现在这个项目是优sqlserver转到oracle 同时c/s模式到b/s

原系统中有几个大的视图,每个A4纸得打个5页左右.视图还套着视图.这些视图都是系统的关键视图,基本没有什么优化余地,
而且查询返回数据有时需要多,有时需要少,即很难确定到底使用不使用索引.
sqlserver 查询很快大约在1秒左右.
oracle 大约10秒左右.

而且这些报表由要求实时性没法物化视图.
其中主要涉及的几张表 大概 40万左右.

也试了好多办法…
[/Quote]
视图套视图一般是因为数据库结构设计的不合理而造成的~
ORACLE具体的优化有很多~比如调节ORACLE参数设置，更具执行计划调整你的SQL语句~
一时半会说不完的~~

[yf520gn]

[Quote=引用 1 楼 lpc19598188 的回复:]
之前的表和事务是按sql server设计的，
现在迁到oracle, 不大动设计性能不会有本质提高

oracle 70%的性能设计时就决定了，
再怎么优化只是争那30%的空间
[/Quote]
单纯套用SQL SERVER~当然慢了~

[xlongbuilder]

[Quote=引用 3 楼 yf520gn 的回复:]
引用 1 楼 lpc19598188 的回复:
之前的表和事务是按sql server设计的，
现在迁到oracle, 不大动设计性能不会有本质提高

oracle 70%的性能设计时就决定了，
再怎么优化只是争那30%的空间

单纯套用SQL SERVER~当然慢了~
[/Quote]
与事务没关,只是视图多了点而已,没有其他的

--ORACLE具体的优化有很多~比如调节ORACLE参数设置，更具执行计划调整你的SQL语句~
加内存到4G,4cpu,linux 索引,索引组制表,分区 基本都搞过了,没什么大变化 很惨的

能不能讲下怎么设计才符合oracle 的要求,给点建设性意见吧

[yf520gn]

1.尽量不要用嵌套视图
2.优化你创建视图和查询的SQL语句，减少对硬盘的I/O次数
3.正确创建索引

[grintyang]

拜托楼主，sqlserver和oracle数据库各有各的特点。
在sqlserver中执行速度快的view，在oracle就不一定快
在oracle中一些语句，设置，存储过程的写法等等，sqlserver都不支持。
所以，最好是把视图更改更改吧。
还有我想提点，oracle中的视图，就没有了key 和index。

[sulins]

看楼主的意思，就是因为原视图是系统的关键SQL，而且复杂，从而不敢对SQL进行重构优化。

tsql和pl/sql除了支持标准SQL外，都提供了自有的函数存储过程，要充分利用和挖掘pl/sql的能力。

举个简单的例子，处理树级结构数据，对于sql server 2000来说很复杂（更高版本除外），而对于oralce 9i及以上版本来说，是一件很轻松的事情。（connect by … start with …）

[xlongbuilder]

没有这样的东西
都是大量的group by sum case 左右连接

[oraclelogan]

[Quote=引用 8 楼 xlongbuilder 的回复:]
没有这样的东西
都是大量的group by sum case 左右连接
[/Quote]

1，一定要优化视图，甚至需要重写，因为oracle跟sqlserver里面差别太大了，不然以后查询出错了，有bug了，你不熟悉这些视图的业务sql流程，你怎么挑错啊？现在不熟悉、不改，以后也会做这部分工作的。

2，有些数据视图或者函数取的数据，如果不是经常变化的而是一个月变化一次或者半年变化一次一年变化一次，可以考虑建一张辅助表存储这部分数据。

[xugh]

同意楼上的，既然你知道固化视图，可以选择一个恰当的时间点，在此时间之前的全部转到固化视图中，视图只取该时间点之后的数据，然后再union
不过还是需要了解视图是如何构建的

[wgqqgw]

我觉得，单凭这两句，这些视图能优化的地方应该很多
“原系统中有几个大的视图,每个A4纸得打个5页左右.视图还套着视图”——这还了得，看都看不清，让写的人来看都不一定想起当初怎么写出来的
“都是大量的group by sum case 左右连接”——最耗资源的算法都用上了，还想怎样

[oraclelogan]

[Quote=引用 11 楼 wgqqgw 的回复:]
我觉得，单凭这两句，这些视图能优化的地方应该很多
“原系统中有几个大的视图,每个A4纸得打个5页左右.视图还套着视图”——这还了得，看都看不清，让写的人来看都不一定想起当初怎么写出来的
“都是大量的group by sum case 左右连接”——最耗资源的算法都用上了，还想怎样
[/Quote]

最好资源的算法？这位兄弟说的是group by sum case里面用了最耗资源的算法吗？

[wgqqgw]

[Quote=引用 12 楼 oraclelogan 的回复:]
引用 11 楼 wgqqgw 的回复:
我觉得，单凭这两句，这些视图能优化的地方应该很多
“原系统中有几个大的视图,每个A4纸得打个5页左右.视图还套着视图”——这还了得，看都看不清，让写的人来看都不一定想起当初怎么写出来的
“都是大量的group by sum case 左右连接”——最耗资源的算法都用上了，还想怎样


SQL code
最好资源的算法？这位兄弟说的是group by sum case里面用了最耗资源的算法吗？
[/Quote]

group by
左右连接

够耗的了。

[xlongbuilder]

看看这个,怎么办 帮帮忙,给点建设性意见吧
http://topic.csdn.net/u/20090209/16/fad52b15-6bee-4056-bc47-ad65c0748c9d.html