使用BBED跳过归档进行恢复
https://blog.csdn.net/gumengkai/article/details/53311390 使用BBED跳过归档进行恢复 数据库启动异常，提示6号文件丢失
SQL> startup
ORACLE instance started. Total System Global Area 776646656 bytes
Fixed Size 2257272 bytes
Variable Size 490737288 bytes
Database Buffers 281018368 bytes
Redo Buffers 2633728 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
分析过程：
1. 查看告警日志和trace
[oracle@centos6 trace]$ pwd
/u01/app/oracle/diag/rdbms/orcl/orcl/trace
[oracle@centos6 trace]$ cat alert_orcl.log
日志内容如下：
ALTER DATABASE OPEN
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_dbw0_3020.trc:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_3042.trc:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
ORA-1157 signalled during: ALTER DATABASE OPEN...
根据告警日志中的信息查看trace文件
SQL> select * from v$diag_info;
[oracle@centos6 ~]$ vim /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_3042.trc
trace内容：
DDE: Problem Key 'ORA 1110' was flood controlled (0x1) (no incident)
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
基本可以确认，是6号文件丢失
2. 使用rman还原6号文件
--查看数据库状态 RMAN> report schema;
using target database control file instead of recovery catalog
Report of database schema for database with db_unique_name ORCL
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 760 SYSTEM *** /u01/app/oracle/oradata/orcl/system01.dbf
2 590 SYSAUX *** /u01/app/oracle/oradata/orcl/sysaux01.dbf
3 105 UNDOTBS1 *** /u01/app/oracle/oradata/orcl/undotbs01.dbf
4 5 USERS *** /u01/app/oracle/oradata/orcl/users01.dbf
5 330 EXAMPLE *** /u01/app/oracle/oradata/orcl/example01.dbf
6 0 T *** /u01/app/oracle/oradata/orcl/t01.dbf
7 100 TBS1 *** /u01/app/oracle/oradata/orcl/tbs_1.dbf
8 100 TBS2 *** /u01/app/oracle/oradata/orcl/tbs2.dbf
9 1 UNDO1 *** /u01/app/oracle/oradata/orcl/undo01.dbf
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1 29 TEMP 32767 /u01/app/oracle/oradata/orcl/temp01.dbf
6号文件大小为0，说明该数据文件已经丢失。 --restore还原6号文件 RMAN> restore datafile 6;
Starting restore at 20-NOV-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 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 00006 to /u01/app/oracle/oradata/orcl/t01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/ORCL/backupset/2016_10_23/o1_mf_nnndf_TAG20161023T102912_d0r83s29_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/ORCL/backupset/2016_10_23/o1_mf_nnndf_TAG20161023T102912_d0r83s29_.bkp tag=TAG20161023T102912
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 20-NOV-16
3. 尝试打开数据库
SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf'
提示需要介质恢复
4. 查看数据文件头部和控制文件记录的检查点信息
控制文件： SQL> select FILE#,CHECKPOINT_CHANGE# from v$datafile; FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 2190210
2 2190210
3 2190210
4 2190210
5 2190210
6 2190210
7 2190210
8 2190210
9 2190210 9 rows selected. #可见控制文件中记录的检查点信息是一致的
数据文件头部： SQL> select FILE# ,CHECKPOINT_CHANGE# from v$datafile_header; FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 2190210
2 2190210
3 2190210
4 2190210
5 2190210
6 1301034 #此时oracle会取读6号文件1号块的信息
7 2190210
8 2190210
9 2190210 9 rows selected.
对比控制文件记录的检查点信息和数据文件头部的检查点信息，看两者是否一致。 数据文件头部的scn要比控制文件记录的scn要小，所以要利用归档日志应用日志将数据文件恢复到2190210这个时间点。 5. 使用recover命令恢复6号文件
SQL> recover datafile 6;
ORA-00279: change 1301034 generated at 10/23/2016 10:29:13 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_10_23/o1_mf_1_4_d0rb9tqo
_.arc
ORA-00280: change 1301034 for thread 1 is in sequence #4 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
提示要应用o1_mf_1_4_d0rb9tqo_.arc从1301034进行恢复
6号文件头部记录了检查点信息，包括时间(scn)和RBA，即日志地址，之前的日志就不需要再进行恢复。 --回车进行自动恢复 1322797 ORA-00279: change 1322797 generated at 10/23/2016 11:06:34 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_10_24/o1_mf_1_5_d0vhzoyw
_.arc
ORA-00280: change 1322797 for thread 1 is in sequence #5 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
检查点信息已经到了1322797，还是要比控制文件记录的要小。再从1322797应用归档进行恢复。 --
ORA-00279: change 1344052 generated at 10/24/2016 16:01:57 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_10_24/o1_mf_1_6_d0vj3ffm
_.arc
ORA-00280: change 1344052 for thread 1 is in sequence #6 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
以下重复内容不再贴出来.. --恢复异常，25号归档日志文件丢失 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 1928225 generated at 11/13/2016 11:30:53 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_11_13/o1_mf_1_25_d2htrdn
9_.arc
ORA-00280: change 1928225 for thread 1 is in sequence #25 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log
'/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_11_13/o1_mf_1_25_d2htrd
n9_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
6. 到指定目录下查看归档日志是否还在
[oracle@centos6 2016_11_13]$ ls
o1_mf_1_23_d2hqlxhy_.arc o1_mf_1_26_d2hwpw1f_.arc
o1_mf_1_24_d2hqmflr_.arc o1_mf_1_27_d2jcddcq_.arc
的确是缺少了25号归档日志文件 --再看此时数据文件头部的scn SQL> select FILE# ,CHECKPOINT_CHANGE# from v$datafile_header; FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 2190210
2 2190210
3 2190210
4 2190210
5 2190210
6 1928225
7 2190210
8 2190210
9 2190210 9 rows selected.
还没有恢复到异常发生前的scn，如果此时直接打开数据库，后面的归档日志记录的信息就丢失了。 7. 修改数据文件头部的检查点信息，以跳过25号归档日志。将检查点信息指向26号日志。
--修改RBA，SCN RBA(redo byte addres) à sequence number+block number+offset 61è62 SCN(system change number) 使数据文件头部的SCN从61号日志的开始SCN指向62号日志的开始SCN 8. 使用BBED修改6号文件头部的RBA，6号文件1号块
注：oracle11g offset 500-->RBA offset 484-->SCN BBED> set file 6
FILE# 6 BBED> map /v --dump出1号块的结构
File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
Block: 1 Dba:0x01800001
------------------------------------------------------------
Data File Header struct kcvfh, 860 bytes @0
struct kcvfhbfh, 20 bytes @0
struct kcvfhhdr, 76 bytes @20
ub4 kcvfhrdb @96
struct kcvfhcrs, 8 bytes @100
ub4 kcvfhcrt @108
ub4 kcvfhrlc @112
struct kcvfhrls, 8 bytes @116
ub4 kcvfhbti @124
struct kcvfhbsc, 8 bytes @128
ub2 kcvfhbth @136
ub2 kcvfhsta @138
struct kcvfhckp, 36 bytes @484
ub4 kcvfhcpc @140
ub4 kcvfhrts @144
ub4 kcvfhccc @148
struct kcvfhbcp, 36 bytes @152
ub4 kcvfhbhz @312
struct kcvfhxcd, 16 bytes @316
sword kcvfhtsn @332
ub2 kcvfhtln @336
text kcvfhtnm[] @338
ub4 kcvfhrfn @368
struct kcvfhrfs, 8 bytes @372
ub4 kcvfhrft @380
struct kcvfhafs, 8 bytes @384
ub4 kcvfhbbc @392
ub4 kcvfhncb @396
ub4 kcvfhmcb @400
ub4 kcvfhlcb @404
ub4 kcvfhbcs @408
ub2 kcvfhofb @412
ub2 kcvfhnfb @414
ub4 kcvfhprc @416
struct kcvfhprs, 8 bytes @420
struct kcvfhprfs, 8 bytes @428
ub4 kcvfhtrt @444 ub4 tailchk @8188 BBED> p kcvfhckp --484号检查点的结构
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x001d6c21 –低位4个字节
ub2 kscnwrp @488 0x0000 --高位两个字节
ub4 kcvcptim @492 0x374d2ced
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000019
ub4 kcrbabno @504 0x00000002
ub2 kcrbabof @508 0x0000
ub1 kcvcpetb[] @512 0x02
ub1 kcvcpetb[] @513 0x00
ub1 kcvcpetb[] @514 0x00
ub1 kcvcpetb[] @515 0x00
ub1 kcvcpetb[] @516 0x00
ub1 kcvcpetb[] @517 0x00
ub1 kcvcpetb[] @518 0x00
ub1 kcvcpetb[] @519 0x00 SQL> select to_number('','xx') fromdual; --25号文件 TO_NUMBER('','XX') -------------------- 25 也就是从25号文件，2号块，偏移量为0的位置开始恢复。 只需要把25改为26即可，02不需修改，因为日志文件的第一个块是文件头，也就是从2号文件开始写日志的，恢复的时候也是从2号块开始恢复。 将19改为1a
BBED> d /v offset 500 count 16
File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
Block: 1 Offsets: 500 to 515 Dba:0x01800001
-------------------------------------------------------
19000000 02000000 00009f98 02000000 l ................ BBED> modify /x 1a offset 500
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
Block: 1 Offsets: 500 to 515 Dba:0x01800001
------------------------------------------------------------------------
1a000000 02000000 00009f98 02000000 <32 bytes per line>
BBED> sum apply
Check value for File 6, Block 1:
current = 0xea80, required = 0xea80
9. 修改SCN 6号文件1号块
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x001d6c21 #低位4个字节
ub2 kscnwrp @488 0x0000 #高位2个字节
接下来要推测26号日志开始的SCN，可以从控制文件中记录的V$LOG_HISTORY查看 SQL> select SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# from v$log_history;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
20 1700044 1721365
21 1721365 1754090
22 1754090 1791173
23 1791173 1829681
24 1829681 1928225
25 1928225 2023273
26 2023273 2046588 这样就可以去确定，将1028225改为2023273 1D6C21(21 6c 1d)---》à1edf69(69df 1e) #此时可以用计算器转换，因为数据库未打开，不能使用函数转换 通过将6号文件头部的SCN转换也可以验证这一点。 SQL> select to_number('1d6c21','xxxxxx') from dual; TO_NUMBER('1D6C21','XXXXXX')
----------------------------
1928225 BBED> d /v offset 484 count 16
File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
Block: 1 Offsets: 484 to 499 Dba:0x01800001
-------------------------------------------------------
216c1d00 00000000 ed2c4d37 01000000 l !l......?M7.... <16 bytes per line>
注意，因为这里linux使用的是小端，number类型为倒置存储 BBED> modify /x 69 offset 484
File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
Block: 1 Offsets: 484 to 499 Dba:0x01800001
------------------------------------------------------------------------
696c1d00 00000000 ed2c4d37 01000000 <32 bytes per line> BBED> modify /x df offset 485
File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
Block: 1 Offsets: 485 to 500 Dba:0x01800001
------------------------------------------------------------------------
df1d0000 000000ed 2c4d3701 0000001a <32 bytes per line> BBED> modify /x 1e offset 486
File: /u01/app/oracle/oradata/orcl/t01.dbf (6)
Block: 1 Offsets: 486 to 501 Dba:0x01800001
------------------------------------------------------------------------
1e000000 0000ed2c 4d370100 00001a00 <32 bytes per line> BBED> sum apply;
Check value for File 6, Block 1:
current = 0x59cb, required = 0x59cb
10. 恢复6号文件，看是否能够恢复
SQL> recover datafile 6
ORA-00279: change 2023273 generated at 11/13/2016 11:30:53 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_11_13/o1_mf_1_26_d2hwpw1
f_.arc
ORA-00280: change 2023273 for thread 1 is in sequence #26 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
可以看到此时已经从26号日志开始恢复了
SQL> recover datafile 6
ORA-00279: change 2096676 generated at 11/16/2016 18:54:49 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2016_11_19/o1_mf_1_29_d2zk84c
z_.arc
ORA-00280: change 2096676 for thread 1 is in sequence #29 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} Log applied.
Media recovery complete.
SQL> alter database open; Database altered.
数据库可以打开了。此时最好尽快做一个全库备份 ============================================================================================================================== 附上模拟故障的脚本： 1. 移除数据文件 t01.dbf
[oracle@centos6 orcl]$ ls
control01.ctl redo01.log redo03.log system01.dbf tbs_1.dbf temp01.dbf undotbs01.dbf
example01.dbf redo02.log sysaux01.dbf t01.dbf tbs2.dbf undo01.dbf users01.dbf
[oracle@centos6 orcl]$ mkdir bak
[oracle@centos6 orcl]$ mv t01.dbf bak/t01.dbf
2. 查看最近的备份文件
RMAN> list backup of database;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4 Full 1.12G DISK 00:00:19 23-OCT-16
BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20161023T102912
Piece Name: /u01/app/oracle/fast_recovery_area/ORCL/backupset/2016_10_23/o1_mf_nnndf_TAG20161023T102912_d0r83s29_.bkp
List of Datafiles in backup set 4
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 1301034 23-OCT-16 /u01/app/oracle/oradata/orcl/system01.dbf
2 Full 1301034 23-OCT-16 /u01/app/oracle/oradata/orcl/sysaux01.dbf
3 Full 1301034 23-OCT-16 /u01/app/oracle/oradata/orcl/undotbs01.dbf
4 Full 1301034 23-OCT-16 /u01/app/oracle/oradata/orcl/users01.dbf
5 Full 1301034 23-OCT-16 /u01/app/oracle/oradata/orcl/example01.dbf
6 Full 1301034 23-OCT-16 /u01/app/oracle/oradata/orcl/t01.dbf
最新的备份为10月26号
3. 查看归档日志
[oracle@centos6 ~]$ cd /u01/app/oracle/fast_recovery_area/ORCL/archivelog
[oracle@centos6 archivelog]$ ls
2016_10_16 2016_10_24 2016_11_01 2016_11_03 2016_11_06 2016_11_12 2016_11_16 2016_11_20
2016_10_23 2016_10_29 2016_11_02 2016_11_05 2016_11_09 2016_11_13 2016_11_19
4. 移除2016_11_13的其中一个归档日志文件
[oracle@centos6 archivelog]$ cd 2016_11_13
[oracle@centos6 2016_11_13]$ ls
o1_mf_1_23_d2hqlxhy_.arc o1_mf_1_25_d2htrdn9_.arc o1_mf_1_27_d2jcddcq_.arc
o1_mf_1_24_d2hqmflr_.arc o1_mf_1_26_d2hwpw1f_.arc
[oracle@centos6 2016_11_13]$ mv o1_mf_1_25_d2htrdn9_.arc o1_mf_1_25_d2htrdn9_.arc.bak
5. 关闭数据库，重新打开
SQL> startup
ORACLE instance started. Total System Global Area 776646656 bytes
Fixed Size 2257272 bytes
Variable Size 490737288 bytes
Database Buffers 281018368 bytes
Redo Buffers 2633728 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/t01.dbf' ---------------------
作者：bitko
来源：CSDN
原文：https://blog.csdn.net/gumengkai/article/details/53311390
版权声明：本文为博主原创文章，转载请附上博文链接！ ==================================================================================================================================
==================================================================================================================================
使用BBED跳过归档进行恢复的更多相关文章
- 05 使用bbed跳过归档恢复数据文件
5 使用BBED跳过归档 在归档模式下,缺失了一部分的归档日志文件,对数据文件进行恢复 1 开启归档 --shutdown immediate --startup mount --alter data ...
- BBED跳过归档
通过BBED 跳过归档,以当前数据库 8号文件为例: SQL; FILE# NAME ---------- ---------------------------------------------- ...
- [Xcode 实际操作]七、文件与数据-(10)NSkeyedArchiver存储和解析数据，Swift对象的归档和恢复归档
目录:[Swift]Xcode实际操作 本文将演示如何使用归档的方法,对模型对象进行持久化工作. 在项目名称上点击鼠标右键,弹出右键菜单,选择[New File]新建文件命令, 在弹出的模板选项窗口中 ...
- iOS开发 - 数据归档与恢复 NSKeyedArchiver
归档与恢复归档 归档,英文Archiver['ɑrkɪvə],这里指的是将OC的对象存储为一个文件或者网络上的一个数据块. 恢复归档.英文UnArchiver,指的是将一个来自文件或网络的归档数据块恢 ...
- 【Oracle】使用BBED跳过丢失的归档
在recover datafile的过程其中假设丢失了须要的归档将使得recover无法进行.使用bbed工具能够跳过丢失的归档进行recover datafile. 实验步骤例如以下: SYS@OR ...
- db2日志模式、备份归档、恢复解析
DB2的日志分为两种模式,日志循环与归档日志,也就是非归档和归档模式.下面就具体介绍一下这两种方式以及和备份归档设置的关系. 一.日志循环 这是默认方式,也就是非归档模式,这种模式只支持(backup ...
- Oracle特殊恢复原理与实战（DSI系列）
1.深入浅出Oracle(DSI系列Ⅰ) 2.Oracle特殊恢复原理与实战(DSI系列Ⅱ) 3.Oracle SQL Tuning(DSI系列Ⅲ)即将开设 4.Oracle DB Performan ...
- oracle dis系列课程总结
oracle dis系列课程总结 1 bbed安装和介绍 --1 bbed的安装--(Oracle Block Brower and EDitor Tool) 2 controlfile 丢失的恢复 ...
- 无归档情况下使用BBED处理ORA-01113错误
在丢失归档情况下,恢复时常会遇到ora-01113错误,以下实验模拟表空间offline,然后在丢失归档文件的情况下使用BBED修改文件头信息,最后恢复数据文件: 数据库版本: SQL> sel ...
随机推荐
- vue从入门到进阶：指令与事件（二）
一.插值 v-once 通过使用 v-once 指令,你也能执行一次性地插值,当数据改变时,插值处的内容不会更新.但请留心这会影响到该节点上所有的数据绑定: span v-once>这个将不会改 ...
- C#基础(202)--类定义，字段与属性，自动属性，方法及常见错误
c#类的定义规范 字段与属性的比较: 字段: 字段主要是为类的内部做数据交换交互使用,字段一般是private 字段可以赋值,也可以取值 当字段需要为外部数据提供数据的时候,请将字段封装为属性,而不是 ...
- iphone怎么投屏到电脑屏幕上
随着苹果手机的更显换代,苹果手机的功能越来越强大,其中iphone手机更新了airplay镜像功能,所以想要手机投屏电脑的小伙伴就更加方便了,但是iphone怎么投屏到电脑呢?大家不用着急,下面即将为 ...
- springboot Redis 缓存
1,先整合 redis 和 mybatis 步骤一: springboot 整合 redis 步骤二: springboot 整合 mybatis 2,启动类添加 @EnableCaching 注解, ...
- javascript:面向对象和常见内置对象及操作
本文内容: 面向对象 常见内置对象及操作 首发日期:2018-05-11 面向对象: JavaScript 是面向对象的编程语言 (OOP).OOP 语言使我们有能力定义自己的对象和变量类型. 对象是 ...
- JHipster技术栈理解 - UAA原理分析
本文简要分析了UAA的认证机制和部分源码功能. UAA全称User Account and Authentication. 相关源码都是通过Jhipster生成,包括UAA,Gateway,Ident ...
- 使用Visual Studio Team Services持续集成（二）——为构建定义属性
使用Visual Studio Team Services持续集成(二)--为构建定义属性 1.从VSTS帐户进入到Build 2.编辑构建定义并单击Options Description:如果这里明 ...
- 搭建的flask项目，若修改项目中的文件，项目没有reload，除非重启主机，解决方法如下
1.博主本人前面有发过一篇博文如何搭建flask项目,可以去查看. 解决办法:加入一句 touch-reload=项目目录在uwsgi.ini 2.测试没问题
- shell编程—注释、字符串和数组（四）
shell注释 以#作为注释符号 shell中没有多行注释,只能一行加一个#号 字符串操作 1.拼接字符串 2.获取字符串长度 string=“khjf” echo ${#string} 3.提取子字 ...
- IOS UIWebView用法
转自猫猫小屋 IOS webview控件使用简介(一) IOS webview控件使用简介(二)–加载本地html