如何部署Oracle数据库？

我有一个连接到Oracle或SQL Server数据库的ASP .NET应用程序.已经开发了一个安装程序,使用诸如"restore database ..."之类的sql命令将新数据库安装到现有SQL Server,该命令只是恢复我们保持在源代码管理下的".bak"文件.

我是Oracle的新手,我们的应用程序最近才被移植到与10g兼容.

我们目前正在使用"exp.exe"工具生成".dmp"文件,然后使用"imp.exe"将其导入开发人员框.

您将如何创建"Oracle数据库安装程序"？

您是否会使用脚本文件创建数据库,然后使用所需的默认数据填充数据库？

你会在幕后运行"imp.exe"工具吗？

我们是否需要为系统管理员提供一个干净的界面,以便他们可以选择目标服务器并完成,或者我们应该只提供".dmp"文件？什么是最佳做法？

谢谢.

问题是 - 您的客户对Oracle有何了解？

没有？你应该重新考虑这个立场.Oracle非常庞大而且复杂.如果您认为您的客户一无所知,那么您将开始提供教程并提供不合适的帮助.

最低能力？如果他们有能力,他们就足够了解自己.此外,他们知道足以运行执行SQL的脚本.

实际的DBA？大多数能够负担得起Oracle的组织都可以负担得起真正的DBA.真正的DBA可以应付很多事情 - 他们不需要太多的手持.他们中的一些人喜欢根据他们的商店标准分配存储参数.

您应该提供具有合理默认值的脚本.您应该以某人可以轻松找到所有存储参数并在必要时进行调整的方式定义脚本.

您的初始数据可以通过导出/导入或通过脚本.我更喜欢剧本.

作为DBA,开发人员和架构师,我从双方(消费者和提供商)反复做过这件事.

作为提供商,我的一项重大成就(1996年)是为最大的保险公司(数百万美元的项目)创建商业保险理赔管理软件产品的安装CD.该安装CD安装了Oracle 7.2 RDBMS引擎,FileNet光存储系统(扫描纸质文档并创建编目的二进制版本),以及我们的自定义声明处理应用程序(内置于VB 4.0),所有这些都集成并准备运行.作为安装过程的一部分,用户可以跳过Oracle软件安装或对其进行自定义,用户可以在其所有主要细节(数据库,模式,表空间,大小,磁盘等)中自定义/覆盖数据库配置.

我还为此产品提供了现场服务,其中包括必要时前往客户站点.在我可以复制的每个可以想象的场景下,我测试了安装CD数百次,而且我们从未遇到过需要打电话的现场故障,更不用说旅行了(我曾经四次旅行,但是对于预售的东西代替).

最近(2007年),我编写了一个用于megacorp内部系统的Oracle 10g数据库的脚本.在生产中,数据库的大小为8 TB,主要用于具有高数据量的单个事务表.在测试中,对于适度的服务器,数据库的大小约为1 TB.在开发中,数据库的大小约为100 MB,可以在我的笔记本电脑上运行.完全相同的脚本创建了所有三个环境,我可以在大约五分钟内扩展它们以处理新的环境/机器.该数据库涉及极端性能调整,因此定制所有相关特性绝对至关重要.

回到保险索赔处理产品 - 请允许我补充一点,我最初被雇用来领导它从SQL Server数据库转换到Oracle数据库.该转换被确定为业务必需品,因为大多数潜在客户并未将基于SQL Server的产品视为专业,严肃的解决方案.这在今天并不常见,但它仍然适用于一般情况:如果软件产品可以容纳目标客户(特别是企业级客户)首选的多个数据库选项,则它具有更好的市场渗透机会.

同样,安装CD也被视为一个基本要素.但是,这种情况以及更多的情况向我透露,大多数"真正的"DBA都不接受基于导入的数据库安装.作为一名DBA和架构师,我知道我绝对不会出于同样的原因.

简而言之,基于导入的数据库安装使客户几乎无法控制生成的数据库.它对客户来说是不透明的,让他们质疑它做了什么.它迫使客户花费大量精力试图行使他们无法控制的东西.众所周知,它很脆弱且容易出错(Oracle的进口因所有权和权限问题,约束问题等而众所周知).权衡所有这些影响,基于导入的数据库安装是不专业的 - 它不会首先满足客户的需求.

脚本化数据库安装提供了正确的透明度,可配置性,选择性可重复性以及专业性所需的整体客户控制.它还鼓励您以导入的方式正确理解数据库设计决策的影响.

最好的祝愿.