企业官网建设流程全解析

做了这么多年数据库运维，最近把 YashanDB 23.4.1 企业版完整安装部署跑通了一遍，顺手把 YashanDB 认证（YCA/YCP 这类）里和安装部署直接相关的实操点整成了这篇记录。先说结论：这套数据库的安装思路和很多国产数据库类似——分用户、解压、初始化、启动，但企业版里打包了不少跟共享集群、并行计算强相关的组件，所以环境准备阶段比一般的开源库要更讲究。这篇教程就是从零走一遍，从选机器、装环境，到初始化实例、验证 Oracle 兼容特性，最后把踩过的坑也一并记下来。

这篇内容适合几类人：准备考 YashanDB 认证的学员、做国产数据库选型评估的 DBA、以及手头正好有数据库适配任务但第一次接触 YashanDB 的读者。我不贴官方文档原文，只讲我在一台 CentOS 7.9 测试机上从头折腾的实际过程，参数和命令都是可落地的，你照着敲就行。

1. 动手前的三件事想清楚：版本、授权和机器

1.1 企业版和认证考试是两回事

很多人一听“YashanDB 认证”就以为必须装企业版，其实不是。认证考的是你对数据库产品能力、架构原理和实操流程的把控，而安装部署是企业版里最基础的实操考点。我这次装的是 23.4.1 企业版，主要是为了验证企业版特性，比如并行查询、共享集群模块、细粒度权限这些能力，单机环境也能用，并不需要真的搭一套集群。

企业版和一般免费版本最大的区别在授权机制和组件完整性。企业版安装包里会带有授权相关的配置文件，安装初始化时会校验授权信息，比如 license 的机器指纹、申请日期、允许的 CPU 核数等。我看过不少人拿到安装包后随手解压就初始化，结果实例能起但功能受限，甚至数据库直接进入受限模式。所以动手前先去官网或授权渠道确认好企业版授权文件是否就位，这是最容易被忽略的“前置条件”。

我这次准备了企业版授权文件，并且核对过授权允许的 CPU 数量是 16 核，测试机的 CPU 也是 16 核，刚好卡线。如果你手里的授权是 8 核，机器却是 32 核，初始化也不会直接报错，但后续用企业版特性时会弹警示，考试环境下容易扣分。建议做认证练习时，租一台和授权规格完全一致的云主机，别让这种低级问题影响练习进度。

1.2 服务器配置怎么定才不浪费

安装数据库之前，先算清楚机器规格。我见过太多人在 8G 内存的小机器上硬塞企业版，启动都稀碎，然后跑来问是不是安装包有问题。说实话，YashanDB 的最低配置要求不算高，但如果要跑企业版的并行计划和共享集群验证，至少建议按“4 核 8G 起步，8 核 16G 舒适，16 核 64G 完整验证”这个梯度选。

我这次用的测试机参数如下：

内存分配是个值得展开的点。64G 机器不能全给数据库，我按下面这个逻辑切的：

• 操作系统和日常运维工具预留 4G 到 6G
• 数据库共享内存区（类似 SGA）大概给 32G，占总内存一半
• 每个用户会话的私有内存区总和控制在 8G 以内
• 剩余内存留给文件系统缓存，磁盘读写会受益

这个分配思路和装 Oracle、OpenGauss 都类似，但 YashanDB 对共享内存的依赖更明显，因为它自己管理缓冲区和日志缓冲。初始化实例时我直接指定了 SGA 相关参数，后面会专门讲到计算方式。

磁盘方面，数据目录一定要单独挂分区，和系统盘分开，否则后续做数据备份、日志轮转时容易把根分区撑爆。企业版安装包解压后体积不小，跑一段时间后 redo 日志、归档日志、慢查询日志会持续增长，500G 其实是保守值，生产环境按业务量另算。

1.3 操作系统兼容性别凭感觉

YashanDB 支持主流 Linux 发行版，包括 CentOS、openEuler、麒麟、统信 UOS 等。我会优先选 CentOS 7.9 和 openEuler，因为跟官方验证过最多的就是这两个系列。安装前第一件事是确认 glibc 版本和 CPU 架构：

cat /etc/os-release uname -a ldd --version

