如何实现win和linux之间oracle数据库的架构

RAC（Real Application Cluster，真正应用集群）是Oracle9i数据库中采用的一项新技术，也是Oracle数据库支持网格计算环境的核心技术。它的出现解决了传统数据库应用中面临的一个重要问题：高性能、高可伸缩性与低价格之间的矛盾。

过去，如果企业希望其信息系统具有良好的可靠性、可伸缩性和高性能，就必须选择基于主机的系统，这意味着企业在系统建设之初就必须投入大量资金；如果要节省成本，企业可以选择基于客户机/服务器的计算体系，并在需要时逐步增添新硬件、扩展系统，但如果需要进行应用升级，企业就不得不付出高昂的升级费用，同时这种分布式系统的维护成本也不菲。

采用RAC技术，用户就有了更多的选择，无论是选择基于Intel架构的PC服务器、Unix工作站，还是最近两年颇受关注的刀片服务器；也无论是选择Unix、Windows，还是Linux操作系统，只要在这些软硬件平台上部署了Oracle9i的RAC系统，这些分布在各处的系统就能组成集群，实现用户所需的高性能和高可靠性。且当系统需要进一步扩展时，无需对应用程序进行任何修改。

“这就是基于网格计算环境的数据库，也是数据库技术的未来发展方向。”Oracle公司负责数据库业务的高级副总裁Andy Mendelsohn先生说。

为什么Oracle的RAC技术能够实现以上目标？因为RAC技术采用了“sharing everything”的实现模式。据Oracle公司技术专家介绍，RAC技术通过CPU共享和存储设备共享来实现多节点之间的无缝集群，用户提交的每一项任务被自动分配给集群中的多台机器执行，用户不必通过冗余的硬件来满足高可靠性要求。另一方面，RAC可以实现CPU的共享，即使普通服务器组成的集群也能实现过去只有大型主机才能提供的高性能，这也是Intel、Dell等公司非常愿意与Oracle合作、共拓高端市场的原因。

除了RAC技术，Oracle9i数据库还提供其他功能来支持网格计算，包括支持在数据库之间进行数据快速复制的Transportable Tablespaces、支持数据流更新的Oracle Streams、支持应用可移植性的One Portable Codebase等。Mendelsohn认为，对那些需要建立数据中心的企业来说，Oracle9i RAC加上刀片服务器和Linux操作系统，就完全能够替代传统的基于大型机的数据系统。

.net最常用的架构有哪些？

最长用的还是三层架构。

1. UI Tier（User Interface, 用户接口层）

表示层完成向用户展示界面，提供进一步操作的“驱动接口”，例如按钮，并显示结果。

2. Business Tier（商业层）

完成数据加工，提供加工后的数据给表示层，或者数据层。又可以分为 BLL(Business Logic Layer, 商业逻辑)和DAL(Data Access Layer, 数据访问)。DAL负责存取数据，BLL负责对DAL层操作，对数据进行运算和操作。BLL也负责响应表示层的事件。

3. Data Tier（数据层）

完成数据存储功能。可能是数据库、数据源、XML、文本文件等。

这样就把 数据、业务、显示 分开了。UI层只负责显示给用户看，至于数据怎么处理运算，由BLL进行并响应，处理完的数据，怎么存取由DAL层进行，数据怎么存在介质上由Data层完成，DAL就不用管。各层之间相对比较独立，物理依赖性就不那么高了，有时候就只需要编译改动过的层。

一般对开发和设计人员来说，只需要对UI, BLL, DAL 进行设计开发，DATA Tier由OS或者DBMS来进行，你只需要按“格式”来存取数据即可。

“三层结构的程序不是说把项目分成DAL, BLL, WebUI三个模块就叫三层了, 下面几个问题在你的项目里面：

1. UILayer里面只有少量(或者没有)的SQL语句或者存储过程调用, 并且这些语句保证不会修改数据?

2. 如果把UILayer拿掉, 你的项目还能在Interface/API的层次上提供所有功能吗?

3. 你的DAL可以移植到其他类似环境的项目吗?

4. 三个模块, 可以分别运行于不同的服务器吗?

如果不是所有答案都为YES, 那么你的项目还不能算是严格意义上的三层程序. 三层程序有一些需要约定遵守的规则:

1. 最关键的, UI层只能作为一个外壳, 不能包含任何BizLogic的处理过程

2. 设计时应该从BLL出发, 而不是UI出发. BLL层在API上应该实现所有BizLogic, 以面向对象的方式

3. 不管数据层是一个简单的SqlHelper也好, 还是带有Mapping过的Classes也好, 应该在一定的抽象程度上做到系统无关

4. 不管使用COM+(Enterprise Service), 还是Remoting, 还是WebService之类的远程对象技术, 不管部署的时候是不是真的分别部署到不同的服务器上, 最起码在设计的时候要做这样的考虑, 更远的, 还得考虑多台服务器通过负载均衡作集群

所以考虑一个项目是不是应该应用三层/多层设计时, 先得考虑下是不是真的需要? 实际上大部分程序就开个WebApplication就足够了, 完全没必要作的这么复杂. 而多层结构, 是用于解决真正复杂的项目需求的.”

而且三层之间有时候也不用那么严格，得根据实际业务逻辑来判断使用。这也是软件开发所以没有一个固定流程的原因。

还有个俺收藏得

UI层：

浏览器 —— 要考虑一下不同的浏览器、和插件若干

js脚本 —— ajax这一类的，数据验证了什么的。

显示数据 —— 放在.aspx 页面

提供数据 —— 放在.aspx.cs 页面

逻辑层：

业务逻辑 —— 承上启下，但是大多数情况只用一行代码就可以实现了。

数据逻辑 —— 组合SQL语句，存储过程的话就是给参数赋值了

数据层：

SQLHelp —— 具有类似功能的东东

数据库里的存储过程 —— 不用存储过程的话就略掉

数据库里的视图 —— 同上，我比较喜欢用

数据库里的表 —— 基础的东东了，对于客户来说，里面的数据是最最重要的了。