数据库规划方案讨论

chao_ping

最初由 ligengocp 发布
3）LOG_BUFFER 最好不要超过512K，过多容易造成DOWN机时数据丢失
[/B]

log_buffer大和数据丢失没有什么关系吧？

MTS下面一般也不会使用到80%-90%的物理内存吧？没有生产系统上使用经验，我碰到过的使用MTS的也很少有超过70%的。

chao_ping

最初由 feng_xin 发布
[B]

不是OPS方式。 若归档的话需要客户自己去整理归档文件，所以暂时不考虑归档。 备份方式是RAID5（不可更改）+EXPORT，这种备份方式有一定的风险，有没有更好的方式？
system表空间，从其他客户的使用来看，一般是300-400m左右，考虑到磁盘有36G，所以加大到800M。其实500M按理来说应该是够用了。 [/B]

双机不用OPS的话，你们用oracle standby？还是Tru64 自己的HA?

feng_xin

最初由 chao_ping 发布
[B]
双机不用OPS的话，你们用oracle standby？还是Tru64 自己的HA? [/B]

Tru64 自己的HA

ligengocp

最初由 chao_ping 发布
[B]
log_buffer大和数据丢失没有什么关系吧？

MTS下面一般也不会使用到80%-90%的物理内存吧？没有生产系统上使用经验，我碰到过的使用MTS的也很少有超过70%的。 [/B]

--MTS下面一般也不会使用到80%-90%的物理内存吧？
这也是ASKTOM上问出来的。

--log_buffer大和数据丢失没有什么关系吧？
以前有这种认识：
log_buffer是ORACLESGA的一部分,所有DML命令修改的数据块先放在log_buffer里,如果满了或者到了check_point时候通过lgwr后台进程写到redologfile里去。它不能设得太大，这样在意外发生时会丢失很多改变过的数据。它最好不要大于512K或者128K*CPU个数。

我承认我错误，在COMMIT后log_buffer中的数据被写入online redo logfile，而且一个SCN被赋予，当所有BUFFER数据被写入到LOGFILE时，ORACLE才认为这次提交成功。所以写online redo logfile与提交要么同时成功，要么同时失败。不存在数据丢失问题。

chao_ping

1. 我也看到了。tomas都这么说，肯定是没错的。他说mTS下面不超过物理内存的80%-90%。
2。 你概念弄错了。修改候的数据是放在undo segment里面的。一小部分也会在data buffer里面的。log buffer里面不是放这个东西的，它记录了所有将要写到logfile里面的东西。commit之后的数据是不会丢失的。commit的时候，先要flush rlog buffer，才通知用户commit完成。

ligengocp

最初由 chao_ping 发布
[B]1. 我也看到了。tomas都这么说，肯定是没错的。他说mTS下面不超过物理内存的80%-90%。
2。 你概念弄错了。修改候的数据是放在undo segment里面的。一小部分也会在data buffer里面的。log buffer里面不是放这个东西的，它记录了所有将要写到logfile里面的东西。commit之后的数据是不会丢失的。commit的时候，先要flush rlog buffer，才通知用户commit完成。 [/B]

针对你所说的第二点，我承认我以前的理解有误。不过好像不管写到undo segmentg或是data buffer时都肯定要将修改矢量写到redo log buffer中的。

chao_ping

这次你说对了。

ttdb

最近看了 backup and recovery，好像 redo log里头也记录了 修改矢量，不敢确定

呵呵，数据不会丢失，看来得到了一致

另外，查了一下教材，这么说
Size of the Redo Log Buffer
• Larger values reduce log file I/O, particularly if transactions are long or numerous.
• Frequent COMMIT statements will clear out the buffer, leading to a smaller buffer
size.

Note: The LOG_BUFFER parameter can be set smaller than the platform-specific
value (for example, 512 KB on UNIX systems), but if the LOG_BUFFER value is less
than the platform-specific value, then Oracle RDBMS increases LOG_BUFFER value
to the platform-specific value at instance startup. This can be changed on a platform
basis, depending on what is determined to be the optimum value for the given port.

512K是至少的

还有，这个很容易忘记
"The LOG_BUFFER size must be a multiple of the operating system block size."

ttdb

最初由 ligengocp 发布
[B]

1）SHARED_POOL_SIZE =80M，对于经常进行复杂长时间查询的数据库而言，SHARED_POOL_SIZE很容易消耗，或者FREE SIZE还有，但因为FRAGMENT太多，没有连续的EXTENT给ORACLE使用。
[/B]

我觉得这个，你是完全 搞错了

Library cache
+
Data dictionary cache
+
User Global Area
=shared_pool

OLTP Application Issues
• Make sure that code is shared.
• Use bind variables rather than literals for optimally
shared SQL.

DSS Application Issues
• Parse time is less important.
• Bind variables are problematic.

说得是oltp需要更多的shared_pool
而复杂长时间查询，shared_pool并不重要

从Hybrid Systems里头
Memory Use
The following parameters will have higher values for daytime (that is, OLTP):
• SHARED_POOL_SIZE
• DB_BLOCK_BUFFERS
• SORT_AREA_SIZE

也可以得出结论

yushiyin

非常同意CHAO_PING的上述观点，
我认为：
512M*0.8 给Oracle SGA 其余给系统

data buffer cache : 512M*.0.8*0.45
share_pool_size :   512M*.0.8*0.45
log buffer cache :   512M*0.8*0.1


TO: CHAO _PING，我想你在ORACLE DBA职位上找一个工作应该没有问题吧，否则，搞ORACLE的人都没有信心了。）：