oracle数据库启动过程

最新推荐文章于 2024-01-08 23:33:48 发布

转载最新推荐文章于 2024-01-08 23:33:48 发布 · 610 阅读

文章标签：

#oracle

ORACLE管理专栏收录该内容

3 篇文章

订阅专栏

一.单实例未归档数据库（我的是redhat5.5环境安装11g）

官方网站下载的安装脚本，安装过程中没有修改

1.创建用户组以及授权动作

mkdir -p /u01/app/oracle/product
[root@localhost ~]# mkdir -p /u01/app/oraInventory
[root@localhost ~]# chown -R oracle.oinstall /u01
[root@localhost ~]# chown oracle.dba /u01
[root@localhost ~]# chmod -R 775 /u01

 
 2.检查rpm包，没有好的检查方法，命令不熟悉，之后编辑

 
 3.#vi /etc/sysctl.conf （在配置文件后，将下面的全部粘贴到文件的最后，其实不是修改，是增加）

  kernel.shmall = 268435456
 
 fs.file-max = 6553600
 
 fs.aio-max-nr = 1048576
 
 fs.file-max = 6815744
 
 kernel.shmall = 2097152
 
 kernel.shmmax = 536870912
 
 kernel.shmmni = 4096
 
 kernel.sem = 250 32000 100 128
 
 net.ipv4.ip_local_port_range = 9000 65500
 
 net.core.rmem_default = 262144
 
 net.core.rmem_max = 4194304
 
 net.core.wmem_default = 262144
 
 net.core.wmem_max = 1048586

 
 使修改生效 sysctl 
 -
 p

 4.设置oracle用户的shell limit    （为了提高在linux系统上运行软件的性能，必须对oracle用户设置下列限定。）

#vi /etc/security/limits.conf      

oracle soft nproc 2047

oracle hard nproc 16384

oracle soft nofile 1024

oracle hard nofile 65536

接下来更改/etc/pam.d/login文件，添加下面的内容，使shell limit生效：

（以下并没有执行）
#vi /etc/pam.d/login

session                  required                pam_limits.so
   
 5.上传并安装

  在dbca建库的时候，好像前面安装oracle软件的时候有指定数据库名为abby，之后建库的时候实例名与globlename与sid都必须是abby，不然启动的时候会报错，找不到参数文件，而你明明建库没有报错，建库的参数文件名与启动数据库的参数文件名不一致导致启动报错，还有就是一开始内核参数没有修改，导致需要重新安装oracle软件（一开始没有报错就以为安装成功了，应该是安装成功了，只是后面建库的时候没有使用abby作为实例名而已，下次需要重现问题）。

  以下是删除oracle软件需要做的：（只是删除了对应的目录然后重启即可，具体原理，以后解答，或者大神帮忙解答）

  在Linux下卸载Oracle 11g
 
  1.使用SQL*PLUS停止数据库
 
  [oracle@OracleTest oracle]$ sqlplus /nolog
 
  SQL> connect / as sysdba
 
  SQL> shutdown [immediate]
 
  SQL> exit
 
  2.停止Listener
 
  [oracle@OracleTest oracle]$ lsnrctl stop
 
  3.停止HTTP服务
 
  [root@OracleTest /root]# service httpd stop
 
  3.停止HTTP服务
 
  [root@OracleTest /root]# service httpd stop
 
  4.用su或者重新登录到root(如想重新安装可以保留oracle用户，省得输入环境变量了)
 
  5.将安装目录删除
 
  [root@OracleTest /root]# rm -rf /u01/app/oracle/
 
  6.将/usr/bin下的文件删除
 
  [root@OracleTest /root]# rm /usr/local/bin/dbhome
 
  [root@OracleTest /root]# rm /usr/local/bin/oraenv
 
  [root@OracleTest /root]# rm /usr/local/bin/coraenv
 
  7.将/etc/oratab删除
 
  [root@OracleTest /root]# rm /etc/oratab
 
  8.将/etc/oraInst.loc删除
 
  [root@OracleTest /root]# rm /etc/oraInst.loc
 
  9.将oracle用户删除(若要重新安装,可以不删除)
 
  [root@OracleTest /root]# userdel –r oracle
 
  10.将用户组删除(若要重新安装,可以不删除)
 
  [root@OracleTest /root]# groupdel oinstall
 
  [root@OracleTest /root]# groupdel dba
 
  11.将启动服务删除
 
  [root@OracleTest /root]# chkconfig --del dbora
 
  到此为止重启后，你的Linux系统下的Oracle数据库已完全删除了！！！
 
  以上是CentOS5.4+Oracle 11g的环境。
 
  如果要再次安装， 最好先做一些备份工作。
 
  包括用户的登录脚本，数据库自动启动关闭的脚本，和Listener自动启动的脚本。
 
  要是有可能连创建数据库的脚本也保存下来。

  以下是上述问题解决后数据库实例启动过程：

