oracle的nomount,oracle nomount小议

关于数据库的nomount状态的一点信息。

数据库的启动nomount mount open三个状态，其中nomount中今天查看eygle的博客发现后台altersid.log中存在输出了pid和os id两个信息。

pid代表该进程在数据库内部的进程标识符，而os id则代表该进程在操作系统上的进程标识符。

SQL> startup nomount;

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 1223488 bytes

Variable Size 264242368 bytes

Database Buffers 801112064 bytes

Redo Buffers 7163904 bytes

此时先是oracle的sga的分配

然后读取spfile中的参数

System parameters with non-default values:

processes = 300

event = 10046 trace name context forever,level 12

__shared_pool_size = 130023424

shared_pool_size = 67108864

__large_pool_size = 4194304

__java_pool_size = 4194304

__streams_pool_size = 0

resource_manager_plan =

...

PSP0 started with pid=3, OS id=3944

PMON started with pid=2, OS id=4024

MMAN started with pid=4, OS id=456

DBW0 started with pid=5, OS id=640

DBW1 started with pid=6, OS id=2060

DBW2 started with pid=7, OS id=580

....

查看上面的具体的altersid.log中的，可以查看到oracle后台进程和spfile参数来指定，nomount状态启动oracle实例，分配sga和后台进程。

查看上面的关于后台进程中包含pid和os id两个信息，pid就是该oracle后台进程在数据库内部的标识符，os id也就是该后台进程在操作系统上对应的标识符。

select * from v$process

其中有pid=1的进程但是altersid.log中不存在此记录，查看关于eygle的博客中说到pid=1的进程是一个pseundo进程，这个进程被认为是初始化数据库的进程，启动其他进程之前就被启用，并一直存在数据库中。

v$process中的pid也就是altersid.log中提到的后台进程标识符，spid就是该进程对应于os上面的进程标识符，通过spid，数据库的v$process可以和os联系，通俗的说就是pid是oracle内部编排的，spid是oracle内部进程对应于操作系统的。

昨天blog的提到关于latch的解释，今天查看资料发现v$process视图中也存在latchwait和latchspin。

latch作为数据库内存中串行锁机制，主要用来控制内存上的并发获取，资料中提到多个处理器系统上，oracle进程通过spin来进行latch争夺。

v$process中的addr就是该进程的地址，同样在v$session视图中也存在一个paddr，也是存在于session的进程地址。现在通过v$process中的pid和spid把数据库的进程和os上的进程联系，v$process和v$session可以通过v$process的addr和v$session的paddr来联系。

startup nomount

此时oracle数据库只需要一个spfile或者pfile，而且曾经帮助网友们查看数据库的问题中发现很多情况是参数文件有问题，nomount起不来肯定找参数文件，有一部分是spfile文件手动修改导致的，由于spfile是二进制文件，如果手工修改就会损坏此文件

所以我们一般都是alter system set scope=both/spfile来对参数文件修改，上次的一个网友弄的更是郁闷，他的spfile中有个指定background_dump_dest指定的目录在os上面不存在，俺也是看了半天才发现的，最后修改参数的目录然后nomount。

当初也是因为他的报错信息是个乱码，oracle的字符集 ？等问题也是一个比较常见的问题，后面俺专门整理了再晒出来，不然没有乱码，英语好点oracle的报错信息一般都能看出个大概：就是指定目录不存在。

经过帮网友调试后发现spfile究竟需要什么参数就可以启动数据库到nomount了，后来试验只需要db_name，其余的都可以不要，因为需要用db_name来锁定mount状态数据库所需要控制文件。如果不自己试试，肯定不会知道还可以这么玩的。

提到了sid和oracle_sid。网上的解释很多，sid就是oracle数据库的一个识别。用于在用一个oracle_home下用来识别不同的数据库的。

set oracle_sid=test

export oracle_sid=test

在命令模式下最好连接数据库时都指定oracle_sid，这个也就是存在oracle的系统变量，oracle的后台进程都是通过oracle_sid来识别而启动属于此数据库的后台进程的。

但是上面提到了是同一个oracle_base下吗，如果在不同的oracle_base下是可以存在相同的sid的。

通过查看资料：通过Oracle提供的一个小工具sysresv，我们可以找到对应于不同的ORACLE_SID，操作系统上创建的共享内存段ID(Shared Memory)和信号量ID(Semaphores)等信息。

不过俺没有用过sysresv工具，只能把eygle的先记录下来。

instance_name

也就是oracle数据库的实例名，实例是访问oracle数据库的一种方式，没有实例我们无法访问此数据库。instance_name缺省的就是oracle_sid，但是instance_name和oracle_sid是可以不同的，oracle_sid才是识别数据库的，不同的数据库可以拥有相同的instance_name

show parameter instance_name

但是关于v$instance其中的instance_name并不是instance_name而是数据库的实例的sid，也就是一个唯一的识别码了。

alter system set instance_name='test001' scope=spfile

shutdown immediate

startup

select instance_name from v$instance

db_name

实例所挂载的数据库名称，关系到了具体文件，个人在spfile中db_name如果不等于controlfile中的db_name也就无法查找到controlfile，数据库也就无法mount了。

db_name不操作8个字符的文本串，db_name记录在数据文件，日志文件和控制文件，前面的控制文件和db_name挂钩已经清楚了，后面的数据文件和日志文件了，其实从mount到open状态，数据库要通过db_name来查找数据文件和日志文件，咋感觉有点像scn。

一个实例可以打开打开任何数据库，因为实例的启动只需要参数文件，后面的控制文件 日志文件都是后面的mount open的

一个数据库可以被一个或多个实例打开，rac环境下多个实例公用一个数据库

nomount现在俺也就整理这些，至于mount和open状态更多的是涉及到数据库恢复 scn等的情况，陆续会更新关于备份 恢复的篇幅，更多的是从原理上来理解oracle的机制。谢谢了！

[@more@]