我有一个连接到 Oracle 或 SQL Server 数据库的 ASP .NET 应用程序。已经开发了一个安装程序，用于使用诸如“恢复数据库...”之类的 sql 命令将新数据库安装到现有 SQL Server，它只是恢复我们保持在源代码控制下的“.bak”文件。
我对 Oracle 很陌生，我们的应用程序最近才移植到与 10g 兼容。
我们目前正在使用“exp.exe”工具生成“.dmp”文件，然后使用“imp.exe”将其导入开发人员框。
您将如何创建“Oracle 数据库安装程序”？
您会使用脚本文件创建数据库，然后使用所需的默认数据填充数据库吗？
你会在幕后运行“imp.exe”工具吗？
我们是否需要为系统管理员提供一个干净的界面，以便他们可以选择目标服务器并完成，还是应该只为他们提供“.dmp”文件？最佳实践是什么？
谢谢。
问题是——您的客户对 Oracle 了解多少？
没有？你或许应该重新考虑这个立场。Oracle 非常庞大和复杂。如果您假设您的客户一无所知，那么您将开始提供不适当的教程和帮助。
最低限度的能力？如果他们有能力，他们知道的足够多，可以自己运行 imp。此外，他们知道足以运行执行 SQL 的脚本。
实际的 DBA？大多数能够负担得起 Oracle 的组织都可以负担得起真正的 DBA。真正的 DBA 可以应付很多事情——他们不需要太多的牵手。他们中的一些人喜欢根据他们的商店标准分配存储参数。
您应该提供具有合理默认值的脚本。您应该以一种有人可以轻松找到所有存储参数并在必要时调整它们的方式定义您的脚本。
您的初始数据可以通过导出/导入或脚本。我更喜欢脚本。
作为 DBA、开发人员和架构师，我从双方（消费者和提供者）反复这样做。
作为供应商，我的一项重大成就（1996 年）是为最大的保险公司（价值数百万美元的项目）的商业保险索赔管理软件产品创建了安装 CD。该安装 CD 安装了 Oracle 7.2 RDBMS 引擎、FileNet 光学存储系统（扫描纸质文档并创建编目二进制版本）和我们的自定义索赔处理应用程序（内置于 VB 4.0），所有这些都已集成并可以运行。作为安装过程的一部分，用户可以跳过 Oracle 软件安装或对其进行自定义，并且用户可以自定义/覆盖数据库配置的所有主要细节（数据库、模式、表空间、大小、磁盘等）。
我还为该产品提供了现场服务，其中包括必要时前往客户现场。我在我可以复制的每个可以想象的场景下对安装 CD 进行了数百次测试，我们从来没有遇到过需要打电话的现场故障，更不用说旅行了（我确实旅行了四次，但是为了预售的东西反而）。
最近（2007 年），我为一家大型公司的内部系统编写了一个 Oracle 10g 数据库的创建脚本。在生产中，数据库大小为 8 TB，主要用于具有高数据量的单个事务表。在测试中，数据库的大小约为 1 TB，适用于普通服务器。在开发过程中，数据库大小约为 100 MB，可以在我的笔记本电脑上运行。完全相同的脚本创建了所有三个环境，我可以在大约五分钟内扩展它们以处理新环境/机器。该数据库涉及极端的性能调整，因此所有相关特征的定制绝对至关重要。
回到保险理赔处理产品——让我补充一下，我最初受雇负责将其从 SQL Server 数据库转换为 Oracle 数据库。这种转换被认为是一种业务需要，因为大多数潜在客户并不将基于 SQL-Server 的产品视为专业、严肃的解决方案。这在今天并不常见，但它仍然普遍适用：如果软件产品能够适应目标客户（尤其是企业级客户）偏好的多个数据库选项，那么它就有更好的市场渗透机会。
同样，安装 CD 也被视为必不可少的元素。然而，这种情况以及更多情况向我表明，大多数“真正的”DBA 不会接受基于导入的数据库安装。作为一名 DBA 和架构师，我知道我绝对不会出于同样的原因。
简而言之，基于导入的数据库安装使客户几乎无法控制生成的数据库。它对客户来说是不透明的，让他们质疑它做了什么。它迫使客户付出巨大的努力来尝试行使他们所能做的微不足道的控制。它是出了名的脆弱和容易出错（Oracle 导入以所有权和权限问题、约束问题等而闻名）。权衡所有这些影响后，基于导入的数据库安装是不专业的——它没有将客户的需求放在首位。
编写数据库安装脚本可提供专业要求的正确透明度、可配置性、选择性可重复性和整体客户控制。它还鼓励您以导入不具备的方式正确理解数据库设计决策的影响。
最良好的祝愿。
就我个人而言，我倾向于尽可能使用 SQL 脚本来创建数据库和加载数据。我倾向于使用PL/SQL Developer。它有一些很好的选项可以从现有数据库生成脚本。一旦有了这些，您就可以使用 sqlplus 或任何可以执行任意 SQL 的应用程序代码（例如带有 Java 的 JDBC）运行脚本。 Toad是用于 Oracle 开发的更常见（也更昂贵）的工具。
SQL 导出的唯一限制是它不能导出 CLOB/BLOB 字段。如果您有这些，您要么需要单独执行它们（作为 PL/SQL 导出），要么将整个事情作为 PL/SQL 导出来执行。除了文件实际上是二进制导出（扩展名 .pde）并且在如何执行它方面受到更多限制之外，没有任何戏剧性。
SQL 源文件的另一大优势是它们可以轻松进行版本控制。能够通过运行一两个脚本来创建数据库环境真的很方便。
我认为 Oracle 的导入和导出工具更适用于备份和恢复操作。
现在，至于将其交付给客户，从您的评论看来，您将把它交给 DBA。几乎任何 Oracle 安装都会涉及 DBA。他们可以使用 SQL 脚本来创建架构并进行数据加载。他们将进行大量特定于站点的配置（例如，根据预期负载调整 SGA、临时表空间、并发连接数等）。
作为供应商，您可以就任何相关配置提供指导，您可能会参与支持和可能的安装，但最终由他们来决定什么对他们有用。Oracle 在大量操作系统和硬件变体上运行，网络拓扑和防火墙配置具有无限变化。您不能将所有这些因素都考虑到安装人员甚至是一组说明（前面提到的指南除外）。
上次我参与创建（oracle）数据库（对于一家拥有内部 DBA 的相当大的公司）时，DBA 想知道以下内容：
（从记忆中）他们设置了数据库和表空间，然后我们提供了他们可以运行的简单脚本的组合（或者如果任务不容易自动化，则提供明确的说明）
正如我所说的，这是针对内部应用程序的，所以你的里程可能会有所不同，但在我的情况下，他们希望所有说明都清楚地拼写出来，以便（a）没有可能导致错误的事情发生的误解，并且（b）如果事情没有发生，他们没有责任' t 工作（“我们只是按照说明进行操作”）