这三个命令一分钟就能执行完，但能避开 80% 的安装失败。我记得有一次在低版本 glibc 的机器上装 23.4.1，解压时就提示缺少符号，后来用strings /lib64/libc.so.6 | grep GLIBC一看才发现版本太旧。别急着怀疑安装包损坏，先查基础库。

另外，X86_64 和 ARM 架构对应的安装包不通用，下载时一定要选对。企业版安装包解压后的目录结构里有一个bin目录，里面是各平台编译好的可执行文件，如果拿错包，跑初始化命令时通常直接报“cannot execute binary file”。这个错误信息很直白，但经常有人被它带偏，以为是权限问题。

2. 环境准备：这些细节决定了后面 90% 的成败

2.1 创建专用用户和目录，务必拒绝 root

YashanDB 的安装运维强烈不建议用 root 直接操作。原因有两层：一层是安全层面，数据库进程如果被攻击，root 权限会直接危及整个操作系统；另一层是运维层面，用普通用户跑数据库，文件权限、日志清理、备份恢复都更容易管理。

我习惯创建一个名为yasdb的系统用户：

useradd -m yasdb passwd yasdb

然后规划两个核心目录：

• 软件安装目录：/opt/yashandb，放可执行文件和动态库
• 数据目录：/data/yashan，放数据文件、控制文件、日志

目录的属主和权限必须明确：

mkdir -p /opt/yashandb /data/yashan chown -R yasdb:yasdb /opt/yashandb /data/yashan chmod 755 /opt/yashandb /data/yashan

这里我吃过一次亏：数据目录的属主改好了，但父目录/data没有执行权限，导致yasdb用户根本进不去，初始化时报Permission denied。后来我养成了习惯——ll /data先把父目录权限看一遍，所有中间层级都要有x权限。

2.2 内核参数和资源限制，少一项都容易翻车

数据库一大类问题来自系统资源限制。YashanDB 同样需要调整信号量、共享内存、进程数、文件句柄这些参数。

我调整了以下几个核心参数：

sysctl -w vm.swappiness=10 sysctl -w vm.overcommit_memory=1 sysctl -w fs.file-max=6815744

vm.swappiness=10是为了尽量少用交换分区，数据库进程一旦被换出内存，性能会断崖式下跌。vm.overcommit_memory=1则是允许操作系统为数据库一次性申请大块内存，避免明明物理内存够用却申请失败。

进程数和文件句柄限制也要放开。编辑/etc/security/limits.conf，加入如下配置：

yasdb soft nproc 65535 yasdb hard nproc 65535 yasdb soft nofile 65535 yasdb hard nofile 65535 yasdb soft memlock unlimited yasdb hard memlock unlimited

memlock unlimited这个很多人忽略。YashanDB 的共享内存段可能使用shmget/mmap方式创建，memlock不放开，大内存场景会报Cannot allocate memory。我一开始就没加这两行，结果初始化实例时指定 32G 内存被系统拒绝了，查日志才发现是 memlock 的问题。

内核参数改完后，重新登录yasdb用户或者执行ulimit -a验证一下。注意limits.conf对已经登录的会话不生效，必须重新su - yasdb或者重新 SSH 登录。这种细节在认证考试里也算实操分，监考老师最喜欢看你会不会验证。

2.3 防火墙、时间同步和字符集，提前搞定

关闭防火墙不是最优解，但测试阶段最省事。我在 CentOS 7.9 上是这样处理的：

systemctl stop firewalld systemctl disable firewalld setenforce 0

生产环境建议不要在初始化阶段关 SELinux，直接用semanage port放行数据库端口更规范。不过测试机我图省事，先把 SELinux 置为 permissive，避免出现“进程起不来、日志无内容”这种诡异问题。

如果不想关防火墙，至少要放行默认端口 1688。YashanDB 默认服务端口是 1688，这个端口号要记住，初始化、连接、考试问答里都会出现。放行命令大概是：

firewall-cmd --permanent --add-port=1688/tcp firewall-cmd --reload

时间同步也建议提前配好，尤其以后要搭共享集群或者做增量备份，节点间时间漂移会导致日志乱序。测试环境我用chronyd同步：

systemctl enable chronyd systemctl restart chronyd timedatectl status

