（20190218）安装好 Oracle，没升级，没配置，没创建数据库 没创建用户，基本什么都没干
1、安装Oracle10之前明明是有界面的，但是安装完毕之后，我就重启OS 然后备份虚拟机了，再次进系统发现进度条一直卡住
（1）在开始显示进度条的时候，按"ESC"键，就会显示正在执行什么操作，发现是在 certmonger启动OK(Starting certmonger) 之后就卡在那里了
网上查到原因是：“CentOS启动失败 卡在开机进度条certmonger解决_Linux教程_Linux公社-Linux系统门户网站.html（https://www.linuxidc.com/Linux/2015-02/112688.htm）”
原因分析：X11图形化界面服务引起的，导致开机无法进入图形化界面。
解决办法：
vim /etc/inittab
id:5:initdefault:#把最底行的5改为3，即默认进入命令行操作界面(多用户的命令行操作界面)
进系统后，再执行"startx"启动图形界面
（2）进入命令行界面后，root用户登录 就是登不上去，用户名和PW都正确(有错误它会提示的)，一登进去 就闪回(就回到了登录前的样子，就像没有输入名户名&密码那样)。但是 我用SSH来登录root是OK的。
网上查：“centos6.6输入正确用户名和密码仍跳回登录界面 - u010857476的专栏 - CSDN博客.html（https://blog.csdn.net/u010857476/article/details/44460721）”
我这里是 pam_limits.so文件路径的问题:执行命令“cat /etc/pam.d/login”
[root@CentOS64x64 ~]# cat /etc/pam.d/login #%PAM-1.0 auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so auth include system-auth account required pam_nologin.so account include system-auth password include system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open session required pam_namespace.so session optional pam_keyinit.so force revoke session include system-auth -session optional pam_ck_connector.so #session required /lib/security/pam_limits.so #ZC: 这里的路径不对，我在SSH中执行"find / -name pam_limits.so"，发现只有在"/lib64/security/"下有pam_limits.so文件，于是改成了下面的这一句的样子 session required /lib64/security/pam_limits.so session required pam_limits.so [root@CentOS64x64 ~]#
（3）经过上面的操作，已经可以顺利进入了 命令行，现在 尝试进入图形界面。
字符界面中 root登录，执行命令"startx"，报错“bash :startx command not found”
bash _startx command not found - leoBETT的博客 - CSDN博客.html（https://blog.csdn.net/leoBETT/article/details/82724563）
原因：系统并没有安装桌面
解决方案：
yum groupinstall "X Window System" --> 准备下载安装包，下载前会告诉你安装包大小 --> 输入y确认下载
yum groupinstall "Gnome" --> 准备下载安装包，下载前会告诉你安装包大小 --> 输入y确认下载
输入 startx 启动桌面
ZC：但是我遇到问题：在“yum groupinstall "Gnome"”的时候，提示信息记不全了 大概是 "Group Gnome does not exist"，我以为是 yum的repo要换 于是换成了阿里的，结果还是一样，后来搜索到：
CentOS 启动界面 startx not found - lingdi2000的专栏 - CSDN博客.html（https://blog.csdn.net/lingdi2000/article/details/51376814）
有些新本版的CentOS Gnome 可能改名为 Desktop
如果 yum groupinstall "Gnome" 失败就可以使 换成Desktop试一试
ZC：果然 换成 “yum groupinstall "Desktop"”就OK了
ZC：网上还搜到方式：“为什么centos6.5的终端按ctrl+alt+F7没反应的？进不了图形界面_百度知道.html（https://zhidao.baidu.com/question/360125929395106332.html）”（未使用验证，仅供参考）
yum grouplist 检查已安装的组
yum groupinstall "X Window System"
yum groupinstall "GNOME Desktop Environment"
startx
或 init 5
从图形界面到命令行界面：ctrl + alt +F1(F1到F6）都行，
ZC：貌似 CentOS6：ctrl + alt +F1 默认是图形界面，如果 图形界面是 某个命令行界面startx出来的，图形界面就在 ctrl + alt +F7
2、我在 启动数据库的时候（"SQL> startup"），发现报错：“ORA-27125: unable to create shared memory segment”，搜索到解决方法：“ORA-27125_ unable to create shared memory segment的解决方法(转) - 守护的玉的博客 - CSDN博客.html（https://blog.csdn.net/li951383937/article/details/52844477）”
问题和linux上的hugetbl有关。
解决方法也很简单，首先检查oracle用户的组信息：
[oracle@yans1 ~]$ id oracle
uid=500(oracle) gid=502(oinstall) groups=502(oinstall),501(dba)
[oracle@yans1 ~]$ more /proc/sys/vm/hugetlb_shm_group
0
下面用root执行下面的命令，将dba组添加到系统内核中：
# echo 501 > /proc/sys/vm/hugetlb_shm_group
然后启动数据库，问题消失。
ZC：我是 “uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba)”，于是执行的命令是“# echo 502 > /proc/sys/vm/hugetlb_shm_group” （这里貌似主要是看 "dba"的组id？）
但以上这种方式在重启操作系统后失效， /proc/sys/vm/hugetlb_shm_group又变为了0，建议采用以下方式解决：
加入vm.hugetlb_shm_group = 501 到/etc/sysctl.conf中来解决：
# vi /etc/sysctl.conf
加入如下的内容，其中501为dba组号，需要根据你实际的情况进行改变。
vm.hugetlb_shm_group = 501
# sysctl -p
那么hugetlb_shm_group组是什么呢？以下是解释：
hugetlb_shm_group contains group id that is allowed to create SysV shared memory segment using hugetlb page
这里反复提到了HugePage，以下是关于HugePage的说明和解释：
When a process uses some memory, the CPU is marking the RAM as used by that process. For efficiency, the CPU allocate RAM by chunks of 4K bytes (it's the default value on many platforms). Those chunks are named pages. Those pages can be swapped to disk, etc.
Since the process address space are virtual, the CPU and the operating system have to remember which page belong to which process, and where it is stored. Obviously, the more pages you have, the more time it takes to find where the memory is mapped. When a process uses 1GB of memory, that's 262144 entries to look up (1GB / 4K). If one Page Table Entry consume 8bytes, that's 2MB (262144 * 8) to look-up.
Most current CPU architectures support bigger pages (so the CPU/OS have less entries to look-up), those are named Huge pages (on Linux), Super Pages (on BSD) or Large Pages (on Windows), but it all the same thing.
1、
2、
3、
4、
5、