标签：
##############启动##############
1、nomount 模式【 加载实例和spfile(参数文件)】
什么是实例？
实例是你去安装oracle，或者跑oracle的一个平台，运行库的话，首先对硬件资源有一定占用，比如说最关键就是内存，加载实例对内存有一定占用，
假如我占用了1G的内存，这1G的内存会不会给别的程序用？？答案肯定是不会的，只有库能使用。硬件资源是在实例下面占有好的。
还有你开启数据库得有一些基本进程，这些进程是在实例下面启动的。
就像生活中你想盖房子，你能随便盖吗？
第1件事就是你要买块地皮，然后盖房子娶媳妇。
第一件事你得有块宅基地吧，然后在上块盖房子，然后才能结婚。
这块地就是实例，你盖的房子就是库，你里面住的人呢就是数据。
路径：cd $ORACLE_HOME/dbs
查看：strings spfile实例.ora【它不是文本文件，是二进制文件】
strings spfile$ORACLE_SID.ora
ecom.__db_cache_size=188743680 【数据缓存大小】
ecom.__java_pool_size=4194304 【JAVA池大小】
ecom.__large_pool_size=4194304 【大池大小】
ecom.__shared_pool_size=83886080 【共享池大小】
ecom.__streams_pool_size=0 【流池大小】
*.audit_file_dest=‘/oracle/app/admin/ecom/adump‘ 【审计文件存放路径】
*.background_dump_dest=‘/oracle/app/admin/ecom/bdump‘ 【进程捕获文件存放路径】
*.compatible=‘10.2.0.1.0‘ 【当前库版本号】
*.control_files=‘/oracle/app/oradata/ecom/control01.ctl‘,‘/oracle/app/oradata/ecom/control02.ctl‘,‘/oracle/app/oradata/ecom/control03.ctl‘ 【控制文件路径】
*.core_dump_dest=‘/oracle/app/admin/ecom/cdump‘ 【核心的捕获文件存放路径】
*.db_block_size=8192 【块大小】
*.db_domain=‘‘ 【域名字】
*.db_file_multiblock_read_count=16 【一次最多可以读多少块】
*.db_name=‘ecom‘ 【库名字】
*.db_recovery_file_dest=‘/oracle/app/flash_recovery_area‘ 【闪回区域】
*.db_recovery_file_dest_size=2147483648 【闪回区域大小：2147483648/1024/1024/1024=2G】
*.dispatchers=‘(PROTOCOL=TCP) (SERVICE=ecomXDB)‘ 【开启的TCP网络协议，和监听有关系】
*.job_queue_processes=10 【工作进程数，后台的计划任务】
*.open_cursors=300 【开启的游标数】
*.pga_aggregate_target=94371840 【PGA大小】
*.processes=150 【开启的最大进程数】
*.remote_login_passwordfile=‘EXCLUSIVE‘ 【登录验证的方式】
*.sga_target=285212672 【SGA大小】
*.undo_management=‘AUTO‘ 【uodo表空间管理的方式】
*.undo_tablespace=‘UNDOTBS1‘ 【当前回滚表空间】
*.user_dump_dest=‘/oracle/app/admin/ecom/udump‘ 【用户捕获文件存放路径】
2、mount 加载控制文件(记录数据文件和日志文件的位置)
你到Mount状态，加载完控制文件，目的是往后加载，加载日志文件和控制文件。
控制文件路径：cd $ORACLE_BASE/oradata/$ORACLE_SID/
查看：strings control01.ctl
数据文件和日志文件路径
表空间名称
oracle 单实例单库，一个实例上只能创建一个库
mysql 单实例多库
有的公司有特殊要求：一台服务器多库，那怎么建？
可以建多个实例，oracle认为如果你在一个实例建多个库的话，硬件资源无法分配，硬件资源是加载实例分配的，你的进程数、内存的消耗，缓存的消耗，
那么我一个实例上跑10个库，我现在有1G的内存，我怎么分配？我平均分配？不对吧！按顺序分呢？也不对吧！有资源竞争啊！
所以说呢，你oracle大库作业比较繁忙，为了资源分配的问题，它开发成单实例单库。
mysql可能对性质要求比较小，它做成一个实例跑多个库。
但是有些公司呢，有些特殊需求，我有些库比较小，我跑在一台高端服务器上，成本比较高，我一台服务器上想跑多个库。
你可以多建几个实例，当然一个实例上还是一个库，
3、open 加载日志文件和数据文件
所有的数据库都会有日志文件，日志文件记录着你所有的动作，通过日志才能保证你数据库的完整性。
数据文件，咱们建的表，往表里插入的数据，在操作层面全是插入到数据文件中。
路径：cd $ORACLE_BASE/oradata/$ORACLE_SID/
以上就是数据库的一个启动过程。
窗口1
SQL> shutdown immediate;
cd $ORACLE_BASE/admin/$ORACLE_SID/bdump
tail -f -n 200 alert_$ORACLE_SID.log【oracle的一些改变都会放在alert日志中，验证启动流程】
窗口2
SQL> startup
##############关闭##############
关闭数据库的4种方式：
shutdown normal 需要等待所有事务/进程全部结束 才能关数据库【严禁性最好，但是没有人用】
shutdown transactional 需要等待,但在等待过程中，先把空闲事务进程自动关闭，活动的等人工作完毕了，再关闭。
【
以上2种关闭方式，我会话没有断开，我在往里面写数据，但是没有提交，那它就关闭不了数据库了，是不是有活动会话没有结束，它等待活动会话结束了，才能闭库
你想在生产环境中，你能不能约束用户行为？你不可能约束用户行为吧，你不能说我要关库了，你和用户说你别往里写数据了。
所以上面2种基本很少使用。
】
shutdown immediate 关闭之前同步数据【该同步数据的同步，没有同步的就释放掉，对于你当前的操作，它会告诉你失败了】（生产关闭数据库常用）
举个生活中的例子：
normal：银行5点下班，5点的时候还有10个人手里是有号的，还没有办理业务呢。
那正常银行5点的时候，保安会把银行的大门会关上，只留一个侧门，保安站在门口说不能进来，我们下班了。
咱们关库也一样，不管这3种模式的哪种，第1步外部的新建请求，它不接受了，因为它要关库了，但里面还有10人拿着号，没有办理业务，那怎么办？
你不能说关门直接走吧，你得等待吧，等待这10个人办完业务之后，你才能关门走。
可能5点关门，可能6点才能下班，因为里面还有好多人呢。
transactional：同样也是5点下班，保安把门关上了，大厅10个人有号，但还有些人是陪别人来办业务的、还有些老头老太太走路累了，然后在银行里面乘凉、
还有等人的，约好一个地方，然后对方迟到了，我没地呆，我在银行里坐会吧，这些人不是来办业务的，属于空闲的的会话或进程吧，保安提前把空闲的给清理掉了。
可能5点关门，可能5点50分下班，比上面那种效率好点。
immediate：同样也是5点下班，保安把门关上了，大厅10个人有号，此时正好5点钟窗口上有人在办理业务，正常办理完毕。
剩下这10个等待的人呢，保安给清理走了，说你们明天早上正常来，你们的号还有用，你们排在前面先办理。
所以可能5点关门，可能5点10就下班了。
以上3种，第3种方式关闭速度最快啊。这种方式不会丢数据。
dml：select insert update delete
【oracle为了严谨性， insert update delete操作后，要加上commit，才能生效 (开2个窗口，不commit操作，举个例子)】
客户操作完毕，打了commit操作，传输到服务器端，先写在内存中，然后往硬盘中写，因为内存的数据容易丢。
客户操作完毕，没有打commit操作，传输到服务器端，先写在内存中，现在我一重启，这些操作没有提交，就失效了。
窗口1
insert操作，不commit;
窗口2
shutdown normal;【一直卡着不动】
举例：
窗口1
insert操作，不commit;
窗口2
shutdown immediate;【提交的数据会同步到磁盘，但是没有提交的数据，直接丢弃了。没有丢失数据，它会告诉你操作失败了。】
shutdown abort 强制关闭数据库相当于断电（它的速度最快，此动作非常危险，容易失数据)
同样也是5点下班，大厅10个人有号，此时正好5点钟窗口上有人在办理业务，保安拉闸把电停了，然后一顿电棍把这15个办理业务的人一顿打，然后把门一关闭，就不管你了。
启动数据库
startup 直接打此命令默认选项为open直接打开数据库
startup nomount 只启动实例(装载实例和打开参数文件)
startup mount 挂载数据库(装载实例和打开控制文件，激活某些功能，用户不能存取数据库可以进行实例或数据的恢复处理)
alter database mount 改变数据库从nomount状态到mount状态
alter database open 打开数据库（此时才可以正常对数据库进行读写）
alter database open read only 将数据库打开到只读状态(用得特别少)
startup force 重启数据库 【先shutdown abort ，然后startup ，生产中不会用，特别危险】
----------------------------------------------------------
生产关库：有些大哥直接在操作系统中直接reboot，这么操作库很容易出现问题，无法恢复
正常关闭过程：
1、关闭应用
2、查看数据库备份
3、正常关监听
4、正常关库shutdown immediate 【如果特别慢，可以编写脚本实现】
5、重启操作系统
day03_启动、关闭数据库
标签：
原文地址：http://www.cnblogs.com/xiaoxiao5ya/p/84ed57886fc716cd8ddeeb5524c17302.html