字符集我直接选了 UTF8。YashanDB 支持的字符集里有 GBK、UTF8、GB18030 等，如果业务侧有历史数据，初始化之前确定好字符集，不然后期迁移会有字符乱码的风险。初始化命令里我会显式传入--charset UTF8，不依赖系统环境变量。

3. 安装包处理与初始化实例：核心流程详解

3.1 下载校验和解压，不能直接双击

企业版安装包从官网下载后是一个 tar.gz 压缩包，文件名类似yashandb-23.4.1-enterprise-linux-x86_64.tar.gz。下载完第一件事是校验完整性，最简单的办法是对比官方提供的 SHA256 校验值：

sha256sum yashandb-23.4.1-enterprise-linux-x86_64.tar.gz

校验通过后，用yasdb用户解压到软件目录：

su - yasdb tar -zxf yashandb-23.4.1-enterprise-linux-x86_64.tar.gz -C /opt/yashandb

解压后目录结构大致包括bin、lib、share、conf、license等，我简单列一下：

解压完之后，把授权文件放到license目录下，并确认权限是yasdb用户可读。授权文件一般是一个.dat或.lic结尾的文件，如果权限不对，初始化阶段会报授权校验失败。

3.2 环境变量，配错了连客户端都跑不起来

YashanDB 的运行离不开环境变量，核心是YASDB_HOME和YASDB_DATA。在yasdb用户的.bashrc里写入：

export YASDB_HOME=/opt/yashandb export YASDB_DATA=/data/yashan export PATH=$PATH:$YASDB_HOME/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$YASDB_HOME/lib

然后source ~/.bashrc。这里有个顺序坑：LD_LIBRARY_PATH一定要先追加再看，别把原来的路径覆盖掉，否则系统命令都受影响。我第一次配置时直接写死LD_LIBRARY_PATH=$YASDB_HOME/lib，结果ls和cat都报动态库找不到，吓出一身冷汗。

YASDB_DATA表示数据目录，后续初始化、启动都会用到，如果你反复在命令行里写--datadir倒也不是不行，但考试时容易漏参数。配好环境变量后，执行echo $YASDB_DATA确认路径无误，再继续往下走。

3.3 初始化实例，内存参数我这样算的

初始化是安装过程的分水岭。我用的是命令行方式，先yasdb init --help看一下参数说明，再实际执行。不建议直接复制网上的命令，因为不同版本参数名可能有差异，但核心参数长这样：

yasdb init \ --datadir /data/yashan \ --port 1688 \ --charset UTF8 \ --memory-size 32G \ --redo-log-size 1G \ --log-buffer-size 512M

内存参数的计算逻辑是这样的：64G 物理内存，我预留 4G 给系统，再预留 8G 给文件缓存和运维工具，剩下 52G，取其中 32G 作为数据库的共享内存池。剩下的 20G 里再细分给后台进程、会话私有内存和归档缓冲区。

--redo-log-size 1G是每个 redo 日志文件的大小。数据库会预分配多个 redo 文件，如果太小，高频写入场景下频繁切换日志，性能会有明显波动。1G 是比较稳的中间值，小业务可以降到 512M，但对 64G 内存的测试机来说，1G 更合理。

初始化执行完成后，控制台会打印一段摘要，包含数据目录、端口、字符集、内存参数等信息。建议截图保留，因为后续排障、认证报名时偶尔会用到。同时检查数据目录下是否生成了yashan.ini或类似命名的实例配置文件，这是数据库实例的身份文件，不能随意删除。

3.4 启动实例与第一登录

初始化完成后启动就很简单了：

yasdb start

启动期间如果报错，第一件事是看日志，日志目录一般在数据目录下的log子目录里。正确启动后，用ps -ef | grep yasdb能看到多个数据库进程，数量一般大于 10 个，和别的数据库一个主进程带多个后台进程的模式不太一样。

第一登录用系统内置账号：

yasql sys/sys@127.0.0.1:1688

或者如果你在初始化时设了用户口令，就用实际密码。登录后先跑一句最简单的 SQL 验证实例正常：

select name, value from v$system_parameter where name like '%version%';

如果能看到 23.4.1 相关版本信息，说明核心安装已经跑通了。到这里，基本的安装部署链路已经完成，但离“企业版完整部署”还差几块——连接验证、企业特性验证、服务化配置。

4. 连接验证与企业版功能核对

4.1 修改默认口令，禁用不必要远程登录