[oracle@localhost trace]$ tail -f alert_abby.log 
Wed Aug 31 22:00:21 2016
Setting Resource Manager plan SCHEDULER[0x3005]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Wed Aug 31 22:00:21 2016
Starting background process VKRM
Wed Aug 31 22:00:21 2016
VKRM started with pid=34, OS id=1451 
Wed Aug 31 22:00:31 2016
Begin automatic SQL Tuning Advisor run for special tuning task  "SYS_AUTO_SQL_TUNING_TASK"
End automatic SQL Tuning Advisor run for special tuning task  "SYS_AUTO_SQL_TUNING_TASK"
Thu Sep 01 04:37:06 2016
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =27
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile /u01/app/oracle/product/11.2.0.1/db/db_home/dbs/spfileabby.ora
System parameters with non-default values:
  processes                = 150
  memory_target            = 948M
  control_files            = "/u01/app/oracle/oradata/abby/control01.ctl"
  control_files            = "/u01/app/oracle/flash_recovery_area/abby/control02.ctl"
  db_block_size            = 8192
  compatible               = "11.2.0.0.0"
  db_recovery_file_dest    = "/u01/app/oracle/flash_recovery_area"
  db_recovery_file_dest_size= 3852M
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=abbyXDB)"
  audit_file_dest          = "/u01/app/oracle/admin/abby/adump"
  audit_trail              = "DB"
  db_name                  = "abby"
  open_cursors             = 300
  diagnostic_dest          = "/u01/app/oracle"
Thu Sep 01 04:37:13 2016
PMON started with pid=2, OS id=4467 
Thu Sep 01 04:37:13 2016
VKTM started with pid=3, OS id=4469 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Thu Sep 01 04:37:13 2016
GEN0 started with pid=4, OS id=4473 
Thu Sep 01 04:37:14 2016
DIAG started with pid=5, OS id=4475 
Thu Sep 01 04:37:14 2016
DBRM started with pid=6, OS id=4477 
Thu Sep 01 04:37:14 2016
DIA0 started with pid=8, OS id=4481 
Thu Sep 01 04:37:14 2016
PSP0 started with pid=7, OS id=4479 
Thu Sep 01 04:37:14 2016
MMAN started with pid=9, OS id=4483 
Thu Sep 01 04:37:14 2016
DBW0 started with pid=10, OS id=4485 
Thu Sep 01 04:37:14 2016
LGWR started with pid=11, OS id=4487 
Thu Sep 01 04:37:14 2016
CKPT started with pid=12, OS id=4489 
Thu Sep 01 04:37:14 2016
SMON started with pid=13, OS id=4491 
Thu Sep 01 04:37:14 2016
RECO started with pid=14, OS id=4493 
Thu Sep 01 04:37:15 2016
MMON started with pid=15, OS id=4495 
Thu Sep 01 04:37:15 2016
MMNL started with pid=16, OS id=4497 
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01/app/oracle
Thu Sep 01 04:50:30 2016
alter database mount
Thu Sep 01 04:50:35 2016
Successful mount of redo thread 1, with mount id 2625743062
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database mount
Thu Sep 01 04:52:25 2016
alter database open
Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
 read 15720 KB redo, 2124 data blocks need recovery
Started redo application at
 Thread 1: logseq 6, block 27856
Recovery of Online Redo Log: Thread 1 Group 3 Seq 6 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/abby/redo03.log
Completed redo application of 11.60MB
Thu Sep 01 04:52:37 2016
Completed crash recovery at
 Thread 1: logseq 6, block 59297, scn 859451
 2124 data blocks read, 2124 data blocks written, 15720 redo k-bytes read
Thu Sep 01 04:52:37 2016
Thread 1 advanced to log sequence 7 (thread open)
Thread 1 opened at log sequence 7
  Current log# 1 seq# 7 mem# 0: /u01/app/oracle/oradata/abby/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu Sep 01 04:52:37 2016
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Thu Sep 01 04:52:43 2016
QMNC started with pid=20, OS id=4736 
Thu Sep 01 04:52:47 2016
Completed: alter database open
Thu Sep 01 04:52:49 2016
Starting background process CJQ0
Thu Sep 01 04:52:49 2016
CJQ0 started with pid=26, OS id=4752 
Thu Sep 01 04:52:51 2016
db_recovery_file_dest_size of 3852 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.