月度归档：2020年06月

生活

20200630生活感想

1、2020年一半结束了，想想做了些什么
2、有次健身练完，健身房的教练又要叫我买课，拉着我聊了一个小时。不想花钱了，已经买了30节课，不少了，这样下去没底
3、买防晒衣，去了线下店饰梦乐，看中一件128，但是没舍得买，后来淘宝上买了一件68的，做工、材质都比128的差多了
4、买盗版潮牌，淘宝上165买了一件T恤，后来发现官网相同图案是长袖，盗版的是短袖，真让人贻笑大方。算了，自己家里穿吧

ORACLE

Oracle缩小表空间大小

1、碎片整理
合并表空间的碎片增加表空间的连续性
alter tablespace POSP_DATA coalesce;

2、缩小表空间大小
大小不能小于数据文件中的所处的最大位置
alter database datafile '/oradata/posp/posp_data16.dbf' RESIZE 2048M;

3、查询表空间使用率
select a.tablespace_name as tablespace, total, free,(total-free) as usage from
(select tablespace_name, sum(bytes)/1024/1024 as total from dba_data_files group by tablespace_name) a,
(select tablespace_name, sum(bytes)/1024/1024 as free from dba_free_space group by tablespace_name) b
where a.tablespace_name = b.tablespace_name;

TABLESPACE TOTAL FREE USAGE
--------------------
SYSAUX 980 48.6875 931.3125
UNDOTBS1 250 218.75 31.25
POSP_DATA 32768 31643.875 1124.125
USERS 5 3.6875 1.3125
SYSTEM 1730 7.1875 1722.8125
POSP_IDX 4096 3999.8125 96.1875

ORACLE

Oracle重建控制文件

数据库启动报错：
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
原因为控制文件损坏，之前清理文件的时候误删了，无奈网上找了个文章硬着头皮上，重建控制文件

1、查询数据库版本
SQL> select * from v$version;

BANNER
--------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE 11.2.0.4.0 Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production

2、查询控制文件位置
SQL> show parameter control_files
NAME TYPE VALUE
--------------------
control_files string /oradata/posp/control01.ctl, /oracle/app/oracle/fast_recovery_area/posp/control02.ctl

3、删除控制文件
rm /oradata/posp/control01.ctl
rm /oracle/app/oracle/fast_recovery_area/posp/control02.ctl

4、启动
SQL> shutdown abort;
SQL> startup nomount;

5、查询语言
SQL> select userenv('language') from dual;
USERENV('LANGUAGE')
--------------------
AMERICAN_AMERICA.US7ASCII

继续阅读Oracle重建控制文件 →
LINUX

npm私服搭建verdaccio

verdaccio是管理npm包的私服，类似于maven私服吧。自己开发的包可以放上去，也可以作为公共包的缓存，本地没有再到中央库去拉

1、安装node.js
略过

2、安装verdaccio
npm install -g verdaccio

3、启动服务
1）启动
verdaccio -l 0.0.0.0:4873
*** WARNING: Verdaccio doesn't need superuser privileges. Don't run it under root! ***
warn --- config file - /root/.config/verdaccio/config.yaml
warn --- Verdaccio started
warn --- Plugin successfully loaded: verdaccio-htpasswd
warn --- Plugin successfully loaded: verdaccio-audit
warn --- http address - http://0.0.0.0:4873/ - verdaccio/4.7.2
外网可以通过http://IP:4873来访问了，但是现在只是运行在控制台上，日志也是往控制台打的
2）添加配置
vi /root/.config/verdaccio/config.yaml
在最后加入：
listen: 0.0.0.0:4873

继续阅读npm私服搭建verdaccio →
LINUX

CentOS7日志管理工具journal

CentOS7的systemd使用journal来记录管理日志，journal记录的日志为二进制格式，可以通过管理工具维护。对应的服务为systemd-journald
你会发现在/var/log/下少了很多日志文件，而/var/log/journal占用了大量的磁盘空间

1、查看服务
[root@docker log]# systemctl status systemd-journald.service
● systemd-journald.service - Journal Service
Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
Active: active (running) since 五 2020-06-26 03:38:23 UTC; 1 day 11h ago
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 79 (systemd-journal)
Status: "Processing requests…"
Tasks: 1
Memory: 7.0M
CGroup: /system.slice/systemd-journald.service
└─79 /usr/lib/systemd/systemd-journald
6月 19 13:54:37 docker systemd-journal[77]: Journal stopped
6月 19 13:54:52 docker systemd-journal[77]: Runtime journal is using 8.0M (max allowed 307.2M, trying to leave 460.8M free of 2.9G available → current limit 307.2M).
6月 19 13:54:52 docker systemd-journal[77]: Journal started
6月 19 13:54:53 docker systemd-journal[77]: Permanent journal is using 328.0M (max allowed 4.0G, trying to leave 4.0G free of 74.2G available → current limit 4.0G).
6月 19 13:54:53 docker systemd-journal[77]: Time spent on flushing to /var is 56.281ms for 31 entries.
6月 26 03:38:12 docker systemd-journal[77]: Journal stopped
6月 26 03:38:23 docker systemd-journal[79]: Runtime journal is using 8.0M (max allowed 307.2M, trying to leave 460.8M free of 2.9G available → current limit 307.2M).
6月 26 03:38:23 docker systemd-journal[79]: Journal started
6月 26 03:38:24 docker systemd-journal[79]: Permanent journal is using 328.0M (max allowed 4.0G, trying to leave 4.0G free of 47.7G available → current limit 4.0G).
6月 26 03:38:24 docker systemd-journal[79]: Time spent on flushing to /var is 51.714ms for 22 entries.

2、查看使用磁盘空间
[root@docker log]# journalctl --disk-usage
Archived and active journals take up 336.0M on disk.

3、清理命令
格式：
journalctl --vacuum-size=BYTES：保留多大的日志
journalctl --vacuum-time=TIME：移除多久以前的日志
例子：
保留一周的日志
journalctl --vacuum-time=1w
保留500MB的日志
journalctl --vacuum-size=500M

4、查看当前日志
journalctl -f

5、查看指定应用日志
journalctl -xeu httpd

参考资料：
https://www.cnblogs.com/leigepython/p/10302056.html

LINUX

GitLab访问报错：HTTP 502: Whoops, GitLab is taking too much time to respond.

发现一个奇怪的现象，gitlab有时打开报502，多刷几次可以正常打开。所以并不是端口被占用
网上提供了一个分析的方法：
1、gitlab-ctl status
查看进程是否正常启动
2、/var/log/gitlab
下的日志有没有报错
3、gitlab-ctl tail [process name]
查看对应进程的情况

参考资料：
https://www.liangzl.com/get-article-detail-27713.html
https://segmentfault.com/a/1190000017436142

LINUX

rpmdb: BDB0113 Thread/process 9751/139849321973824 failed: BDB1507 Thread died in Berkeley DB library

yum update时报错：
错误：rpmdb: BDB0113 Thread/process 9751/139849321973824 failed: BDB1507 Thread died in Berkeley DB library
错误：db5 错误(-30973) 来自 dbenv->failchk：BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
错误：无法使用 db5 - (-30973) 打开 Packages 索引
错误：无法从 /var/lib/rpm 打开软件包数据库
CRITICAL:yum.main:
Error: rpmdb open failed

解决办法：
cd /var/lib/rpm
rm -rf __db*
rpm --rebuilddb
yum repolist

再执行：
yum update