系统内置账号sys是企业版初始化之后的最高权限账号，默认口令在测试阶段一定要尽快改掉。执行：

alter user sys identified by '新密码';

我一开始图省事，用一个弱口令顶着，结果写脚本时不小心把口令打印到了日志里，虽然只是测试环境，但那种感觉就像保险箱钥匙挂在门把手上。认证考试里也常考默认账号安全配置，改完口令要专门commit并验证新口令生效。

同时确认监听绑定地址。默认监听可能绑在本机回环地址上，如果需要其他服务器通过客户端远程连接，要把监听地址改成实际网卡 IP 或0.0.0.0。这个改动通常在实例配置文件的网络段里设置，改完要重启数据库。

4.2 建库建用户，验证 Oracle 兼容特性

YashanDB 对 Oracle 的兼容性是卖点之一，安装完不验证一下等于没装。我先建了一个测试表空间和用户：

create tablespace tbs_test datafile '/data/yashan/tbs_test.dbf' size 2G; create user test identified by 'test123' default tablespace tbs_test; grant dba to test;

然后切到test用户下执行几个典型的 Oracle 兼容点：

select sysdate from dual; select rownum, name from users; select nextval for my_seq from dual;

dual表、rownum伪列、序列的这些行为，我实测和 Oracle 的相似度非常高。如果你在公司做过从 Oracle 到其他国产库的迁移，你会知道这套兼容能力能省掉多少改 SQL 的工作量。

另外我也用 JDBC 驱动从另一台机器做了连接测试。YashanDB 提供标准 JDBC 驱动，驱动包在安装目录的lib下，URL 格式类似jdbc:yasdb://ip:1688/dbname。第一次用客户端连不上不要急着怀疑驱动，按后面第 6 节的排查清单走一遍，基本都是端口、监听、防火墙这三个地方。

4.3 认证考试里关于安装部署的高频考点

结合我接触到的 YashanDB 认证相关信息，实操考试中安装部署环节特别喜欢问这几类问题：

考试环境和真实部署最大的不同是时间紧凑，不会给你机会慢慢试错。所以平时练习时就要把命令背成条件反射，尤其init、start、stop、yasql这几个命令之间不要有明显的停顿感。我练习时是先把所有环境配置写成一个 shell 脚本，反复在自己的测试机上重置环境，直到脚本一次跑通为止。

5. 企业版日常运维：服务化、日志与备份

5.1 把数据库注册成 systemd 服务

重启服务器后手动启动数据库不是不行，但一个完整的部署方案应该支持开机自启。我把 YashanDB 注册成了 systemd 服务，写了一个单元文件，内容大概如下：

[Unit] Description=YashanDB Database Service After=network.target [Service] User=yasdb Group=yasdb Environment=YASDB_HOME=/opt/yashandb Environment=YASDB_DATA=/data/yashan Environment=LD_LIBRARY_PATH=/opt/yashandb/lib ExecStart=/opt/yashandb/bin/yasdb start ExecStop=/opt/yashandb/bin/yasdb stop Restart=on-failure LimitNOFILE=65535 LimitNPROC=65535 [Install] WantedBy=multi-user.target

然后systemctl daemon-reload && systemctl enable yashandb && systemctl start yashandb。这里有一个细节：systemd 给服务设置了独立的资源限制，即使系统limits.conf里写了memlock unlimited，服务文件里最好再显式声明LimitMEMLOCK=infinity，否则服务方式启动时仍可能受限。

测试完服务化之后，我用systemctl status yashandb看了一下状态，确认进程身份是yasdb，这样安全性和资源隔离都满足要求了。

5.2 日志体系，排障先从这看

YashanDB 的日志体系比很多国产库清晰，我整理出下面这个对应关系：

遇到排障场景，我第一反应是打开实例告警日志。如果日志里出现ORA-风格错误码，说明数据库层面有明确报错，比如ORA-12541之类（兼容 Oracle 时错误风格相近）；如果日志里只是空洞的连接超时，那问题往往在网络层。

企业版还有一个好处是并行操作的相关日志更完整，比如并行导入导出、并行 DDL，都能在日志里看到每个工作线程的执行情况。调并行度时我会先开大日志级别，压测完了再调回来，避免日志量爆炸。

5.3 备份恢复要不要现在做

