确定处理数据库迁移所需的RAM数量

如果没有两台SQL服务器频繁地对磁盘进行分页，那么这个过程确实发生了一次。 如果两台服务器都在同一台机器上，情况更是如此。

MySQL（3Gb）数据的最终维度并不特别令人担忧。 任何现代的32位3Gb台式电脑都可以处理。 这是在900 GB的源数据（Oracle）上运行的查询将是过度的。

我知道你现在正在担心RAM，但其他​​一些会大大提高性能的因素是硬盘速度和处理器内核的数量。 第一个原因是由于查询将数据从磁盘上的数据库中提取出来，所以会有很多的硬盘访问，其次是因为这两个sql服务器都擅长充分利用多核处理器。

但是对于RAM：
您拥有的RAM越多，查询可以从磁盘提取的数据就越多。 许多因素会影响RAM的重要性。 最重要的可能是如果你的查询将包括子查询和类似的SQL结构？ 如果是这样，Oracle引擎将从磁盘中提取数据到内存临时表中，并在其执行计划上执行更高的查询。 可以驻留在内存中的数据越多，oracle需要重复这一过程的次数就越less，为了构造最终结果，需要将更less的数据分页回磁盘。

然而，你的数据库质量（我错过了正确的名词，但实质上在oracle上查询的表有多大）可以减less一些要求，如果只是这样，Oracle上的查询表不会超过1或2 GB的大小。

查询的质量必然会影响最需要的RAM数量。 这里的业务顺序是索引，索引和更多的索引。 例如，避免像瘟疫一样进行全文search，只有在必要时才采用，而不是在可能的情况下。 避免非索引search，因为这是一个迁移任务， 所以可以索引表中的列数比平常多 。 请记住，你只会从Oracle读取。 最后，你必须确保，在子查询的情况下，你尽可能地优化它们，这样你就不会提取太多不必要的行。

多less内存？
我担心，RAM的确切数量是无法制定的。 只有在您构build查询并准备启动过程后，您才能了解在单个事务中正在处理的数据量。

select你最繁重的交易（你知道的那个交易在处理时会产生大量的数据）。 估计在执行计划的最密集部分期间将生成多less行。 获取每行所需的总内存（求和每列所需的内存）并乘以行数。 这是可用 RAM的数量，您理想上需要避免分页。

最后一个优化：
一个交易可能看起来像一个不错的优化实践。 但要小心。 所有这一过程中的阻塞点并不是从900 Gb数据库读取数据的速度有多快，而是在分页之前可以保存多less数据。 因为事务将作为一个单元执行，所以需要更多的内存来保存临时结果和回滚数据。 避免处理大量数据的查询事务。

另外，在整个过程中只提取需要的列。 除非你确实需要它，否则SELECT *确实不是一个好主意。

结论：
我不能按照你的要求给你一个RAM的数量。 你必须明白这样做会是不公平的。 我会对你说谎。 您需要的RAM数量不仅受到每个查询中正在处理的数据量的影响，甚至会受到HDD性能影响（即使幅度较小），因为在您的情况下可以接受某些数据分页。

您的处理器和操作系统也可以使用RAM的数量。 正如你所知道的，如果它们都是32Bit，就不会使用〜3.8以上的值。 如果他们是64位，你可以塞入1TB的RAM，而不用担心它了。

最后，将Oracle服务器从MySQL服务器中分离出来，也会大大降低您对RAM的要求。 Oracle服务器机器将成为您的首选，而1Gb RAM MySQL服务器机器将高兴地处理传入的数据。

但有一件事我可以对你说，不要用1Gb的RAM来试试。 如果是32位的机器，请将其升级至4Gb。

祝一切顺利。

以现在的RAM价格，你的公司并没有在这里投入很大的资金。
所以去3GB的内存并且发现这是不够的。

去4GB的RAM，即使在一个32位操作系统，video卡将吃掉第四GB的一部分。

非math上来说，4GB应该够了。 如果没有，那么贵公司的下一个投资应该是在8位的64位操作系统（也许是一台新电脑）。