暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

初次接触神通oscar数据库的一些感受

白鳝的洞穴 2023-09-18
4358
神舟通用在国产数据库老四家(达梦、金仓、南大通用、神舟通用)里十分低调,很多行业用户以前都没怎么听说过神州通用这家数据库公司。不过这家中国航天集团旗下的数据库公司干数据库是从90年代中后期开始的,起步时间和达梦差不太多。神州通用很神秘,神通数据库就更神秘了,这个数据库到底长什么样,其产品发展的历史怎样,是不是基于某个开源数据库产品等都很难找到资料。这些年我们对神通数据库的研究也不多,大体知道神通早期的数据库产品叫oscar,与Oracle的兼容性很好,这些年神舟通用也加入了openGauss生态,也发行了openGauss内核的神通数据库产品。
         
最近有用户要接入神舟通用的oscar数据库,D-SMART也正好在往全面支持国产数据库方面发展。因此在我们的实验室里也安装了一套oscar,这个周末有点时间,我也简单的摸了一下oscar数据库。
         
以前听说神通oscar和PG书库有些渊源,据说早期神舟通用是在PG早期版本的基础上进行国产化改造,加入了大量的Oracle兼容特性,形成了现在的版本。不过出乎我意料的是oscar和PG从进程架构上就完全不同,oscar是一种单进程多线程架构的数据库。
         
在oscar中并没有给后台线程独立的命名,因此我们看不出oscar的后台都有些什么系统线程。而oscar的官方文档中也没有明确的说明。我们还是先根据自己的经验来摸一摸这个数据库产品。如果仅仅从线程架构上看,我可能会先入为主,认为oscar是不是和MySQL有什么关系。
         
在环境变量中SZ_OSCAR_HOME指向了数据库的安装目录。在我们的安装环境中是:SZ_OSCAR_HOME=/u01/ShenTong。那么我们先去看看目录结构。
目录结构十分简单,不过和PG、MySQL的差别都很大,我们先来看看安装的神通数据库的一些简单的情况。
可以看到我们安装的是一个oscar 7.0.8,数据库名称为XMAN,目前是非归档模式的。Oscar的目录结构比较简单,odbs下是存放数据库文件的。我们看看XMAN数据库下都有哪些文件:
我们看到有XMAN*.dbf,REDO.log,undots01.dbf,XMANtmp01.dbf等文件,从名字上来看和早期的Oracle数据库很相似,包含数据文件表空间、REDO/UNDO/TEMP等文件。当年的老四家做关系数据库的三家都是以模仿Oracle为主,因为当时做数据库国产化的单位都是为了信息安全,把数据库从Oracle迁移到国产数据库上,保持与Oracle的兼容性可以打打降低总体使用成本。在这方面达梦和神通数据库做得都比较彻底,连数据库存储引擎也都全面学习Oracle。
因为oscar对Oracle的模仿太到位了,作为一个老Oracle DBA,在第一次使用oscar的时候,没有特别费劲。很快就找到了v$sysstat这样的监控视图。而且完全是盲找的,因为在doc下的文档实在是太精炼了,精练到连系统视图介绍的章节都没有。
v$sysstat也给安排上了,这对于DBA监控数据库提供了一定的数据,oscar的sysstat有110多条,虽然没有Oracle丰富,不过做做简单监控也凑合用了。看样子D-SMART今后接入的数据主要来自于这个地方。
在v$session里我们还可以看到等待事件。目前只是简单的试用了一下,可以看到确实会产生于操作相关的等待事件。从v$event_name中,我们发现目前的版本一共有37个等待事件(包含idle).
等待事件的数量还是比较少的,与Oracle的2000多个等待事件相比不够一个零头,比起PG的几百个等待事件来说,也少了一些。不过等待事件包含了并发、IO、提交、配置、应用等多个方面,对于运维中分析性能与故障还是会有些帮助的。
下面就要回答一些朋友关心的oscar是不是一款完全套壳开源产品的数据库。从基本特性上看,oscar是在模仿Oracle,在SQL语法、PL/SQL等方面,以及系统包上,都与Oracle做了十分相似的兼容。也采用了Oracle的表空间、UNDO/REDO/TEMP机制。
在进程结构上,oscar采用了单进程多线程的架构,类似于MySQL,不过通过Perf工具跟踪内部调用,发现oscar与MySQL没有任何相似性。通过对一些细节的分析来看,oscar与PG数据库应该还是有些渊源的。只不过oscar已经经过了魔改,在表面上已经很难看到PG的影子了。除了进程/线程架构外,存储引擎已经完全替换,SQL引擎也针对Oracle做了相似性的改造。
我们用一个常见的测试用例来测试一下执行计划,熟悉PG的朋友应该一眼就能看出似曾相识。不过这个执行计划一眼就看出驱动表选得不合适。
对表做了分析后,驱动表选择正确了。在一个PG 14的环境中,我们做了完全相同的测试,结果如下:
         
从执行计划显示来看,oscar的SQL引擎应该和PG是有一定的渊源的。这是一个PG到目前为止还没有很好解决的执行计划问题,对于带OR条件的表关联,无法在某些场景中正确的使用HASH JOIN来替代NESTED LOOP,从而引发此类问题的性能问题。
         
今天我回顾了周末对神通oscar的初步探索,在最近一段时间适配D-SMART的过程中,我会更加深入的使用oscar,有什么新发现,再写文章和大家分享吧。如果正好您是oscar的用户,有些使用心得,也欢迎加我的微信与我交流。
         
         

文章转载自白鳝的洞穴,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论