oracle-不完全数据库恢复-被动恢复-RMAN-06025/ORA-01190
不完全数据库恢复
到目前为止，前面讨论的都是完全恢复数据库，这是recover database\recover tablespace\recover datafile默认的行为特征。
所谓完全恢复指在介质恢复阶段（执行recover）必须应用所有的应该应用的重做日志：它们包括从数据文件头中的检查点RBA所指向的重做记录开始，
一致到在线的当前的CURRENT redo log结束，不论在归档文件还是redo中，recover将尽可能寻找这些记录，最后返回
media recovery complete
前面章节讨论没有丢失任何一个归档跟redo日志，所以都是完全恢复总是成功的。
不完全恢复在介质恢复阶段不需要应用所有的重做记录，而只需要一部分：介质恢复的起点必须是数据文件头中的检查点RBA所指向的重做记录，终点可以
是之后的任意一条重做记录，这些重做记录可以在归档日志或是在线日志中。不完全恢复的结果是将数据库恢复到“过去”的一个时间点，而不像完全恢复那样将db恢复到当前时间点。
完全恢复不会丢失任何一个已经提交的事务，而不完全恢复可能丢失已提交的事务。
12.1 工作原理
不完全恢复的结果是一样的，2个特点：
--1 不完全恢复极可能造成已经提交的事务丢失，即将db回退到过去的一个时间点，导致某些变更就像根本没有发生过一样。因此，不完全恢复也被称为指定时间目标（point in time）恢复，PIT恢复
--2 不完全恢复的影响范围一定是数据库范围的，即只有recover database命令支持不完全恢复。
由于极可能造成事务丢失，并且影响整个数据库，绝非必要，否则不应该使用不完全恢复解决问题。
主动与被动不完全恢复
--被动恢复：原计划完全恢复，但是在恢复过程中发现recover需要的一个归档日志或处于active或current的redo log丢失或损坏，结果被迫以不完全恢复，否则db无法打开。
--主动恢复：由于人为错误破坏了数据库内的大量信息（比如update，truncate重要的表），为了找回正确的信息使数据库回到破坏操作之前采用的不完全恢复。
PIT的4种表达形式
--1 精确到重做日志的基于日志序列号recover database until sequence,仅适用RMAN
比如，RECOVER DATABASE UNTIL SEQUENCE 100视图将db恢复至99号日志的最后一条重做记录，不包括100号日志。
--2 精确到重做日志的基于交互式手动喊停的recover database until cancel，仅适用sqlplus
--3 精确到重做记录的基于时间的recover database until time，适用于RMAN和sqlplus。
比如，recover database until time ‘sysdate-1’ 试图将db恢复至大于24小时之前
--4 精确到重做记录的基于SCN的recover database until scn和recover database until restore point，适用于RMAN；recover database until change 和recover database until restore point适用于sqlplus。
比如recover database until scn 10000试图将db恢复至PIT点SCN10000
为了使不完全恢复能够成功，在recover执行之前的restore命令有一个非常重要的注意事项，那就是必须还原足够“旧”的备份中的数据文件。因为recover命令使用的是重做记录，重做记录只能将数据向“前”推，增大其头部的检查点SCN。
假设不完全恢复PIT点的SCN是70000，但是restore命令还原的数据文件头部中的SCN是80000，这会导致recover database until scn 70000抛出RMAN-06556异常，意思是数据文件不够“旧”，
即restore命令还原的数据文件头SCN不够小，其值应该小于或等于70000，recover命令才能成功。
12.2 被动恢复
场景1：数据库有备份，运行时数据文件yhqt01.dbf丢失，并且某些在备份后产生的未备份的归档日志丢失，应用报错ORA-01116无法打开10号文件
丢失的是普通数据文件，所以
RMAN> run {
sql'alter database datafile 10 offline';
restore datafile 10;
recover datafile 10;
sql'alter database datafile 10 online';}
Starting recover at 25-JUL-19
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 84 is already on disk as file /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_84_gml7nj0y_.arc
archived log for thread 1 with sequence 85 is already on disk as file /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_85_gml7nk2o_.arc
archived log for thread 1 with sequence 88 is already on disk as file /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_88_gml7o84w_.arc
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/25/2019 11:26:00
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 87 and starting SCN of 1013521 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 86 and starting SCN of 1013510 found to restore
--由于手工删除了86.87号归档日志
查看当前在线日志的情况
SQL> select group#,sequence#,status from v$log;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 88 INACTIVE
2 89 CURRENT
3 87 INACTIVE
查看被还原的10号文件yhqt01.dbf头部的SCN号，该数据文件头部的SCN即使recover命令恢复的起点
SQL> select file#,change# from v$recover_file;
FILE# CHANGE#
---------- ----------
10 1006178
使用SCN号是1006178去咨询一下v$log_history视图，得到recover datafile 10的起点在哪个日志
SQL> select sequence# from v$log_history where 1006178 between first_change# and next_change#-1;
SEQUENCE#
----------
82
结果是82号日志
根据上面3个查询，刚才使用的recover datafile 10，需要从82号日志恢复到89号日志，其中88,89为在线日志，RMAN报告86,87号归档日志找不到，既然不能成功地从82号一直恢复到89号，recover命令异常。
接下来去归档路径下找一找，发现确实找不到，这里人为的rm掉了
[oracle@DSI 2019_07_25]$ ll
total 5148
-rw-r----- 1 oracle oinstall 5262336 Jul 25 11:14 o1_mf_1_84_gml7nj0y_.arc
-rw-r----- 1 oracle oinstall 2048 Jul 25 11:14 o1_mf_1_85_gml7nk2o_.arc
-rw-r----- 1 oracle oinstall 2560 Jul 25 11:14 o1_mf_1_88_gml7o84w_.arc
再使用RMAN查看归档备份的情况
RMAN> list backup of archivelog all;
那么oracle认为86 87号归档日志在哪里呢
RMAN> list archivelog low sequence 86 high sequence 87;
List of Archived Log Copies for database with db_unique_name ORCL
=====================================================================
Key Thrd Seq S Low Time
------- ---- ------- - ---------
11 1 86 A 25-JUL-19
Name: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_86_gml7o58q_.arc
12 1 87 A 25-JUL-19
Name: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_87_gml7o64p_.arc
这种情况下，似乎只能将yhqt01.dbf文件恢复到85号日志的最后一条重做记录，
RMAN> recover datafile 10 until sequence 86;
命令执行成功。但是不要误认为oracle可以支持单独的一个数据文件进行不完全恢复。
上线10号文件报错
RMAN> sql'alter database datafile 10 online';
sql statement: alter database datafile 10 online
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 07/25/2019 11:36:40
RMAN-11003: failure during parse/execution of SQL statement: alter database datafile 10 online
ORA-01113: file 10 needs media recovery
ORA-01110: data file 10: '/u01/app/oracle/oradata/orcl/yhqt01.dbf'
错误RMAN-11003表示yhqt01.dbf文件和其他数据文件无法同步，还需要更多恢复，需要86号日志，但是86号日志已经丢失找不到了。这个时候，
有两种办法，要么在也不上线yhqt，不访问yhqt01.dbf数据文件。要么在数据库范围上执行一次真正的不完全恢复，使所有数据文件倒退至85号文件的最后一条重做日志，保证所有数据文件之间的一致性。
RMAN> recover database until sequence 86;
Starting recover at 25-JUL-19
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/25/2019 11:40:03
RMAN-06556: datafile 1 must be restored from backup older than SCN 1013510
直接执行会报错，因为其他数据文件不够旧
关闭数据库
SQL> shutdown abort;
ORACLE instance shut down.
RMAN> run {
startup force mount;
restore database;
}2> 3> 4>
Oracle instance started
database mounted
Total System Global Area 784998400 bytes
Fixed Size 2257352 bytes
Variable Size 499125816 bytes
Database Buffers 276824064 bytes
Redo Buffers 6791168 bytes
Starting restore at 25-JUL-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=133 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/orcl/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/orcl/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/orcl/users01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/orcl/test01.dbf
channel ORA_DISK_1: restoring datafile 00008 to /u01/app/oracle/oradata/orcl/rc_data01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/bol_fullbak01u7hht8_1_1_20190725
channel ORA_DISK_1: piece handle=/home/oracle/backup/bol_fullbak01u7hht8_1_1_20190725 tag=BOL_FULLBAK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/orcl/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00006 to /u01/app/oracle/oradata/orcl/assm01.dbf
channel ORA_DISK_1: restoring datafile 00007 to /u01/app/oracle/oradata/orcl/mssm01.dbf
channel ORA_DISK_1: restoring datafile 00009 to /u01/app/oracle/oradata/orcl/ogg01.dbf
channel ORA_DISK_1: restoring datafile 00010 to /u01/app/oracle/oradata/orcl/yhqt01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/bol_fullbak02u7hhtf_1_1_20190725
channel ORA_DISK_1: piece handle=/home/oracle/backup/bol_fullbak02u7hhtf_1_1_20190725 tag=BOL_FULLBAK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
Finished restore at 25-JUL-19
利用动态视图检查所还原的数据文件是否足够“旧”但又不至于“太旧”。
SQL> select 'restore check ok' "restore_check"
from
(select max(next_change#-1) tail,min(first_change#) head
from v$log_history
where
sequence# between 82 and 86) lh
where
(select max(change#) from v$recover_file) <= lh.tail and
(select min(change#) from 2 3 4 5 6 7 8 9 v$recover_file) >= lh.head;
restore_check
----------------
restore check ok
restore database默认从最新的备份中还原，在82号日志之后是备份过数据库，并且没有在85号日志之后备份过数据库。
实际情况应该在restore中给出from关键字指定哪个备份集还原
RMAN> run {
2> set until sequence 86;
3> restore database;
4> }
executing command: SET until clause
Starting restore at 25-JUL-19
using channel ORA_DISK_1
skipping datafile 1; already restored to file /u01/app/oracle/oradata/orcl/system01.dbf
skipping datafile 2; already restored to file /u01/app/oracle/oradata/orcl/sysaux01.dbf
skipping datafile 4; already restored to file /u01/app/oracle/oradata/orcl/users01.dbf
skipping datafile 5; already restored to file /u01/app/oracle/oradata/orcl/test01.dbf
skipping datafile 8; already restored to file /u01/app/oracle/oradata/orcl/rc_data01.dbf
skipping datafile 3; already restored to file /u01/app/oracle/oradata/orcl/undotbs01.dbf
skipping datafile 6; already restored to file /u01/app/oracle/oradata/orcl/assm01.dbf
skipping datafile 7; already restored to file /u01/app/oracle/oradata/orcl/mssm01.dbf
skipping datafile 9; already restored to file /u01/app/oracle/oradata/orcl/ogg01.dbf
skipping datafile 10; already restored to file /u01/app/oracle/oradata/orcl/yhqt01.dbf
restore not done; all files read only, offline, or already restored
Finished restore at 25-JUL-19
在restore前使用set until可以有效防止还原不够“旧”的备份。这里还原的数据文件头部的SCN必须小于86号日志的第一条重做记录的SCN。
RMAN> recover database until sequence 86;
Starting recover at 25-JUL-19
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 84 is already on disk as file /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_84_gml7nj0y_.arc
archived log for thread 1 with sequence 85 is already on disk as file /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_85_gml7nk2o_.arc
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=82
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=83
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/arch_06u7hhtm_1_1_20190725
channel ORA_DISK_1: piece handle=/home/oracle/backup/arch_06u7hhtm_1_1_20190725 tag=TAG20190725T110004
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_82_gml9gk3o_.arc thread=1 sequence=82
channel default: deleting archived log(s)
archived log file name=/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_82_gml9gk3o_.arc RECID=16 STAMP=1014551121
archived log file name=/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_83_gml9gk46_.arc thread=1 sequence=83
channel default: deleting archived log(s)
archived log file name=/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_83_gml9gk46_.arc RECID=17 STAMP=1014551121
archived log file name=/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_84_gml7nj0y_.arc thread=1 sequence=84
archived log file name=/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2019_07_25/o1_mf_1_85_gml7nk2o_.arc thread=1 sequence=85
media recovery complete, elapsed time: 00:00:00
Finished recover at 25-JUL-19
以上的命令也能这样执行
RMAN> run{
set until sequence 86;
recover database;
}
至此，从86号日志第一条重做开始其后的所有重做记录描述的变更均未生效，数据文件中没有这些结果的变更。
SQL> alter database open resetlogs;
Database altered.
SQL> select sequence#,status from v$log;
SEQUENCE# STATUS
---------- ----------------
1 CURRENT
0 UNUSED
0 UNUSED
整个事故到此尚未结束，对业务来说需要将85号日志以后提交的事务重新录入数据库。
上面的步骤总体可以总结为：
RMAN> run {
startup force mount;
set until sequence 86;
restore database;
recover database;
alter database open resetlogs;
}
另外，若在RAC环境下，为了避免PIT点产生歧义，在set until时指定线程号
RMAN> run {
startup force mount;
set until sequence 86 thread ;
restore database;
recover database;
alter database open resetlogs;
}
话外篇
此时查询yhqt依然报错
SQL> conn yhqt/****
Connected.
SQL> select count(*) from yhqtest_3;
select count(*) from yhqtest_3
*
ERROR at line 1:
ORA-00376: file 10 cannot be read at this time
ORA-01110: data file 10: '/u01/app/oracle/oradata/orcl/yhqt01.dbf'
SQL> select file#||chr(9)||status||chr(9)||name||chr(9)||bytes from v$datafile where file#=10; FILE#||CHR(9)||STATUS||CHR(9)||NAME||CHR(9)||BYTES
--------------------------------------------------------------------------------
10 OFFLINE /u01/app/oracle/oradata/orcl/yhqt01.dbf 52428800
SQL> alter database datafile 10 online;
alter database datafile 10 online
*
ERROR at line 1:
ORA-01190: control file or data file 10 is from before the last RESETLOGS
ORA-01110: data file 10: '/u01/app/oracle/oradata/orcl/yhqt01.dbf'
SQL> set linesize 999
查看相关的检查点
--数据文件检查点
SQL> select file#,CREATION_CHANGE#,CHECKPOINT_CHANGE# ,UNRECOVERABLE_CHANGE#,LAST_CHANGE#,OFFLINE_CHANGE#,STATUS from v$datafile order by 1;
FILE# CREATION_CHANGE# CHECKPOINT_CHANGE# UNRECOVERABLE_CHANGE# LAST_CHANGE# OFFLINE_CHANGE# STATUS
---------- ---------------- ------------------ --------------------- ------------ --------------- -------
1 7 1013532 0 1013510 SYSTEM
2 1786 1013532 0 1013510 ONLINE
3 2807 1013532 0 1013510 ONLINE
4 15626 1013532 0 1013510 ONLINE
5 923171 1013532 0 1013510 ONLINE
6 923455 1013532 0 1013510 ONLINE
7 923728 1013532 0 1013510 ONLINE
8 924001 1013532 0 1013510 ONLINE
9 924272 1013532 0 1013510 ONLINE
10 986669 1013531 0 1013532 1013510 OFFLINE
--数据文件头检查点
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
1013532
1013532
1013532
1013532
1013532
1013532
1013532
1013532
1013532
1013510
--系统检查点
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
1013532
查看incrarnation
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 ORCL 1542322764 PARENT 1 25-JUL-19
2 2 ORCL 1542322764 CURRENT 1013511 25-JUL-19
10号数据文件的头部检查点还在reset scn的前面
恢复10号文件
SQL> recover datafile 10;
Media recovery complete.
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
1013532
1013532
1013532
1013532
1013532
1013532
1013532
1013532
1013532
1013532
10 rows selected.
SQL> alter database datafile 10 online;
Database altered.
SQL> select count(*) from yhqtest_3;
COUNT(*)
----------
5001
oracle-不完全数据库恢复-被动恢复-RMAN-06025/ORA-01190的更多相关文章
- oracle-不完全数据库恢复-被动恢复-ORA-00313/ORA-00366
继上一篇不完全恢复 oracle-不完全数据库恢复-被动恢复-ORA-00313/ORA-00366 场景2:数据库拥有备份,CURRENT状态日志组中所有的在线日志头损坏,在发生日志切换时实例被自动 ...
- oracle 11g 数据库恢复技术 ---04 rman
四 RMAN RMAN体系结构的主要组成部分: --1 目标数据库(target) --2 RMAN命令行客户端 --3 通道(channel) --4 快速恢复区(fast recovery are ...
- Oracle 【IT实验室】数据库备份与恢复之：如何对Oracle数据库文件进行恢复与备份
任何数据库在长期使用过程中,都会存在一定的安全隐患.对于数据库管理员来说不能仅寄希望于计算机操作系统的安全运行,而是要建立一整套的数据库备份与恢复机制.当数据库发生故障后,希望能重新建立一个完整的数据 ...
- Oracle 11g 中恢复管理器RMAN介绍
这是我平时摘录的笔记,从管理艺术那本书上摘录出来的,放到这里 RMAN 可在数据库服务器的帮助下从数据库内备份数据文件,可构造数据文件映像副本.控制文件和控制文件映像.对当日志 SPFILE 和RMA ...
- Oracle 数据库备份和恢复配置
可能的失败及其解决方法 失败类型 我们坑你遇到的失败或错误分为两大类:物理和逻辑.物理错误一般是硬件错误或使用数据库的应用程序中的软件错误,而逻辑错误一般在终端用户级别(数据库用户和管理员). 按从轻 ...
- Oracle 数据库异机恢复（归档模式）
操作必须在服务器上进行(在192.168.12.71上执行) 0.按需要恢复的日期,把距恢复日期最近的全部备份和全部备份日期后的日志备份一同拷贝到需要恢复的机器上: 1.用RMAN登陆 C:\User ...
- Oracle数据库备份、恢复及常见问题
通常我们都是使用PL/SQL Developer来对Oracle中的数据对象和数据进行管理.如果我们想方便快速还原或者部署Oracle到新机器上,怎么进行数据库的备份.导入恢复呢? 这里我们必须要考虑 ...
- undo丢失恢复异常恢复，运维DBA反映Oracle数据库无法启动报错ORA-01157 ORA-01110，分析原因为Oracle数据库坏块导致
本文转自 惜纷飞 大师. 模拟基表事务未提交数据库crash,undo丢失恢复异常恢复,运维DBA反映Oracle数据库无法启动报错ORA-01157 ORA-01110,分析原因为Oracle数据库 ...
- 数据恢复：如何恢复Linux中意外删除的Oracle和MySQL数据库
今天有客户的数据库意外被删除了整个目录中的数据文件,操作系统级别的删除,然而幸运的是这个数据库没有崩溃,仍然处于 open 状态的时候,客户就发现了问题,求助到我们,最终完整地恢复了所有数据文件. 在 ...
随机推荐
- MVC-MVP-MVVM框架模式分析
MVC(Model-View-Controller) MVC 架构模式图(经典版) 注:实际上,Model和View永远不能相互通信,只能通过Controller传递:上图只是MVC模式的经典图. M ...
- Spring的DI和AOP
Spring 为了降低Java开发的复杂性,Spring采取了以下4种关键策略:* 基于POJO的轻量级和最小入侵性编程:* 通过依赖注入和面向接口实现松耦合:* 基于切面和惯例进行声明式编程:* 通 ...
- 【HDU4003】Find Metal Mineral
题目大意:给定一棵 N 个节点的有根树,边有边权,在根结点处有 K 个人,这些人会遍历树上的所有边,求如何遍历才能使得所有人走过路径的边权和最小. 题解: 引理:对于一棵子树来说,若存在 M>0 ...
- 用小程序做一个类似于苹果AssistiveTouch功能
一.首先我先介绍一下,我们要做一个什么样的项目功能 项目功能就是一个音频点击播放,当点击为播放的状态时,一个音频的动图出现,而且是可以跟随着手指的滑动而滑动,而且,在滑动动图的时候,当前下的页面是不可 ...
- MegaPixImage插件代码（new MegaPixImage）
/** * Mega pixel image rendering library for iOS6 Safari * * Fixes iOS6 Safari's image file renderin ...
- LOJ-数列分块入门5
链接: https://loj.ac/problem/6281 题意: 给出一个长为 的数列 ,以及 n个操作,操作涉及区间开方,区间求和. 思路: 考虑开方5次之后就为1, 即考虑一整个区间的开方次 ...
- 【curl】cookie的分隔符
cookie是以分号作为分隔符的. ex: curl --silent -H "Host: xxx.com" "172.172.178.9:80/item/comm?pi ...
- 第九周作业—N42-虚怀若谷
一.编写脚本,接收二个位置参数,magedu和/www,判断系统是否有magedu,如果没有则自动创建magedu用户,并自动设置家目录为/www [root@centos7 data]# cat u ...
- 分组统计 over(partition by
sum( CASE WHEN ISNULL(b.zl, 0) = 0 THEN C.LLZL ELSE b.zl END * c.pccd * b.sl) over(partition by b.dj ...
- 全方面了解和学习PHP框架 PHP培训教程
PHP成为最流行的脚本语言有许多原因:灵活性,易用性等等.对于项目开发来说,我们通常需要一个PHP框架来代替程序员完成那些重复的部分.本文,兄弟连将对PHP框架进行全面解析. PHP框架是什么? PH ...