使用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 ...
随机推荐
- 微信小程序之封装http请求
下面将封装http请求服务部分的服务以及引用部分 // 本服务用于封装请求 // 返回的是一个promisepromise var sendRrquest = function (url, metho ...
- 【Wyn Enterprise BI知识库】 什么是商业智能 ZT
商业智能(Business Intelligence,BI),又称商务智能,指用现代数据仓库技术.在线分析处理技术.数据挖掘和数据展现技术进行数据分析以实现商业价值. 图1:商业智能(BI)系统 商业 ...
- C# 利用SharpPcap实现网络包捕获嗅探
本文是利用SharpPcap实现网络包的捕获的小例子,实现了端口监控,数据包捕获等功能,主要用于学习分享. 什么是SharpPcap? SharpPcap 是一个.NET 环境下的网络包捕获框架,基于 ...
- Android为TV端助力 转载：Android绘图Canvas十八般武器之Shader详解及实战篇(下)
LinearGradient 线性渐变渲染器 LinearGradient中文翻译过来就是线性渐变的意思.线性渐变通俗来讲就是给起点设置一个颜色值如#faf84d,终点设置一个颜色值如#CC423C, ...
- MySQL5.7 搭建主从同步
性能更好的新服务器申请下来了,我们决定在2台新服务器上使用mysql5.7,并且使用主从同步.读写分离架构,很不幸这个任务落到了我的头上.读写分离是在业务代码中实现的,在此不做详述,介绍一下我搭建My ...
- vue使用axios请求后端数据
1. 安装axios $ npm install axios 2.在main.js里面导入axios import axios from 'axios' Vue.prototype.$http = a ...
- C#-类（九）
类的定义 类是描述具有相同特征与行为的事物的抽象,类内部包含类的特征和类的行为 类支持继承 类的定义是关键字class为标志 类的格式 访问标识符 class 类名 { 类主体 } 访问标识符:指定了 ...
- mysql中导入导出sql文件
1.导出整个数据库: mysqldump -u用户名 -p密码 数据库名 > 导出的文件名 例:mysqldump -uroot -proot user > user.sql 2.导出一个 ...
- SSM 框架 ---项目整合
一.SSM框架理解 Spring(业务层) Spring就像是整个项目中装配bean的大工厂,在配置文件中可以指定使用特定的参数去调用实体类的构造方法来实例化对象. Spring的核心思想是IoC(控 ...
- Android Studio插件GsonFormat
GsonFormat插件用于在androidStudio 根据json自动生成class的字段和方法,极大提高了开发效率 一.安装GsonFormat插件 二.重启Android Studio,新建一 ...