最近在参与数据库国产化的相关工作，热火朝天，忙忙碌碌，也发现数据库国产化的一些怪事儿。很多很多的甲方和应用开发商都要求必须适配某某数据库，或兼容某某特性，否则这个项目就黄了，或换数据库适配。貌似一听也很有道理，毕竟应用开发商是有一些开发的工作量在里面的。不过反过来想想也挺有意思的：1. 到底是数据库是基础软件还是应用软件是基础软件；2、莫非你原来运行在windows上的C程序还让linux改造以支

最近看到很多国产数据库厂商都是基于开源某斯库来的，而且还可以高举信创大旗，甚至有十几家都开始拥抱某开源社区。要知道是人家商业数据库还在开发和迭代呢。以我国产数据库的经验来看，国产数据库最难的迁移和适配工作，需要应用或数据库开发商做大量的妥协。我突然有一个恐惧的想法：当下大家都依赖开源社区开源生态把某斯做起来了，生态也起来了，数据库也迁移和适配过来了。你们那里来的技术底气和商务功夫保证自己的数据库不

dbaccess sysmaster -select * from sysdbslocale where dbs_dbsname not like 'sys%';GB18030-20005488utf8573728859-1819常用的基本上就是如上几种， 需要注意是否开启了GL_USEGLU环境变量。注意：1。 是每个database一个字符集，没有办法...

DBSSO (database system security officer) ：可以配置系统使得系统能够“审计特定的用户行为”和“定期分析审计结果”

具体错误如上图，建议排查的方面有：1、应用程序的的启动路径中是否有中文；2、是否存在连接用户弱口令的问题；3、字符集设置的是否可以数据库一致；4、客户端工具的ifxjdbc.jar驱动是否正确；5、telnet ip port是否可以成功；6、是否datastudio的版本不对？...

最近听说了一个国产数据库项目POC的若干故事，深有感触，与大家分享。1、国产数据库作为国产基础软件目前整体趋势是如火如荼，风生水起；2、国产数据库(无论分布式还是集中式)大部分的原型都是PG和mysql两大开源数据库，涉及 mysql分支的（包括mariDB和percana server）恐怕都难逃GPL协议的约束（至于是什么约束，请大家自行百度）；从这个角度来说，以PG为原型的貌似风险低一点；3

查看数据库的大小：​SELECT d.datname as "Name",pg_catalog.pg_get_userbyid(d.datdba) as "Owner",pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding",d.datcollate as "Collate",d.datctype as "Ctype",pg_catalog

要实现数据库的跨库访问，需要完成以下三步：1、修改/etc/hosts：ip地址空格或TAB主机名注：写上互相访问的两个主机的IP和主机名。示例:192.168.1.100 DB1192.168.1.200 DB22、修改/etc/hosts.equiv（如果没有就创建）：主机名TAB ...

管理员下运行VM未配置环境变量，需切到VM程序目录下.\vmware-vdiskmanager.exe -r "D:\HDR-CLUSTER\gbase01\虚拟机模板-cl2.vmdk" -t 0 "D:\QEMU_DEMO\gbase01.vmdk".\vmware-vdiskmanager.exe -r "D:\HDR-CLUSTER\gbase02\虚拟机模板-cl2.vmdk" -t 0

1、创建共享磁盘，需要用管理员权限执行vmware-vdiskmanager -c -s 40000Mb -a lsilogic -t 2 H:\sharedisk\sharedisk.vmdk2、修改虚拟机的配置文件，追加如下内容disk.locking = "FALSE"diskLib.dataCacheMaxSize = "0"diskLib.dataCacheMaxRead...