Paperxie AI学术图表生成实战：从Visio手动绘图到自然语言出图
2026/10/15 4:56:58
简介：这份文档面向华为视讯管理系统SMC2.0的部署与运维人员，聚焦单机环境下操作系统与数据库的选型及安装问题。内容覆盖Windows Server 2012 R2、2016、2019三个版本分别搭配SQL Server 2014、2016、2019 Express的完整安装流程，并给出SQL Server 2008 Express SP2升级至2014 Express SP2的数据迁移与兼容性验证方法，同时整理了数据库管理工具的使用要点。资源包为1个docx文件，约11.66MB，以图文步骤形式呈现，便于对照操作。文档还专设典型安装升级失败FAQ章节，涵盖不支持当前操作系统、安装到9%报错、VC2017依赖安装失败、Net服务未启动、数据库连接超时、导入证书失败等十余类常见故障的排查思路，并附有操作系统与SMC对应推荐版本附录。目前已有749人学习下载，适合需要快速完成SMC2.0环境搭建、减少部署踩坑的技术人员参考。
1. 单机 SMC2.0 部署：为什么“一台机器装完就能跑”反而是最容易翻车的场景
单机 SMC2.0 操作系统和数据库安装指导，这个标题背后其实是一类非常典型的交付场景：客户只给一台物理机或者一台虚拟机，要求把 SMC2.0 整套服务端连同数据库全部塞进去，装完能登录、能建库、能跑业务。很多人第一反应是“单机还不简单，一路 next 就完了”，但真正在一线做过交付的都知道，单机部署的翻车率反而比集群高——因为集群里每个组件职责单一，而单机把所有矛盾都压在一台机器上：操作系统内核参数、文件句柄、数据库字符集、时区、SELinux、防火墙、磁盘分区，任何一项没对齐，最后都会以“服务起不来”或者“连不上数据库”这种模糊现象暴露出来。
这篇文章面向的是需要独立完成 SMC2.0 单机交付的运维和实施人员，也适合想在自己实验环境里复现一套完整服务端的开发者。我会按“操作系统准备 → 数据库安装 → SMC2.0 对接 → 排错”的顺序，把每一步的命令、参数含义和判断标准讲清楚，让你照着做能跑通，遇到报错知道往哪看。整套流程在常见的企业级 Linux 发行版上验证过，具体版本以你手头拿到的安装介质为准，不要盲目套用网上抄来的参数。
2. 操作系统层：装库之前必须锁死的六项配置
2.1 分区方案怎么定：别让 /var 和 /tmp 拖垮数据库
单机部署最容易被忽视的就是分区。很多人装系统时直接选“自动分区”，结果根分区只有 50G，数据库数据目录一涨就满，服务直接挂死。我的习惯是手动分区，至少把下面几个挂载点独立出来：
| 挂载点 | 建议容量 | 说明 |
|---|---|---|
| / | 50G | 只放系统和 SMC2.0 程序，不存数据 |
| /var | 100G 起 | 数据库日志、系统日志都在这，涨得最快 |
| /tmp | 20G | 安装过程临时文件，独立避免撑爆根分区 |
| /data | 剩余全部 | 数据库数据目录，单独挂载方便扩容和备份 |
| swap | 物理内存的 1~2 倍 | 内存小于 64G 时保留，大于 64G 可给 16G |
分区时用xfs文件系统，这是目前企业级发行版对数据库支持最稳的选择。格式化命令示例：
# 假设数据盘是 /dev/sdb，创建 xfs 并挂到 /data mkfs.xfs -f /dev/sdb mkdir -p /data echo "/dev/sdb /data xfs defaults,noatime 0 0" >> /etc/fstab mount -a df -h /datanoatime参数的作用是关闭文件访问时间记录，数据库这种高频读写场景下能减少大量无谓的元数据写入。挂载后用df -h确认容量和挂载点正确，再继续下一步。
2.2 内核参数：数据库能不能扛住并发就看这几个值
数据库对内核参数非常敏感，尤其是共享内存和文件句柄。默认值在单机高并发下几乎必然不够。把下面内容写进/etc/sysctl.d/99-smc.conf：
# 共享内存段最大值，按物理内存的 70% 估算，单位字节 kernel.shmmax = 68719476736 # 共享内存页数，shmmax / 4096 向上取整 kernel.shmall = 16777216 # 系统级文件句柄上限 fs.file-max = 6815744 # 单进程可打开文件数 fs.nr_open = 1048576 # 网络连接队列，避免高并发时丢连接 net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 # 端口回收，短连接多时有用 net.ipv4.tcp_tw_reuse = 1执行sysctl -p /etc/sysctl.d/99-smc.conf生效。这里kernel.shmmax是最关键的，设小了数据库启动时会报“无法分配共享内存”。如果你不确定物理内存大小，先用free -b看总内存，再按 70% 算。注意shmall的单位是页，不是字节，很多人在这里填错导致参数不生效。
2.3 用户与资源限制：别用 root 跑数据库
数据库必须用独立用户运行，这是底线。创建用户和组的命令：
groupadd -g 54321 dbgroup useradd -u 54321 -g dbgroup -m -d /home/dbuser -s /bin/bash dbuser echo "dbuser:YourPassword" | chpasswd然后配置资源限制，编辑/etc/security/limits.d/99-db.conf：
dbuser soft nofile 1048576 dbuser hard nofile 1048576 dbuser soft nproc 65536 dbuser hard nproc 65536 dbuser soft memlock unlimited dbuser hard memlock unlimitedmemlock unlimited是给数据库锁定内存用的，不设的话某些数据库在内存紧张时会被 OOM killer 干掉。改完用su - dbuser切换过去，执行ulimit -a确认open files和max locked memory已经变成新值。注意 limits 配置对已经登录的会话不生效，必须重新登录。
2.4 关闭干扰项：SELinux、防火墙、透明大页
这三样是单机部署里最常见的“玄学故障源”。SELinux 会拦截数据库对数据目录的访问，防火墙会挡住 SMC2.0 和数据库之间的端口，透明大页会导致数据库出现不可预测的延迟抖动。
# 临时关闭 SELinux setenforce 0 # 永久关闭，改配置文件 sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config # 关闭防火墙并禁用开机自启（内网环境常见做法，公网环境请按需放行端口） systemctl stop firewalld systemctl disable firewalld # 关闭透明大页 echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag透明大页的关闭要写进开机脚本，否则重启就失效。可以在/etc/rc.local里加上述两行，并确保该文件有执行权限。做完用getenforce、systemctl status firewalld、cat /sys/kernel/mm/transparent_hugepage/enabled三个命令逐一确认。
2.5 时区与字符集：装完再改代价极大
时区不对会导致数据库日志时间和业务时间对不上，排查问题时完全没法关联。字符集不对则会在建库后才发现中文乱码，那时候改就得重建库。
# 设置时区为东八区 timedatectl set-timezone Asia/Shanghai timedatectl status # 确认系统字符集 localectl set-locale LANG=en_US.UTF-8 localectl status字符集建议用en_US.UTF-8，既支持中文又避免排序规则上的坑。数据库初始化时也要显式指定同样的字符集，两边必须一致，否则 SMC2.0 写入的中文数据在数据库里就是问号。
2.6 依赖包检查：缺一个 libaio 就够你查半天
数据库安装程序通常依赖libaio、libaio-devel、bc、binutils、compat-libcap1等包。在离线环境里这些包不会自动装，必须提前准备好。
# 检查关键依赖是否已安装 rpm -q libaio libaio-devel bc binutils compat-libcap1 # 如果有缺失，用本地源安装 yum install -y libaio libaio-devel bc binutils如果rpm -q返回“package xxx is not installed”，就去安装介质的 Packages 目录里找对应 rpm 手动装。这一步偷懒，后面数据库安装程序会在 99% 的时候报一个看不懂的链接错误。
3. 数据库安装：从静默建库到连接验证
3.1 安装方式选择：图形化还是静默
数据库安装一般有两种方式：图形化安装和静默安装。图形化适合第一次装、想看清楚每一步的人，但需要 X11 转发或者本机有桌面环境，在纯命令行服务器上很麻烦。静默安装靠一个响应文件驱动，适合批量交付和远程操作，也是我推荐的方式。
静默安装的核心是准备一个响应文件，里面预先填好安装路径、数据目录、字符集、内存参数等。不同数据库产品的响应文件格式不同，但思路一致：把图形界面里要点的选项全部写成键值对。下面以某企业级数据库的典型响应文件片段为例：
# 响应文件关键项示例（字段名以实际产品文档为准） UNIX_GROUP_NAME=dbgroup INVENTORY_LOCATION=/data/oraInventory ORACLE_HOME=/data/dbhome ORACLE_BASE=/data/dbbase oracle.install.db.InstallEdition=EE oracle.install.db.characterSet=AL32UTF8 oracle.install.db.DBA_GROUP=dbgroup字段含义：INVENTORY_LOCATION是安装清单目录，ORACLE_HOME是数据库软件安装路径，characterSet必须和操作系统字符集对齐。执行静默安装前，先用-silent -responseFile参数跑一遍检查：
./runInstaller -silent -responseFile /home/dbuser/db.rsp -ignorePrereq -waitforcompletion-ignorePrereq是跳过前置检查，只在确认系统配置已手动满足时使用，否则可能装到一半失败。安装完成后按提示用 root 执行root.sh脚本，这一步会注册系统服务。
3.2 建库参数：内存和连接数怎么给
建库时最容易拍脑袋的就是内存参数。单机场景下数据库要和 SMC2.0 抢内存，给多了 SMC2.0 卡，给少了数据库慢。我的经验是：数据库内存不超过物理内存的 50%，SMC2.0 的 JVM 堆占 25%，剩下留给操作系统和文件缓存。
建库命令示例（以 dbca 静默建库为例）：
dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName smcdb \ -sid smcdb \ -characterSet AL32UTF8 \ -memoryPercentage 50 \ -totalMemory 32768 \ -emConfiguration NONE \ -datafileDestination /data/oradata \ -redoLogFileSize 1024 \ -sysPassword YourSysPwd \ -systemPassword YourSysPwd-memoryPercentage 50表示使用物理内存的 50%，-totalMemory是显式指定总内存（单位 MB），两者取其一即可。-characterSet AL32UTF8必须和系统en_US.UTF-8对应。-emConfiguration NONE是关掉企业管理器，单机交付用不上还占资源。建库过程会持续十几分钟，期间可以用tail -f跟踪日志确认没有报错。
3.3 监听与连接串：SMC2.0 要连的地址写对了吗
数据库建好后要确认监听正常，并且 SMC2.0 能通过连接串连上。先看监听状态：
lsnrctl status # 确认监听端口，默认 1521 netstat -tlnp | grep 1521然后用数据库自带客户端测试连接：
sqlplus system/YourSysPwd@//127.0.0.1:1521/smcdb能进 SQL 提示符就说明数据库本身没问题。接下来在数据库里为 SMC2.0 创建独立用户和表空间：
-- 创建表空间，数据文件放 /data/oradata CREATE TABLESPACE smc_data DATAFILE '/data/oradata/smc_data01.dbf' SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 100G; -- 创建用户并授权 CREATE USER smcuser IDENTIFIED BY YourSmcPwd DEFAULT TABLESPACE smc_data; GRANT CONNECT, RESOURCE, DBA TO smcuser;AUTOEXTEND ON让数据文件在写满后自动扩展，避免半夜因为表空间满导致业务中断。MAXSIZE设一个上限，防止单个文件无限膨胀把磁盘撑爆。授权按最小权限原则，实际生产里不建议直接给 DBA，这里为了首次跑通先给足，后续再收紧。
3.4 验证清单：装完必须逐项打勾
数据库装完不要急着装 SMC2.0，先按下面清单逐项确认：
| 检查项 | 命令 | 预期结果 |
|---|---|---|
| 监听状态 | lsnrctl status | READY |
| 实例状态 | sqlplus -S / as sysdba后select status from v$instance; | OPEN |
| 字符集 | select value from nls_database_parameters where parameter='NLS_CHARACTERSET'; | AL32UTF8 |
| 表空间 | select tablespace_name, bytes/1024/1024 mb from dba_data_files; | 有 smc_data |
| 用户可登录 | sqlplus smcuser/YourSmcPwd@//127.0.0.1:1521/smcdb | 成功进入 |
| 时区 | select dbtimezone from dual; | +08:00 |
任何一项不符合，先解决再往下走。尤其是字符集和时区，装完 SMC2.0 再回头改，成本翻十倍。
4. SMC2.0 对接数据库：配置项与启动顺序
4.1 配置文件里必须改的四个地方
SMC2.0 的数据库连接信息通常集中在一个配置文件里，常见的是application.properties或dbconfig.xml这类。需要改的核心项有四个：连接地址、端口、库名、账号密码。以 properties 格式为例：
# 数据库连接配置 spring.datasource.url=jdbc:oracle:thin:@127.0.0.1:1521/smcdb spring.datasource.username=smcuser spring.datasource.password=YourSmcPwd spring.datasource.driver-class-name=oracle.jdbc.OracleDriver # 连接池参数 spring.datasource.hikari.maximum-pool-size=50 spring.datasource.hikari.minimum-idle=10 spring.datasource.hikari.connection-timeout=30000maximum-pool-size是连接池上限，单机场景下不要超过数据库processes参数的 70%，否则数据库侧连接数不够会报错。connection-timeout是获取连接的超时时间，设太短在网络抖动时容易误报，30 秒是稳妥值。改完配置后不要直接启动，先用一个小工具验证连接串本身是通的。
4.2 启动顺序与依赖检查
SMC2.0 启动前必须确保数据库已经处于 OPEN 状态，否则应用启动时会因为连不上库直接退出。正确的顺序是：先确认监听和实例，再启动 SMC2.0。
# 1. 确认数据库实例状态 su - dbuser -c "sqlplus -S / as sysdba <<EOF select status from v\$instance; exit EOF" # 2. 确认监听端口可连 nc -zv 127.0.0.1 1521 # 3. 启动 SMC2.0 服务 systemctl start smc2.service systemctl status smc2.service如果systemctl status显示active (running)但日志里有数据库连接异常，用journalctl -u smc2.service -n 200看最近 200 行日志。常见的是密码里含有特殊字符导致配置文件解析出错，这时候把密码用引号包起来再试。
4.3 首次登录与初始化数据
服务起来后，用浏览器访问 SMC2.0 的登录页面，默认端口和初始账号在安装介质的说明文件里。首次登录通常会触发初始化建表，这个过程会往数据库里写大量数据，期间不要刷新页面或重启服务。
初始化完成后，在数据库侧确认表已经建出来：
-- 统计 smcuser 下的表数量 select count(*) from user_tables; -- 查看最近创建的表 select table_name, created from user_tables order by created desc fetch first 10 rows only;如果表数量为 0，说明初始化没成功，回到 SMC2.0 日志里找SQLException关键字。多数情况是用户权限不够，比如缺少CREATE TABLE权限，补授权后重启服务再试。
5. 避坑与排查：单机部署最常见的五个翻车点
5.1 数据库启动报“共享内存不足”
现象：数据库实例启动到 mount 阶段就失败，日志里写ORA-27102: out of memory或类似提示。
原因：kernel.shmmax和kernel.shmall设置过小，或者memlock限制没放开。单机部署时如果物理内存很大但 shmmax 还是默认值，必然触发。
解决：用free -b看总内存，把kernel.shmmax设为总内存的 70%，kernel.shmall设为shmmax/4096。同时确认/etc/security/limits.d/里 dbuser 的memlock是 unlimited，改完重启系统或重新登录会话。
5.2 SMC2.0 连库报“IO 错误：网络适配器无法建立连接”
现象：SMC2.0 启动日志里反复出现连接被拒绝，但手动sqlplus能连上。
原因：监听只绑定了localhost或者只监听了 IPv6，而 SMC2.0 配置里写的是127.0.0.1或主机名，解析到了不同协议栈。
解决：检查listener.ora里的HOST字段，改成0.0.0.0或具体的内网 IP。同时确认/etc/hosts里主机名解析到的是 IPv4 地址，不是::1。改完lsnrctl reload重载监听。
5.3 中文数据写入后变成问号
现象：SMC2.0 界面输入中文能保存，但数据库里查出来是???。
原因：操作系统字符集、数据库字符集、SMC2.0 连接串字符集三者不一致。最常见的是数据库建库时选了ZHS16GBK，而系统是UTF-8。
解决：确认数据库NLS_CHARACTERSET是AL32UTF8，系统locale是en_US.UTF-8，SMC2.0 连接串里加?useUnicode=true&characterEncoding=UTF-8。如果数据库字符集已经错了，只能重建库，没有后悔药。
5.4 服务重启后数据库没自动起来
现象：服务器重启后 SMC2.0 起不来，手动启动数据库后 SMC2.0 才正常。
原因：数据库实例没有配置开机自启，或者自启脚本执行顺序在 SMC2.0 之后。
解决：确认/etc/oratab里实例对应的行末尾是Y而不是N，然后检查systemd里数据库服务的After和Wants依赖。SMC2.0 的服务文件里要加After=oracle.service这类依赖，保证启动顺序。
5.5 磁盘满了导致数据库挂起
现象：业务跑一段时间后数据库无响应，df -h看到/var或/data100%。
原因：数据库归档日志没清理，或者审计日志暴涨。单机部署时/var分区如果给得小，系统日志也能把它撑满。
解决：先清理归档日志释放空间，然后配置归档定期删除策略。/var分区建议至少 100G，并且把数据库审计日志目录单独挂载。临时救急可以用find /var/log -name "*.log" -mtime +7 -delete清理旧日志，但根治要靠监控和定期清理脚本。
6. 进阶技巧：把单机部署做成可重复的脚本
单机部署做多了就会发现，每次手工敲命令既慢又容易漏。我的习惯是把整个流程拆成三个脚本：01_os_prepare.sh负责系统层配置，02_db_install.sh负责静默装库建库，03_smc_deploy.sh负责 SMC2.0 配置和启动。每个脚本开头用set -e让出错即停，关键步骤前用echo打印当前进度，方便定位卡在哪一步。
系统准备脚本里，把内核参数、limits、SELinux、防火墙、时区这些全部写成幂等操作——重复执行不会报错。比如改内核参数用sysctl -w加写配置文件双保险，创建用户前先id dbuser判断是否存在。这样脚本可以在不同机器上反复跑，不用每次手动确认。
数据库安装脚本里，响应文件用变量替换生成，把密码、路径这些敏感信息从脚本里抽出来放到单独的env.sh里，脚本本身可以进版本库，env.sh不进。建库完成后自动跑一遍验证 SQL，把字符集、时区、表空间状态打印出来，不符合预期就退出并提示。
SMC2.0 部署脚本里，配置文件用sed替换占位符，启动后用curl轮询健康检查接口，直到返回 200 才认为部署成功。健康检查接口的路径在安装介质说明里能找到，通常是/actuator/health这类。轮询超时设 300 秒，超时后自动收集日志打包，方便后续排查。
最后说一个我踩过的坑：脚本里所有路径都用绝对路径，不要用相对路径。曾经有个脚本在/root下跑没问题，换到/home下跑就找不到文件，查了半天才发现是相对路径的问题。还有，脚本里的sleep不要写死，用轮询代替，否则机器性能差异会让固定等待时间要么不够要么浪费。这套脚本化思路跑通之后，单机部署从半天缩短到四十分钟，而且每次结果一致，不用再靠记忆去补步骤。希望帮到你。
本文还有配套的精品资源，点击获取