https://www.cnblogs.com/dbcrazy/p/10877369.html
重要提示:
DevOps
容器默认不启动init进程的,导致centos7中执行systemctl时会出现如下错误:
1 |
Failed to get D-Bus connection: Operation not permitted |
其实,systemctl完全可以通过参考配置文件,启动命令就行,当试图去写一个脚本替换掉systemctl时,发现已经有人做了:https://github.com/gdraheim/docker-systemctl-replacement
把这里的systemctl.py 替换掉systemctl命令即可。
另外,虽然我们可以直接使用systemctl了,但是,某些工具未必能,如: ansible service模块,timedatectl。
ansible service模块还会参考是否存在目录 /run/systemd/system 。 可以手动创建该目录将其欺骗。
centos7容器修改时区:
1 |
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && <span class="hljs-built_in">echo</span> <span class="hljs-string">"Asia/Shanghai"</span> > /etc/timezone |
/usr/share/zoneinfo/Asia/Shanghai 和 /etc/localtime 并不属于相同的rpm包,前者属于: tzdata 后者属于: systemd
Operation not allowed for reason code reason-code on table table-name.
Explanation: Access to table table-name is restricted. The cause is based on the following reason codes reason-code: 7
The table is in the reorg pending state. This can occur after an ALTER TABLE statement containing a REORG-recommended operation.7
Reorganize the table using the REORG TABLE command (note that INPLACE REORG TABLE is not allowed for a table that is in the reorg pending state).
其中:
reorg table <tablename> 通过重构行来消除“碎片”数据并压缩信息,对表进行重组。
runstats on table <tbschema>.<tbname> 收集表 <tbname> 的统计信息。
reorgchk on table all 确定是否需要对表进行重组,对于对所有表自动执行 runstats 很有用。
>>> reorg 和runstats 都是单个表优化,初始化的命令:
runstats on table administrator.test;
reorg table administrator.test;
我使用openldap仅仅是几十条数据用于测试,但是,docker版本的openldap却启动后就占用 725MB的内存,显然不太合理,尤其是跑在我的笔记本上的,更不能如此的浪费,查了一下,相关讨论: https://github.com/nickstenning/docker-slapd/issues/8
解决办法:
1 |
ulimit -n 1024 |
原值是: 1048576。 然后,重启slapd,内存使用为5MB,一下子省去了700+MB的内存,简直太好了,当然,我是虚拟机中使用的,要重启虚拟机才能释放给系统使用。
1 2 |
fact_caching = jsonfile fact_caching_connection = /tmp/ansible_facts_cachedir |
1 2 3 |
fact_caching_timeout = 86400 fact_caching = redis fact_caching_connection = 127.0.0.1:6379 |
1 2 3 4 5 6 7 8 9 10 |
- hosts: all tasks: - name: Install mlocate yum: name=mlocate state=installed - name: Run updatedb command: /usr/bin/updatedb async: 300 poll: 10 |
查看单个用户最大进程数量:
1 |
lsattr -El sys0|grep maxuproc |
修改单个用户最大进程数量:
1 |
chdev -l sys0 -a maxuproc=256 |
首先,在安装目录find db2icrt;
db2icrt 需要指定db2fenc账号和实例账号,而且,这些账号不会自动创建,需要事先创建:
1 2 |
useradd db2inst3 -g 102 passwd db2inst3 #修改密码 |
创建实例: (命令是在/opt/ibm/db2/V11.1/instance 下面的,默认没有在path目录中)
1 |
./db2icrt -u db2inst3 db2inst3 |
db2 create 的数据库默认在db2实例账户的家目录下的。
1 |
/home/db2inst3/db2inst3 |
启动实例:
1 2 3 |
su - db2inst3 db2start |
db2 实例名也不能多于8个字符(直到db2 11 中依然如此),哎
创建实例的时候,会自动往 /etc/services 中注册一个条目, 如: (不知道这个是如何选择到50001端口的,这是是因为另一个实例已经占用了 50000端口)
db2c_db2ist11 50001/tcp
创建实例时并不立即生成实例相关目录,只是在实例用户的目录中生成了sqllib目录,甚至在db2start后,都并不产生数据库的目录的。
DB2 11.5 的容器镜像,启动的时候,自动创建了数据库TESTDB, 但是没有自动启动DB2 manager,进入db2inst1账号后,由于db2admin没有在PATH里面,db2start会失败,所以,将路径 /opt/ibm/db2/V11.5/das/bin 假如到PATH 后,db2start可以正常启动,但是,db2 connect to testdb 时,就会报错,然后db2 manager进程就退出了。
然而,也找不到哪里有有用的错误日志。
db2 manager启动的时候,数据库本身并没有启动,可以激活数据库,也可以第一次connect to 数据库的时候自动激活,目前的情况就是第一次连接的时候失败,应该就是因为数据库启动失败
先怀疑一下:
检查:
db2 get db cfg for testdb
日志文件存储需求: 1024 * 4K * (13+12) = 100MB ;
这个完全没有问题。
内存需求: 1237664 * 4K = 4.8GB ,然而,我的容器限制的是2GB的内存
修改内存需求配置:
1 |
db2 update db cfg for testdb using DATABASE_MEMORY 4096 |
修改后: 4096*4KB= 16MB (这个是非常小的,这里仅仅是快速测试一下是不是内存问题导致的失败,所以,随便写了一个很小的值)
再次测试,发现连接数据库正常了
总结:
问题:
DB2中记录了sql的执行次数和平均时长,执行总时长以及CPU时间。
但是,这些数据是多长时间内的呢?