day10_小计

窗口1、
sqlplus scott/lipengfei


窗口2、
SQL> drop user scott;
drop user scott
*
ERROR at line 1:
ORA-01940: cannot drop a user that is currently connected


怎么闭关这个连接呢?你可以在 窗口1 退出。
在生产环境会有一个问题,你多个人操作数据库,可能开发人员也在用,他不在你本地。
咱们用  v$session解决

desc v$session

select SID,SERIAL#,USERNAME,STATUS,program from v$session where username is not null;
【USERNAME为空不能被干掉,它是启动数据库必要加载的进程】


alter system kill session'SID,SERIAL#'; 【在oracle中通过SID,SERIAL#就可以定位一个会话】


窗口1、
select * from emp; 【ERROR at line 1:ORA-00028: your session has been killed】

窗口2、
SQL> drop user scott;


select SID,SERIAL# from v$session where username='SCOTT';
      SID    SERIAL#
---------- ----------
       145          7
       147         40
       150         53
       159         80


alter system kill session '145,5';


select 'alter system kill session '||''''||SID||','||SERIAL#||''';' from v$session where username='SCOTT';

'ALTERSYSTEMKILLSESSION'||''''||SID||','||SERIAL#||''';'
--------------------------------------------------------------------------------
alter system kill session '145,7';
alter system kill session '147,40';
alter system kill session '150,53';
alter system kill session '159,80';


select 'fuck you;!-' from dual;

select '  ''  ' from dual;
= select '''' from dual;



----------------------LGWR---------------------------
窗口1
sqlplus scott/lipengfei

create table aa as select * from emp;
insert into aa select * from aa;
commit;
select count(*) from aa;
insert into aa select * from aa;
select count(*) from aa;【操作这些么,有没有写到磁盘的日志中???? 超过了3秒,日志写由内存写到磁盘了,解发了DBW写进程】

窗口2
shutdown abort;
startup

窗口1
select count(*) from aa;【这有多少行?】

这就是数据库保证数据完整性,按大家想法只要日志写到日志文件中,我就有记录了。

如果说我写100W行,我写入了50W行的时候,断电了,数据库只保存50W行吗?
不是吧,保证数据的完整性,你没有commit,代表这个动作没有完成,突然断电了,
你再启动的时候,它认为你这个操作不是完整,往回退,默认有smon进程进行恢复。

tail -n 100 $ORACLE_BASE/admin/$ORACLE_SID/bdump/alert_$ORACLE_SID.log  

Completed: ALTER DATABASE   MOUNT
Mon Apr 27 14:24:49 2015
ALTER DATABASE OPEN
Mon Apr 27 14:24:49 2015
Beginning crash recovery of 1 threads
Mon Apr 27 14:24:49 2015
Started redo scan 【因为你之前未正常关机,开始扫描redo】
Mon Apr 27 14:24:49 2015
Completed redo scan
 4359 redo blocks read, 689 data blocks need recovery【有数据块要恢复】
Mon Apr 27 14:24:50 2015
Started redo application at
 Thread 1: logseq 2, block 41425
Mon Apr 27 14:24:50 2015
Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0
  Mem# 0 errs 0: /oracle/app/oradata/ecom/redo01.log【加载redo日志】
Mon Apr 27 14:24:50 2015
Completed redo application
Mon Apr 27 14:24:51 2015
Completed crash recovery at
 Thread 1: logseq 2, block 45784, scn 475148
 689 data blocks read, 689 data blocks written, 4359 redo blocks read
Mon Apr 27 14:24:51 2015
Thread 1 advanced to log sequence 3
Thread 1 opened at log sequence 3
  Current log# 2 seq# 3 mem# 0: /oracle/app/oradata/ecom/redo02.log
Successful open of redo thread 1
Mon Apr 27 14:24:51 2015
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Successfully onlined Undo Tablespace 1.
Mon Apr 27 14:24:52 2015
SMON: enabling cache recovery【SMON恢复】
SMON: enabling tx recovery
Mon Apr 27 14:24:52 2015
Database Characterset is ZHS16GBK
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=16, OS id=3616
Mon Apr 27 14:24:52 2015
db_recovery_file_dest_size of 2048 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.
Mon Apr 27 14:24:52 2015
Completed: ALTER DATABASE OPEN【恢复完成,数据库正常开启】




举例:
aa表Insert 28行,现在aa表有56行了,在redo日志中应该记录着,
一次操作insert了28行,日志写完了,我这新增的28行数据也写到数据文件了,因为dbwn进程,
但是现在我没有打commit,突然断电了,当我再startup,启动到mount后,它会扫描日志,
保证数据库的完整性,在扫描日志时,发现有这么1行,1次Insert了28,但是没有提交。
没有提交,就不能保证完整性,它就会往后退,退到上一次正常完成状态(commit),所以扫描日志了。
这就是数据库的特点,一定要保证数据的完整性,如果保证不了,那数据库就不能用了。










原文地址:https://www.cnblogs.com/xiaoxiao5ya/p/a7908f56501da954875342e48bbdc2bf.html