安装部署完成不等于万事大吉。企业版带逻辑备份和物理备份两套路径，我测试时用了 SQL 层面的导出工具：

ys_dump -u sys -d sys -h 127.0.0.1 -p 1688 -f /backup/yashan_full.dmp

这个工具会把数据目录里的逻辑对象导出成一个文件，用于日常备份足够。更彻底的物理备份要配合归档日志使用，简单说就是把数据文件、控制文件、redo 日志、归档目录整体复制走，恢复时按时间点回放。测试机我做了逻辑备份验证，生产环境建议至少一周做一次带校验的物理备份。

备份恢复还有一个容易忽略的点：恢复环境的版本要和备份时完全一致，小版本不一致可能导致控制文件不兼容。我踩过一次，从 23.4.1 备份的数据恢复到 23.4.1 没问题，但想恢复到同系列的 23.4.0 就报了版本不匹配。好在报错信息很明确，所以平时备份机尽量保持和线上同版本。

6. 排障实录：安装部署中我踩过的坑

6.1 初始化失败，报 Permission denied

我第一遍初始化时，数据目录的属主改好了，但父目录/data的执行权限没放开，yasdb用户进不去，初始化程序报Permission denied。排查顺序：

su - yasdb cd /data/yashan

cd一执行就现原形了。解决办法是：

chmod o+x /data

然后重跑初始化。这个坑很基础，但提醒我一点：目录权限要查整条路径，不只是最后一层。尤其是三层以上目录结构，逐层namei -l /data/yashan看权限更靠谱。

6.2 启动失败，端口 1688 被占用

第二次启动时，实例一直处于启动中状态，告警日志提示bind: Address already in use。排查方式是：

ss -lntp | grep 1688

发现是被自己上一次启动失败后残留的进程占用了端口。处理办法是先看残留进程，再决定是kill还是等它自然退出。这里不能盲目kill -9，因为数据库进程可能正在做恢复，强制干掉会留下更复杂的启动状态。正确做法是用自带的停止命令，如果停止不了再考虑信号处理。

确认端口释放后重新启动，这次状态正常。之后我学乖了，启动脚本里加了一句每次启动前先检查端口占用。

6.3 远程连接超时，防火墙和监听地址一起改

数据库主机上本地用yasql连接是好的，换到另一台机器用 JDBC 连接就超时。排查顺序是这样：

1. ping主机，网络通
2. telnet ip 1688，结果显示不通
3. firewall-cmd --list-all，发现防火墙没放行
4. 放行端口后再试，还是不通
5. 检查监听配置，发现监听地址绑定了回环地址
6. 改监听地址，重启实例，远程连接成功

这个案例很有代表性。很多时候大家只查防火墙，忘了监听地址这个变量。用户态的问题和系统态的问题重叠在一起时，按网络栈从外到内、从下到上排查最有效率。

6.4 32G 内存初始化报 Cannot allocate memory

初始化时指定了--memory-size 32G，结果报无法分配内存。物理内存明明有 64G，为什么不够？原因就是前面提的memlock限制。执行：

ulimit -l

如果显示不是unlimited，那就是内存锁限制没放开。去/etc/security/limits.conf补上：

yasdb soft memlock unlimited yasdb hard memlock unlimited

重新登录用户后再跑初始化，问题解决。这个坑在国产数据库里很常见，也不只 YashanDB 一家，装过 OpenGauss、Doris 这类内存敏感型组件的同事应该都遇到过类似场景。

6.5 常见问题速查表

最后再分享一个小技巧

所有安装部署流程跑完，最后我会用三条命令“自检”整套环境是不是干净的：

yasdb status yasql sys/password@127.0.0.1:1688 -e "select 1 from dual;" systemctl is-enabled yashandb

如果 alias 和 systemd 都是 enabled，再检查一遍授权文件和磁盘空间，基本就能放心的进入后续的数据库初始化和业务配置阶段。我在实际练习中的体会是，安装部署这类任务最怕的就是“前面环境一塌糊涂，后面问题连环爆”。只要环境准备阶段按部就班、逐项验证，后面运行起来会意外地顺利。这也是我写这篇记录的原因——把容易翻车的细节提前亮出来，大家少踩坑。希望这些实操记录，能帮到正在备考或正在做国产化数据库适配的你。