甲骨文(Oracle)的逆OOS姿态及从其迁移
2010-08-21 09:20:10 
阿炯
Oracle开始显露出它对开源软件的真实立场了吗？才过几个月，Oracle收购Sun Microsystems之后的效应开始显露。其中，就有一系列对开源软件的打击。最开始是在2009年四月宣布计划收购Sun的；这场交易持续到今年六月才结束。收购Sun之后，Oracle接管了一系列关键技术，包括开源软件空间里的一些。其中就有Java，MySQL数据库和OpenSolaris。起初人们就Oracle将如何对待它的新开源财产持有疑问，现在看来情况渐渐明了了。
OpenSolaris：第一个感到不安的是OpenSolaris，Sun开源版的Unix操作系统。OpenSolaris董事会苦于与Oracle的交流太少。它向公司发出通牒，说如果Oracle不向它派出联络人，它将从公司分立出来。那也被忽略了。现在Oracle已经宣告说它有意背离开源操作系统。在一个邮件里，这家公司说，Solaris必须还是其用户的首选OS，但 OpenSolaris不会在其中扮演任何角色。Oracle告诉开发者，他们将不再能触及Solaris的开发代码，只能得到大的发行之后的完整代码。之前代码是每天都与开发者共享的。
PostgreSQL：第二个受害者是PostgreSQL数据库。尽管不归Oracle所有，这一开源数据库软件是现在为Oracle所有的MySQL的一大对手。Sun Microsystems以前一直在为PostgreSQL的开发投入服务器。可是7月末，Oracle把这项工作停了下来，让PostgreSQL身陷囹圄，也让人们对其开源工作愈加怀疑。
Java：第三大举动是控诉Google侵犯其Java专利。Java本身是开源软件，是在被Oracle收购前不久开源的。真正不是完全不受限制的只有诸多的Java 技术规格。Google 和 Sun最初协商在Android操作系统上使用Java。当二者协商失败之时，Google转向其自身的为Android重编译Java的 Dalvik虚拟机。那是一种避开从Sun那里得到Java使用许可的限制的方式。那时这可能惹恼Sun，但Google已经开始和Oracle协商了，也表示愿意进一步合作。甚至还有来自内幕人士的暗示，说控诉Google可能就是与Oracle的协商中的一部(意思是说Oracle出卖了Java 吗？--译者注)。
尽管有着这些与开源软件想悖的做法，Oracle说它投入到了开源。在公司最近的杂志里，Oracle的 Edward Screven说开源是公司的全局战略之一。
渐露'铁血' - 本色开源遭遇挑战
源自LUPA开源社区2010年9月上旬消息：免费的开源软件源于高科技行业的“修补爱好者”和研究人员。他们的主要目的是分享代码和创意，而非盈利。在科技行业，他们有时会被人比作社会主义者和共产主义者。但那些岁月早已逝去。虽然部分理想主义色彩仍然存在，不过随着开源软件逐渐被IBM、甲骨文、惠普、谷歌、苹果甚至微软等科技巨头看重，它们也逐渐向商业化靠拢。开源也有了更加外扩的定义，现下的开源不是免费，而逐渐变成是一种商业模式，并成为了企业斗争的工具。
甲骨文这个在收购Sun还誓将开源发展壮大的软件寡头，在最近则开始逐步显露它“铁血”的商业化立场了。Oracle最开始是在2009年四月宣布计划收购Sun的；这场交易持续到今年六月才结束。收购Sun之后，Oracle接管了一系列关键技术，包括开源软件阵营里的一些。其中就有 Java，MySQL数据库和OpenSolaris。起初人们就Oracle将如何对待它的新开源财产持有疑问，但随着事态的逐渐发展，现在看来情况渐渐明了了，人们之前的担心正在逐步应验。
在完成收购后不到几个月，Oracle收购Sun Microsystems之后的纯商业化逐利效应开始显露。Sun开始成为这个冰冷的商业机器暴力拆解，创造利润的目标，其中，就有一系列对开源软件的打击。
第一个感到不安的是OpenSolaris，Sun开源版的Unix操作系统。OpenSolaris董事会苦于与Oracle的交流太少。它向公司发出通牒，说如果Oracle不向它派出联络人，它将从公司分立出来。
这样的声明无疑被甲骨文公司忽略了。现在Oracle已经宣告说它有意背离开源操作系统。在一个邮件里，这家公司说，Solaris必须还是其用户的首选OS。不过在最新版本的Solaris中，甲骨文已经要求用户必须在90天内购买软件的服务合同，否则将不再对用户免费开放。开源已经让甲骨文在这个 产品中逐渐剔除，利润正成为甲骨文最终的目标！而另一边，OpenSolaris不会在其中扮演任何角色。Oracle告诉开发者，他们将不再能触及Solaris的开发代码，只能得到大的发行之后的完整代码。 之前代码是每天都与开发者共享的。
除了OpenSolaris，连OpenOffice这个著名的开源文档软件也成了甲骨文整改的目标。从技术角度来说，这是我曾经用过的最好的 OpenOffice版本。然而，我注意到有几件事，给了我很大的理由去关注它们。根据我所看到的，我很怀疑，将来OpenOffice.org是否还会 继续是一个自由/开源软件。
甲骨文的表现让人感觉似乎带着一些敌意，至少在互动上以及OpenOffice社区里是这样。也许更令人不安的是，他们似乎正试图将OpenOffice从已经传播多年的自由软件许可证下隔离出来。那么事实究竟是如何呢？我们将通过本专辑为大家详细介绍……
而在服务支持方面，甲骨文更是开始将主动权掌握在自己手里。对于Oracle将直接为更多Sun硬件提供更新这则消息，连数据中心专家们都不能确定这究竟是好事还是坏事。有报道称最晚到2010年10月15号为止，Oracle将会收回与Sun硬件支持和维护VAR（加值经销商）们所签订的协议。很多IT用户总是喜欢从主要供应商那里直接获得支持服务，与他们签订更新合同。然而，也有许多IT专家表示他们更喜欢使用与他们保持长期合作的第三方合作伙伴的服务。他们对那些 为他们提供采购建议并处理支持和服务的那些VAR和集成商表示信任。
不过，Oracle会将这些服务收归己有，没有人会感到奇怪。在过去这些年里，Oracle收购了许多提供第三方维护和更新服务的软件厂商。现在，追逐利益的甲骨文正在实行它的“铁血”政策，要把所有收益都据为己有。前面谈到目前开源的发展趋势，虽然开源的商业化是一种合理的趋势，但开源也正成为大企业之间争斗的对象。最近，甲骨文起诉谷歌侵犯其专利一事，就完全显露出甲骨文试图借助这起诉讼重新建立Java的企业控制权，并最终借此获得巨大赢利的目的。
追溯历史，我们就可以知道，甲骨文原本就是一家传统商务软件公司，其主要收入来自于软件授权。甲骨文支持Linux，但主要目的是希望借此节省用户在使用其数据库软件时产生的软硬件成本。但这样的赢利模式似乎和开源的商业模式有着很大的出入。十余年的市场磨合下来，开源软件的盈利模式已经找到了一个正确的方向：它的主要市场在企业级的IT基础架构环境之中，盈利模式主要来自后期的服务和应用费用。从商业角度来看，所有的促销方式殊途同归，而开源的软件模式，则把这种促销变成了商业运作 的常态。
但在甲骨文看来，开源的商业模式，似乎并不对拉里·艾利森的胃口。毕竟高价格、高服务费用，是这家企业软件巨头一贯的商业风格，从Java到Solaris，甲骨文必然会想尽一切办法将这些原本开放的平台纳入到自己的轨道之中。秉承了这样的价值取向，甲骨文开始了对Sun的一系列整合，伴随着的是对开源社区和开源软件开发者的巨大挑战。开发周期短？用户不感兴趣？对待社区贡献者苛刻？大多数可能是这样。吃惊吗？一点都不，开源精神可能会创造伟大的软件，但是成为软件界的大恶魔会带来大量的财富。然而后者才是Oracle这样的 公司真正关心的。
从 Oracle 迁移到 PostgreSQL 的常见陷阱
该迁移并非没有障碍，可以先看一下此二者的相关对比。
PostgreSQL和Oracle的数据类型的对比
PostgreSQL和Oracle的函数差异分析
PostgreSQL和Oracle的常规使用对比
以下是在迁移过程中可能遇到的一些常见问题的真实示例。
1.SQL 语法和功能的差异
Oracle 和 PostgreSQL SQL 语法和功能并不总是一对一的匹配。这可能会导致迁移过程中出现问题，尤其是对于复杂的查询和存储过程。
例如：在 Oracle 中曾经严重依赖 “CONNECT BY” 子句进行分层查询。PostgreSQL 不支持 “CONNECT BY”。不得不使用递归公用表表达式（CTE）重写这些查询，这是 PostgreSQL 处理分层数据的方式。
2.交易行为
Oracle 和 PostgreSQL 处理事务的方式不同。在 Oracle 中，DDL 语句被视为自治事务，并立即提交。相比之下，PostgreSQL 将 DDL 语句视为常规事务。例如：曾经尝试在 PostgreSQL 的单个事务中执行一系列 DDL 和 DML 语句，期望它们的行为类似于 Oracle。这导致了一些意外行为，因为更改没有立即提交。
3.区分大小写
默认情况下，Oracle 对列名和表名不区分大小写，而 PostgreSQL 区分大小写。如果您的 Oracle 架构使用混合大小写标识符，这可能会导致出现问题。例如在 Oracle 中有一个包含混合大小写列的表。当我将其迁移到 PostgreSQL 时，我遇到了问题，因为 PostgreSQL 将 “myColumn” 和 “mycolumn” 视为两个不同的列。
4.序列和自动递增
在 Oracle 中可以创建一个序列，然后使用触发器自动递增列。PostgreSQL 有一个内置的功能，可以使用 “SERIAL” 或 “IDENTITY” 自动递增列，但是将 Oracle 序列和触发器迁移到这种新范式可能会很棘手。例如：* 在 Oracle 中，我有一个带有序列和用于自动递增主键的触发器的表。迁移到 PostgreSQL 时不得不用 “SERIAL” 主键替换它们。
5.数据类型
Oracle 和 PostgreSQL 有不同的数据类型集。虽然其中许多是直接映射的，但某些 Oracle 数据类型在 PostgreSQL 中没有等效项。例如在 Oracle 中有一个使用 “NUMBER” 数据类型的表。PostgreSQL 没有 “NUMBER” 类型，所以我不得不在 PostgreSQL 中仔细地将其映射到适当的数字类型。
6.空和空字符串
Oracle 以相同的方式处理 NULL 和空字符串，这与 PostgreSQL 不同，后者的 NULL 和空字符串是不同的。如果 Oracle 数据库或应用程序依赖于此行为，则需要在迁移过程中仔细处理此问题。迁移后的应用程序中曾经遇到过一个错误，因为它依赖于 Oracle 将空字符串视为 NULL。不得不更新应用程序代码以在 PostgreSQL 中分别处理 NULL 和空字符串。
7.日期和时间类型
Oracle 有一个包含日期和时间的 DATE 类型，这与 PostgreSQL 不同，PostgreSQL 将日期和时间分为 DATE、TIME 和 TIMESTAMP 类型。如果 Oracle 数据库使用 DATE 类型来存储时间，这可能会导致混淆。例如在 Oracle 中有一个表，其中包含用于存储日期和时间的 DATE 列。当使用 DATE 类型将其迁移到 PostgreSQL 时，丢失了时间信息就不得不返回并将其更改为 PostgreSQL 中的 TIMESTAMP 类型。
从 Oracle 迁移到 PostgreSQL 不仅仅是按下一个开关这么简单。这是一个包含一系列步骤的旅程，例如架构转换、数据迁移、应用程序迁移和性能调优。每个阶段都有自己的问题，需要一个解决方案的工具箱来处理它们。
1、Ora2Pg
它是一个开源工具，可将 Oracle 数据库模式转换为 PostgreSQL 格式。优点：
可以处理大量的甲骨文对象
可通过配置文件进行配置
局限性：
复杂的 PL/SQL 转换可能需要手动干预
大型数据库可能需要很长时间才能转换
ora2pg -t TABLE -o table.sql -b /output/directory -c /path/to/config/file
Oracle 数据库中也有一堆序列：
ora2pg -t SEQUENCE -o sequence.sql -b /output/directory -c /path/to/config/file
就这样就已经准备好了 PostgreSQL 表和序列。
2、pgLoader
它是 PostgreSQL 的数据加载工具，它使用 COPY 命令来超快地加载数据。它就像一辆移动的卡车，帮助将数据从 Oracle 传输到 PostgreSQL。当第一次尝试移动我们的数据时，进展缓慢。但是使用 pgLoader，只是运行了以下命令：
pgloader oracle://user@localhost/dbname postgresql:///dbname
还有一堆 CSV 文件需要加载到 PostgreSQL 中。pgLoader 也处理了这些：
pgloader --type csv --field 'column1,column2,column3' --with 'header=true' csv_file.csv postgresql:///dbname
优点：
快速数据加载
可以从各种来源加载数据，包括平面文件和其他数据库
局限性：
不提供在迁移期间转换数据的选项
仅限于数据加载，不处理架构或代码迁移
3、外部数据包装器 （FDW）
它是 PostgreSQL 的简洁功能，它们可让您管理其他数据库中的数据，就好像它们是本地 PostgreSQL 表一样。例如有时需要直接从 PostgreSQL 查询 Oracle 数据。对于 FDW，我能够设置一个外部表并且像对本地数据一样运行查询：
CREATE EXTENSION oracle_fdw;
CREATE SERVER oracle_server FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//hostname/dbname');
后来当需要从外部 MySQL 数据库中提取数据时，使用了 mysql_fdw：
CREATE EXTENSION mysql_fdw;
CREATE SERVER mysql_server FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'mysqlhost', port '3306');
优点：
简化数据集成
支持不同的数据源
局限性：
一些外部数据包装器是只读的
性能可能比本地查询慢
4、pg_dump、pg_restore 和其他内置 PG 功能
PostgreSQL 带有自己的工具箱。发现两个非常有用的工具是用于数据备份和还原的 “pg_dump” 和 “pg_restore”。在的迁移过程中，一旦我们所有的数据都在 PostgreSQL 中，想确保有可靠的备份。所以使用这些命令来转储和恢复数据库：
pg_dump -U username -W -F t dbname > dbname.tar
pg_restore -U username -W -F t -d dbname dbname.tar
还有几张需要单独备份的大表，“pg_dump” 工具再次派上用场：
pg_dump -U username -W -F t -t large_table dbname > large_table.tar
优点：
可以处理完整备份和部分备份
允许并行备份和恢复
局限性：
从转储还原可能比初始备份慢
不是为大规模数据迁移而设计的
5、Npgsql
它是 PostgreSQL 的.NET 数据提供程序，.NET 应用程序与 PostgreSQL 通信。有一个.NET 应用程序需要连接到我们新的 PostgreSQL 数据库。使用 Npgsql，它就像：
var connString = "Host=myserver;Username=mylogin;Password=mypass;Database=mydatabase";
using (var conn = new NpgsqlConnection(connString)){
conn.Open();
// Perform database operations
}
从.NET 应用程序调用 PostgreSQL 存储过程，Npgsql 使它变得简单：
using (var conn = new NpgsqlConnection(connString)){
conn.Open();
using (var command = new NpgsqlCommand("stored_procedure_name", conn)){
command.CommandType = CommandType.StoredProcedure;
var result = command.ExecuteNonQuery();
}
}
优点：
用于 PostgreSQL 的完全托管的.NET数据提供程序
支持新式 .NET 功能，如异步和实体框架核心
局限性：
仅适用于 .NET 应用程序
可能需要更改应用程序代码才能从 Oracle 数据提供程序切换
6、EverSQL，用于迁移后调优
在完成迁移后，查询需要进行一些调整才能在 PostgreSQL 上高效运行。这就是 EverSQL 的用武之地。这个工具采用了我们的 SQL 查询，并针对 PostgreSQL 进行了优化。一个 Oracle 查询在 PostgreSQL 上运行得比较慢时可将它弹出到 EverSQL 中，它给出了一个优化版本，运行速度提高了 19 倍。还使用 EverSQL 的 Index Advisor 功能来获取有关添加哪些索引的建议。
优点：
自动 SQL 查询优化，具有自动重写功能。
提供索引优化建议
局限性：
大多数功能都在免费层上，但高级功能需要付费订阅。
被Oracle锁在牢笼里的JS
201X，国内著名的技术网站JavaEye发表了一个声明：由于Oracle的强硬要求，只能被迫放弃已经运营了7年的JavaEye域名和JavaEye品牌，更名为ItEye。
这件事在当时震动挺大的，很多人是第一次意识到：Java这个名字真是不能随随便便使用的啊！
自己玩玩儿没问题，但是一旦做大，有了商业利益，Oracle的法务团队立刻就把你盯上了（这是跟国内的大厂学的吗？）。
这也没办法，Oracle拥有Java的注册商标，当它挥舞起法律大棒的时候，几乎无人可以抵挡。
鲜为人知的是，JavaScript也是Oracle的注册商标。也就是说，使用JavaScript这个名称也存在当被告的风险。
1995年，Netscape公司的布兰登开发了一个用于浏览器的脚本语言：LiveScript。
同一时期，Sun的 Java 语言正在大火，为了蹭Java的热度，Netscape和 Sun 达成了品牌授权协议，把 LiveScript 改名为 JavaScript，以强调它是Java的“小兄弟”，能和 Java 一起使用。
“Java” 是 Sun 的注册商标，“JavaScript” 这个名字中含有 Java，因此商标必须由 Sun控制。
2009年，Sun被Oracle收购，JavaScript商标也被转入Oracle怀抱。
但是，和Java不同，Oracle虽然持有JavaScript商标，从未认真推出过一款名为 JavaScript 的产品。
它没有推出自己的浏览器，也没有参与JavaScript引擎(V8、JavaScriptCore、SpiderMonkey)的开发。它虽然也是ECMAScript技术委员会的成员，但不主导标准制定，也没有主要提案。这件事儿听起来挺魔幻的，Oracle似乎是为了持有而持有。但是，Oracle却时不时地挥舞法律大棒，维护下自己的权利。
2017年，AppStore的某位开发者收到通知，说其 App的名称（HTML, CSS,JavaScript Snippet Editor）未经授权使用了 “JavaScript” 字样，必须下架。开发者很无奈，只好把JavaScript改成了JS。
2023年，Oracle又给Cloudflare的首席系统工程师Sid Chatterjee发了一封律师函，要求Sid把“Rust for JavaScript Developers”这个公司的名称改掉，因为它使用了“JavaScript”，侵犯了Oracle的权益。
正是因为如此，一些公司和组织不得不避嫌了，不得不使用一些奇怪的名称：
1.ECMAScript
很多新程序员看到这个名字都很惊讶，明明是JavaScript，为什么起个这么古怪的名字？还有什么ES5、ES6的......
这就是因为当年Netscape想标准化JavaScript的时候，没法用JavaScript这个名字，只好临时以标准化组织ECMA的名字作为占位符，后来干脆转正，变成了ECMAScript。
这个名字实在糟透了，即使是WebScript、DOMScript、HTMLScript都比它好，怪不得JavaScript创始人布兰登说听起来像一种皮肤病。
2.JSConf
使用JavaScript的程序员创建了无数的社区组织，他们想开个会都得避嫌JavaScript，只能叫JSConf。
世界上最受欢迎的编程语言，甚至连一个以其命名的会议都做不到，可悲啊。
2022年9月3号，Node.js的作者Ryan Dahl写了一篇博文，希望Oracle能体面地放弃JavaScript商标，让大家可以自由地使用这个名称。
后来他干脆给Oracle写了一封公开信，再次请求Oracle释放JavaScript商标。这封信获得了27785名支持者的签署，也包括了各路大牛：
许多人得知 Oracle 竟然宣称拥有 JavaScript 的所有权后都感到震惊，但 Oracle 仍然保持沉默。
2024年11月，Ryan Dahl所在的Deno公司启动了法律程序，正式向美国专利商标局提交申请，要求撤销 Oracle 对“JavaScript”的商标权。
这次申请的理由非常充分：
1.通用性：JavaScript已经成为通用的名称，被全球数百万开发者使用，它不是一个品牌，已经是现代编程的基石。
2.放弃使用：Oracle 多年来未曾以“JavaScript”为名提供任何重要的产品或服务，Oracle 不控制、维护或执行该商标。
3.欺诈：Oracle 在续展商标的申请中提交了误导性证据，居然将将 Node.js 作为 Oracle“商业使用”的证据。
这一次，Oracle强大的法律团队开始发力了。他们首先时拖延到了最后期限才开始回应，并且很巧妙底对第三项（“欺诈”）发起攻击，说Oracle在续展商标申请时，不但提交了Node.js作为证据，而且也提交了自家产品Oracle JET作为证据。
Oracle JET是什么？
这是个UI相关的包，使用量极小。网友说它的 npm 包每周下载量约为 1000 次，有四个包在依赖它，如果沿着依赖树往下看，几乎全是其他Oracle 包或早已失效的演示/一次性程序。每周 1000 次下载可能全部来自其他 Oracle 项目的 CI 流水线。
经过一系列来回的交锋后，今年6月份，商标审判和上诉委员会驳回了第三项的指控。但是欺诈并不是案件的核心，“通用性”和“放弃使用”才是，目前这个案件还在进行中。
如Ryan Dahl在公开信中所说，Oracle能从JavaScript商标中获得的最大价值，就是将其授予公众以后获得的良好声誉。Oracle为什么不这么干呢？
因为这是Oracle的一种防御性资产，它不需要花钱开发，只要按期续展，并且能在必要时阻止别人滥用或混淆 “Java/JavaScript” 品牌。一言以蔽之：放弃无利可图但有风险，保留没成本却有控制力。这也是很多大公司处理“遗产型知识产权”的典型策略。