itspace
- 浏览: 984979 次
- 性别:
- 来自: 杭州
-
文章分类
最新评论
-
孤星119：
好熟悉的数据库字段啊， 上家公司做的项目每天都跟这些字段打招呼 ...
Oracle exp compress参数引起的空间浪费 -
itspace：
quxiaoyong 写道遇到个问题，网上一搜，全他妈这篇文章 ...
数据库连接错误ORA-28547 -
quxiaoyong：
遇到个问题，网上一搜，全他妈这篇文章。你转来转去的有意思吗？
数据库连接错误ORA-28547 -
hctech：
关于version count过高的问题，不知博主是否看过ey ...
某客户数据库性能诊断报告 -
itspace：
invalid 写道写的不错，我根据这个来安装，有点理解错误了 ...
AIX 配置vncserver
数据库版本为
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
运行在linux系统中
[ora10g@hzmc admin]$ uname -a
Linux hzmc 2.6.18-53.el5xen #1 SMP Mon Nov 12 03:26:12 EST 2007 i686 i686 i386 GNU/Linux
由于数据库的online redolog全部丢掉，导致数据库在open阶段时出现以下错误
alter database open
Thu Nov 3 16:55:02 2011
Beginning crash recovery of 1 threads
parallel recovery started with 2 processes
Thu Nov 3 16:55:02 2011
Started redo scan
Thu Nov 3 16:55:02 2011
Errors in file /ora10g/admin/drb/udump/drb_ora_14761.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/Tbackup/drb/redo01_1.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/Tbackup/drb/redo01.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
Thu Nov 3 16:55:02 2011
Aborting crash recovery due to error 313
Thu Nov 3 16:55:02 2011
Errors in file /ora10g/admin/drb/udump/drb_ora_14761.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/Tbackup/drb/redo01_1.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/Tbackup/drb/redo01.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
我们知道数据库在异常宕机，再次open数据库时需要扫描online redolog，从而确保数据不丢失。如果redlog丢失，存储在数据库里的业务数据可能出现不一致状态。
（如果redolog完好，数据库open过程中会进行事物恢复，从而保证事物的一致性）但目前问题的难点是在线日志已经全部丢失的情况下怎么打开数据库？从而导出业务数据。
在这种情况下，我们首先想到了一个隐含参数_allow_resetlogs_corruption，该隐含参数Oracle的解释是：allow resetlogs even if it will cause corruption，
也就是说在数据库打开过程中，如果碰到处于current或者active状态的redlog损坏，当该参数置为true时，Oracle将直接跳过redolog恢复，并打开数据库。当然，在打开数据库的过程中，
Oracle将会重建redolog。基于目前这个情况，我们将参数_allow_resetlogs_corruption置为true，并尝试打开数据库。
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
System altered.
由于需要重建redolog，所以需要将数据库进行不完全恢复，这样数据库open的时候才能使用resetlogs选项，所以我们在设好_allow_resetlogs_corruption参数并重启数据库至mount状态之后
对数据库做了不完全恢复。
SQL> recover database until cancel;
ORA-00279: change 11000485117844 generated at 11/03/2011 16:36:32 needed for
thread 1
ORA-00289: suggestion :
/ora10g/oracle/product/10.2.0/db_1/dbs/arch1_2_766254516.dbf
ORA-00280: change 11000485117844 for thread 1 is in sequence #2
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
再次尝试打开数据库，这时候意想不到事情发生了，数据库中竟然有部分数据文件的resetlogs_change#处于不一致状态。
SQL> alter database open RESETLOGS;
alter database open RESETLOGS
*
ERROR at line 1:
ORA-01190: control file or data file 11 is from before the last RESETLOGS
ORA-01110: data file 11: '/Tbackup/drb/wentest03.dbf'
SQL> select resetlogs_change#,file# from v$datafile_header;
RESETLOGS_CHANGE# FILE#
----------------- ----------
11000485117845 1
11000485117845 2
11000485117845 3
11000485117845 4
。。。
11000485117845 10
456954 11
RESETLOGS_CHANGE# FILE#
----------------- ----------
456954 12
456954 13
11000485117845 14
11000485117845 15
11000485117845 16
11000485117845 17
。。。
11000485117845 37
11000485117845 38
9745339313660 39
。。。
11000485117845 51
11000485117845 52
进一步查看数据文件状态，可以看到11,12,13号数据文件处于online状态，这几个数据文件必须要进行处理，否则业务数据将丢失，而39号数据文件在数据库正常使用时，已经处于offline状态
可以暂时不管，如果有时间，再进行处理也不迟。
SQL> select file#,status from v$datafile where file# in (11,12,13,39);
FILE# STATUS
---------- -------
11 ONLINE
12 ONLINE
13 ONLINE
39 OFFLINE
SQL> select name from v$datafile where file# in (11,12,13);
NAME
--------------------------------------------------------------------------------
/Tbackup/drb/wentest03.dbf
/Tbackup/drb/wentest02.dbf
/Tbackup/drb/wentest01.dbf
首先我们需要清晰一个概念，就是Oracle在open数据库时，需要对数据文件进行一系列检查，主要检查该数据文件是不是本数据库的文件文件（主要检查db_id,db_name）,
数据文件号和存储在滋控制文件的数据文件号是否一致(file#,rfile#),数据文件的checkpoint change和checkpoint count是否和控制文件的checkpoint change和checkpoint count一致，
正常状态下数据文件的resetlogs change和resetlogs是否处于一致等等。
以下就是Oracle 10g下，各个检查项在block 1中的位置：
Block 1：
offset：0028――0031
这四个bytes存放的dbid
offset：0032――0039
这个8个bytes存放的是数据库名的ascii码表示
offset：0040――0041
这两个字节存放的是Control Seq
offset：0052――0053
这两个字节存放的是文件号
offset：0112――0115
这四个字节存放的是reset logs count
offset：0116――0123
这六个字节存放的是reset logs scn
offset：0148――0149
这两个字节表示数据文件ctl cnt
offset：0368――00372
这四格字节表示相对文件号
offset：0484――0489
这六个字节存放的是checkpoint scn
进一步我们通过dump数据文件头，发现了一些问题，resetlogs_change，resetlog count，file number都不准确
SQL> ALTER SESSION SET EVENTS 'immediate trace name file_hdrs level 10';
Session altered.
DATA FILE #11:
(name #19) /Tbackup/drb/wentest03.dbf
creation size=2560 block size=8192 status=0xf head=19 tail=19 dup=1
tablespace 11, index=12 krfil=12 prev_file=0
unrecoverable scn: 0x0883.33ab315d 01/01/1988 00:00:00
Checkpoint cnt:4 scn: 0x0883.33a89fae 04/16/2009 02:27:10
Stop scn: 0x0883.33a89fae 01/01/1988 00:00:00
Creation Checkpointed at scn: 0x0883.33a89f0c 04/16/2009 02:21:30
thread:0 rba:(0x0.0.0)
...
aux_file is NOT DEFINED
File 11 with tablespace ID 11 is plugged in read only
V10 STYLE FILE HEADER:
Compatibility Vsn = 169870080=0xa200300
Db ID=3342305182=0xc737879e, Db Name='DRB'
Activation ID=0=0x0
Control Seq=93349=0x16ca5, File size=2560=0xa00
File Number=12, Blksiz=8192, File Type=3 DATA
Tablespace #11 - WEN rel_fn:12
Creation at scn: 0x0883.33a89f0c 04/16/2009 02:21:30
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x2803df21 scn: 0x0a01.4001ff95 reset logs terminal rcv data:0x0 scn: 0x
0000.00000000
prev reset logs count:0x24293a18 scn: 0x0000.00000001 prev reset logs terminal rcv data:0
x0 scn: 0x0000.00000000
recovered at 01/01/1988 00:00:00
status:0x0 root dba:0x00000000 chkpt cnt: 4 ctl cnt:3
begin-hot-backup file size: 0
Checkpointed at scn: 0x0883.33a89fae 04/16/2009 02:27:10
thread:1 rba:(0x5d12.14eb5.10)
现在我们的目标很清晰，就是首先需要用bbed修复数据文件11,12,13的resetlogs_change，resetlog count，file number。以修改11号数据文件为例，12号，13号修改方式类似
[ora10g@hzmc ~]$ bbed listfile=l blocksize=8192 password=blockedit
BBED> dump offset 112
BBED> modify 0xb724
BBED> dump offset 114
BBED> modify 0xac2d
BBED> dump offset 116
BBED> modify 0x95ff
BBED> dump offset 118
BBED> modify 0x0140
BBED> dump offset 52
BBED> modify 0x0b
BBED> sum apply
修改完成之后，再次进行不完全恢复，结果命令hang，问题又再次出现。
SQL> recover database until cancel;
后台日志显示：
/ora10g/admin/drb/udump/drb_ora_31042.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /ora10g/oracle/product/10.2.0/db_1
System name: Linux
Node name: hzmc
Release: 2.6.18-53.el5xen
Version: #1 SMP Mon Nov 12 03:26:12 EST 2007
Machine: i686
Instance name: drb
Redo thread mounted by this instance: 1
Oracle process number: 15
Unix process pid: 31042, image: oracle@hzmc (TNS V1-V3)
*** SERVICE NAME:() 2011-11-03 17:23:58.006
*** SESSION ID:(159.3) 2011-11-03 17:23:58.006
*** 2011-11-03 17:23:58.006
Beginning recovery file header examination (51 files)
*** 2011-11-03 17:23:58.007
Completed recovery file header examination
*** 2011-11-03 17:23:58.007
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [2130], [0], [8], [2], [], [], [], []
Current SQL statement for this session:
ALTER DATABASE RECOVER database until cancel
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+27 call ksedst1() 0 ? 1 ?
ksedmp()+557 call ksedst() 0 ? 9B8E606 ? 9B8E606 ? 155 ?
0 ? 0 ?
ksfdmp()+19 call ksedmp() 3 ? BFF69F8C ? AD0710C ?
CD49D00 ? 3 ? CCF9E38 ?
kgeriv()+188 call 00000000 CD49D00 ? 3 ?
kgeasi()+113 call kgeriv() CD49D00 ? B7F70020 ? 852 ?
3 ? BFF69FC8 ?
kccugg()+433 call kgeasi() CD49D00 ? B7F70020 ? 852 ?
2 ? 3 ? 0 ?
kcc_get_record()+32 call kccugg() 1 ? BFF6B58C ? 0 ? BFF6A1F0 ?
2 ? 200 ?
kccgri()+31 call kcc_get_record() BFF6B58C ? 0 ? BFF6A1F0 ? 2 ?
BFF6A2F0 ?
kctgdc()+52 call kccgri() BFF6B58C ? 0 ? BFF6A1F0 ?
BFF6B58C ? BFF6A0AC ?
krdsmr()+16009 call kctgdc() BFF6B58C ? BFF6AF58 ?
同时查看数据等待事件,数据库处于enq: CF - contention等待，也就是说数据库在不完全恢复时，将控制文件加锁，且没有释放
SQL> select event from v$session_wait;
EVENT
----------------------------------------------------------------
pmon timer
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
EVENT
----------------------------------------------------------------
direct path read
smon timer
SQL*Net message to client
enq: CF - contention
这时如果进行控制文件备份，命令同样挂起
SQL> alter database backup controlfile to trace resetlogs;
搜索metalink，有相关文档说这是数据库在10.2.0.3的bug，但是问题现象和我均不一样，这时候抱着试试看的态度，将数据库软件升级至10.2.0.5。
注意升级的时候需将10.2.0.3数据库软件进行备份，这样就可以保证快速回退，升级好之后，结果还是令人失望的，错误依旧。考验的时候来了，网上无解决方案，只能靠自己。
把数据库进行open reselogs打开，归根到底有2种方式：
1、进行不完全恢复命令恢复 。如
recover database until cancel；
recover database until change;
2、进行备份的控制文件进行恢复
recover database using backup controlfile;
而用到 using backup controlfile的一个办法就是将控制文件进行reselogs选项重建，现在目标又很明确，开工！
将控制文件用resetlogs选项备份
SQL> alter database backup controlfile to trace resetlogs;
Database altered.
但是在进行控制文件重建时，后台警告日志出现错误
WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command
Default Temporary Tablespace will be necessary for a locally managed database in future release
Thu Nov 3 17:41:34 2011
Errors in file /ora10g/admin/drb/udump/drb_ora_17372.trc:
ORA-00600: internal error code, arguments: [kccscf_1], [9], [93440], [65535], [], [], [], []
Thu Nov 3 17:41:35 2011
Errors in file /ora10g/admin/drb/udump/drb_ora_17372.trc:
ORA-00600: internal error code, arguments: [kccscf_1], [9], [93440], [65535], [], [], [], []
还好这次metalink有相关解释，只要将MAXLOGHISTORY选项从93440将为65536以下数字即可，经过一番努力，控制文件终于建成功，于是再次进行不完全恢复.
悲剧的是数据库在open resetlogs时再次出现错误，实例异常终止。
SQL> recover database using backup controlfile;
ORA-00279: change 11000485137852 generated at 11/03/2011 19:28:40 needed for
thread 1
ORA-00289: suggestion :
/ora10g/oracle/product/10.2.0/db_1/dbs/arch1_2_766265181.dbf
ORA-00280: change 11000485137852 for thread 1 is in sequence #2
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
马上查看后台日志，出现熟悉的ora-600 [2662]，看到这个错误就像看到久违的老朋友一样，离我们目标就不远了！
ARC1: Becoming the heartbeat ARCH
Thu Nov 3 19:36:42 2011
SMON: enabling cache recovery
Thu Nov 3 19:36:42 2011
Errors in file /ora10g/admin/drb/udump/drb_ora_32054.trc:
ORA-00600: internal error code, arguments: [2662], [2561], [1073892802], [2561], [1073892833], [4194313], [], []
Thu Nov 3 19:37:46 2011
Shutting down instance (abort)
License high water mark = 3
Instance terminated by USER, pid = 5440
解决这个错误之前，先简单的科普一下这个错误的来历。
ERROR:
ORA-600 [2662] [a] [b] [c] [d] [e]
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
这个错误的主要意思是数据库在open或者查询时，发现数据块的内容比当前的current scn大。
知道这个意思之后，解决起来也很容易
1、用bbed工具将数据块的scn改小，如果涉及到块比较多的情况下，这个方法可行性不大
2、将Oracle的current scn加大，这个可行性较高
于是我们采用第二种方案进行修复，但是又面临一个问题，当前的current scn怎么该？该多大？这里再介绍一下修改算法
计算规则如下：Arg [c]*4得出一个数值，假设为V_Wrap,
如果Arg [d]=0，则V_Wrap值为需要的level
Arg [d] < 1073741824，V_Wrap+1为需要的level
Arg [d] < 2147483648，V_Wrap+2为需要的level
Arg [d] < 3221225472，V_Wrap+3为需要的level
本案例的话，Arg [d]为1073892802，大于1073741824，所以level值为2561*4+2。
设置隐含参数_minimum_giga_scn为10245，终于成功将数据库打开，后台日志显示，scn已经递增至11001558728704
Thu Nov 3 19:39:42 2011
Completed crash recovery at
Thread 1: logseq 1, block 3, scn 11000485157857
0 data blocks read, 0 data blocks written, 0 redo blocks read
Advancing SCN to 11001558728704 according to _minimum_giga_scn
。。。
QMNC started with pid=20, OS id=21397
Thu Nov 3 19:46:36 2011
LOGSTDBY: Validating controlfile with logical metadata
Thu Nov 3 19:46:36 2011
LOGSTDBY: Validation complete
Thu Nov 3 19:46:51 2011
Completed: alter database open resetlogs
数据打开之后，接下来就是收尾工作了，检查发现表空间为READ ONLY状态
SQL> select TABLESPACE_NAME,STATUS from dba_tablespaces where TABLESPACE_NAME='WEN';
TABLESPACE_NAME STATUS
------------------------------ ---------
WEN READ ONLY
将表空间置为read write时出现以下错误，这个错误网上搜索，又是没资料，又得靠自己了
SQL> alter database datafile 13 online;
Database altered.
SQL> alter tablespace wen read write;
alter tablespace wen read write
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcpgucv1], [13], [], [], [], [],
[], []
我们知道表空间的状态其实是存储在ts$这张表格中，其状态的意思在sql.bsq中写的很清楚
create table ts$ /* tablespace table */
( ts# number not null, /* tablespace identifier number */
name varchar2("M_IDEN") not null, /* name of tablespace */
owner# number not null, /* owner of tablespace */
online$ number not null, /* status (see KTT.H): */
/* 1 = ONLINE, 2 = OFFLINE, 3 = INVALID */
contents$ number not null, /* TEMPORARY/PERMANENT */
undofile# number, /* undo_off segment file number (status is OFFLINE) */
undoblock# number, /* undo_off segment header file number */
blocksize number not null, /* size of block in bytes */
inc# number not null, /* incarnation number of extent */
scnwrp number, /* clean offline scn - zero if not offline clean */
scnbas number, /* scnbas - scn base, scnwrp - scn wrap */
dflminext number not null, /* default minimum number of extents */
dflmaxext number not null, /* default maximum number of extents */
dflinit number not null, /* default initial extent size */
dflincr number not null, /* default next extent size */
dflminlen number not null, /* default minimum extent size */
dflextpct number not null, /* default percent extent size increase */
dflogging number not null,
/* lowest bit: default logging attribute: clear=NOLOGGING, set=LOGGING */
/* second lowest bit: force logging mode */
affstrength number not null, /* Affinity strength */
bitmapped number not null, /* If not bitmapped, 0 else unit size */
/* in blocks */
plugged number not null, /* If plugged */
directallowed number not null, /* Operation which invalidate standby are */
/* allowed */
flags number not null, /* various flags */
/* 0x01 = system managed allocation */
/* 0x02 = uniform allocation */
/* if above 2 bits not set then user managed */
/* 0x04 = migrated tablespace */
/* 0x08 = tablespace being migrated */
/* 0x10 = undo tablespace */
/* 0x20 = auto segment space management */
/* if above bit not set then freelist segment managed */
/* 0x40 = COMPRESS */
/* 0x80 = ROW MOVEMENT */
/* 0x100 = SFT */
/* 0x200 = undo retention guarantee */
/* 0x400 = tablespace belongs to a group */
/* 0x800 = this actually describes a group */
pitrscnwrp number, /* scn wrap when ts was created */
pitrscnbas number, /* scn base when ts was created */
ownerinstance varchar("M_IDEN"), /* Owner instance name */
backupowner varchar("M_IDEN"), /* Backup owner instance name */
groupname varchar("M_IDEN"), /* Group name */
spare1 number, /* plug-in SCN wrap */
spare2 number, /* plug-in SCN base */
spare3 varchar2(1000),
spare4 date
)
命令不行，那我们就直接修改基表，注意此方法在正常场合不能使用
SQL> update ts$ set ONLINE$=1 where name='WEN';
1 row updated.
可以看到表空间wen已经处于online状态
SQL> select TABLESPACE_NAME,STATUS from dba_tablespaces where TABLESPACE_NAME='WEN';
TABLESPACE_NAME STATUS
------------------------------ ---------
WEN ONLINE
并已经可以读写。
SQL> create table test111 tablespace wen as select * from v$datafile;
Table created.
此时建议数据库做一次重启操作，如果正常 ，问题解决至此，就暂时告一段落了。鼓掌！！！
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
运行在linux系统中
[ora10g@hzmc admin]$ uname -a
Linux hzmc 2.6.18-53.el5xen #1 SMP Mon Nov 12 03:26:12 EST 2007 i686 i686 i386 GNU/Linux
由于数据库的online redolog全部丢掉，导致数据库在open阶段时出现以下错误
alter database open
Thu Nov 3 16:55:02 2011
Beginning crash recovery of 1 threads
parallel recovery started with 2 processes
Thu Nov 3 16:55:02 2011
Started redo scan
Thu Nov 3 16:55:02 2011
Errors in file /ora10g/admin/drb/udump/drb_ora_14761.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/Tbackup/drb/redo01_1.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/Tbackup/drb/redo01.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
Thu Nov 3 16:55:02 2011
Aborting crash recovery due to error 313
Thu Nov 3 16:55:02 2011
Errors in file /ora10g/admin/drb/udump/drb_ora_14761.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/Tbackup/drb/redo01_1.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/Tbackup/drb/redo01.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
我们知道数据库在异常宕机，再次open数据库时需要扫描online redolog，从而确保数据不丢失。如果redlog丢失，存储在数据库里的业务数据可能出现不一致状态。
（如果redolog完好，数据库open过程中会进行事物恢复，从而保证事物的一致性）但目前问题的难点是在线日志已经全部丢失的情况下怎么打开数据库？从而导出业务数据。
在这种情况下，我们首先想到了一个隐含参数_allow_resetlogs_corruption，该隐含参数Oracle的解释是：allow resetlogs even if it will cause corruption，
也就是说在数据库打开过程中，如果碰到处于current或者active状态的redlog损坏，当该参数置为true时，Oracle将直接跳过redolog恢复，并打开数据库。当然，在打开数据库的过程中，
Oracle将会重建redolog。基于目前这个情况，我们将参数_allow_resetlogs_corruption置为true，并尝试打开数据库。
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
System altered.
由于需要重建redolog，所以需要将数据库进行不完全恢复，这样数据库open的时候才能使用resetlogs选项，所以我们在设好_allow_resetlogs_corruption参数并重启数据库至mount状态之后
对数据库做了不完全恢复。
SQL> recover database until cancel;
ORA-00279: change 11000485117844 generated at 11/03/2011 16:36:32 needed for
thread 1
ORA-00289: suggestion :
/ora10g/oracle/product/10.2.0/db_1/dbs/arch1_2_766254516.dbf
ORA-00280: change 11000485117844 for thread 1 is in sequence #2
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
再次尝试打开数据库，这时候意想不到事情发生了，数据库中竟然有部分数据文件的resetlogs_change#处于不一致状态。
SQL> alter database open RESETLOGS;
alter database open RESETLOGS
*
ERROR at line 1:
ORA-01190: control file or data file 11 is from before the last RESETLOGS
ORA-01110: data file 11: '/Tbackup/drb/wentest03.dbf'
SQL> select resetlogs_change#,file# from v$datafile_header;
RESETLOGS_CHANGE# FILE#
----------------- ----------
11000485117845 1
11000485117845 2
11000485117845 3
11000485117845 4
。。。
11000485117845 10
456954 11
RESETLOGS_CHANGE# FILE#
----------------- ----------
456954 12
456954 13
11000485117845 14
11000485117845 15
11000485117845 16
11000485117845 17
。。。
11000485117845 37
11000485117845 38
9745339313660 39
。。。
11000485117845 51
11000485117845 52
进一步查看数据文件状态，可以看到11,12,13号数据文件处于online状态，这几个数据文件必须要进行处理，否则业务数据将丢失，而39号数据文件在数据库正常使用时，已经处于offline状态
可以暂时不管，如果有时间，再进行处理也不迟。
SQL> select file#,status from v$datafile where file# in (11,12,13,39);
FILE# STATUS
---------- -------
11 ONLINE
12 ONLINE
13 ONLINE
39 OFFLINE
SQL> select name from v$datafile where file# in (11,12,13);
NAME
--------------------------------------------------------------------------------
/Tbackup/drb/wentest03.dbf
/Tbackup/drb/wentest02.dbf
/Tbackup/drb/wentest01.dbf
首先我们需要清晰一个概念，就是Oracle在open数据库时，需要对数据文件进行一系列检查，主要检查该数据文件是不是本数据库的文件文件（主要检查db_id,db_name）,
数据文件号和存储在滋控制文件的数据文件号是否一致(file#,rfile#),数据文件的checkpoint change和checkpoint count是否和控制文件的checkpoint change和checkpoint count一致，
正常状态下数据文件的resetlogs change和resetlogs是否处于一致等等。
以下就是Oracle 10g下，各个检查项在block 1中的位置：
Block 1：
offset：0028――0031
这四个bytes存放的dbid
offset：0032――0039
这个8个bytes存放的是数据库名的ascii码表示
offset：0040――0041
这两个字节存放的是Control Seq
offset：0052――0053
这两个字节存放的是文件号
offset：0112――0115
这四个字节存放的是reset logs count
offset：0116――0123
这六个字节存放的是reset logs scn
offset：0148――0149
这两个字节表示数据文件ctl cnt
offset：0368――00372
这四格字节表示相对文件号
offset：0484――0489
这六个字节存放的是checkpoint scn
进一步我们通过dump数据文件头，发现了一些问题，resetlogs_change，resetlog count，file number都不准确
SQL> ALTER SESSION SET EVENTS 'immediate trace name file_hdrs level 10';
Session altered.
DATA FILE #11:
(name #19) /Tbackup/drb/wentest03.dbf
creation size=2560 block size=8192 status=0xf head=19 tail=19 dup=1
tablespace 11, index=12 krfil=12 prev_file=0
unrecoverable scn: 0x0883.33ab315d 01/01/1988 00:00:00
Checkpoint cnt:4 scn: 0x0883.33a89fae 04/16/2009 02:27:10
Stop scn: 0x0883.33a89fae 01/01/1988 00:00:00
Creation Checkpointed at scn: 0x0883.33a89f0c 04/16/2009 02:21:30
thread:0 rba:(0x0.0.0)
...
aux_file is NOT DEFINED
File 11 with tablespace ID 11 is plugged in read only
V10 STYLE FILE HEADER:
Compatibility Vsn = 169870080=0xa200300
Db ID=3342305182=0xc737879e, Db Name='DRB'
Activation ID=0=0x0
Control Seq=93349=0x16ca5, File size=2560=0xa00
File Number=12, Blksiz=8192, File Type=3 DATA
Tablespace #11 - WEN rel_fn:12
Creation at scn: 0x0883.33a89f0c 04/16/2009 02:21:30
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x2803df21 scn: 0x0a01.4001ff95 reset logs terminal rcv data:0x0 scn: 0x
0000.00000000
prev reset logs count:0x24293a18 scn: 0x0000.00000001 prev reset logs terminal rcv data:0
x0 scn: 0x0000.00000000
recovered at 01/01/1988 00:00:00
status:0x0 root dba:0x00000000 chkpt cnt: 4 ctl cnt:3
begin-hot-backup file size: 0
Checkpointed at scn: 0x0883.33a89fae 04/16/2009 02:27:10
thread:1 rba:(0x5d12.14eb5.10)
现在我们的目标很清晰，就是首先需要用bbed修复数据文件11,12,13的resetlogs_change，resetlog count，file number。以修改11号数据文件为例，12号，13号修改方式类似
[ora10g@hzmc ~]$ bbed listfile=l blocksize=8192 password=blockedit
BBED> dump offset 112
BBED> modify 0xb724
BBED> dump offset 114
BBED> modify 0xac2d
BBED> dump offset 116
BBED> modify 0x95ff
BBED> dump offset 118
BBED> modify 0x0140
BBED> dump offset 52
BBED> modify 0x0b
BBED> sum apply
修改完成之后，再次进行不完全恢复，结果命令hang，问题又再次出现。
SQL> recover database until cancel;
后台日志显示：
/ora10g/admin/drb/udump/drb_ora_31042.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /ora10g/oracle/product/10.2.0/db_1
System name: Linux
Node name: hzmc
Release: 2.6.18-53.el5xen
Version: #1 SMP Mon Nov 12 03:26:12 EST 2007
Machine: i686
Instance name: drb
Redo thread mounted by this instance: 1
Oracle process number: 15
Unix process pid: 31042, image: oracle@hzmc (TNS V1-V3)
*** SERVICE NAME:() 2011-11-03 17:23:58.006
*** SESSION ID:(159.3) 2011-11-03 17:23:58.006
*** 2011-11-03 17:23:58.006
Beginning recovery file header examination (51 files)
*** 2011-11-03 17:23:58.007
Completed recovery file header examination
*** 2011-11-03 17:23:58.007
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [2130], [0], [8], [2], [], [], [], []
Current SQL statement for this session:
ALTER DATABASE RECOVER database until cancel
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+27 call ksedst1() 0 ? 1 ?
ksedmp()+557 call ksedst() 0 ? 9B8E606 ? 9B8E606 ? 155 ?
0 ? 0 ?
ksfdmp()+19 call ksedmp() 3 ? BFF69F8C ? AD0710C ?
CD49D00 ? 3 ? CCF9E38 ?
kgeriv()+188 call 00000000 CD49D00 ? 3 ?
kgeasi()+113 call kgeriv() CD49D00 ? B7F70020 ? 852 ?
3 ? BFF69FC8 ?
kccugg()+433 call kgeasi() CD49D00 ? B7F70020 ? 852 ?
2 ? 3 ? 0 ?
kcc_get_record()+32 call kccugg() 1 ? BFF6B58C ? 0 ? BFF6A1F0 ?
2 ? 200 ?
kccgri()+31 call kcc_get_record() BFF6B58C ? 0 ? BFF6A1F0 ? 2 ?
BFF6A2F0 ?
kctgdc()+52 call kccgri() BFF6B58C ? 0 ? BFF6A1F0 ?
BFF6B58C ? BFF6A0AC ?
krdsmr()+16009 call kctgdc() BFF6B58C ? BFF6AF58 ?
同时查看数据等待事件,数据库处于enq: CF - contention等待，也就是说数据库在不完全恢复时，将控制文件加锁，且没有释放
SQL> select event from v$session_wait;
EVENT
----------------------------------------------------------------
pmon timer
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
rdbms ipc message
EVENT
----------------------------------------------------------------
direct path read
smon timer
SQL*Net message to client
enq: CF - contention
这时如果进行控制文件备份，命令同样挂起
SQL> alter database backup controlfile to trace resetlogs;
搜索metalink，有相关文档说这是数据库在10.2.0.3的bug，但是问题现象和我均不一样，这时候抱着试试看的态度，将数据库软件升级至10.2.0.5。
注意升级的时候需将10.2.0.3数据库软件进行备份，这样就可以保证快速回退，升级好之后，结果还是令人失望的，错误依旧。考验的时候来了，网上无解决方案，只能靠自己。
把数据库进行open reselogs打开，归根到底有2种方式：
1、进行不完全恢复命令恢复 。如
recover database until cancel；
recover database until change;
2、进行备份的控制文件进行恢复
recover database using backup controlfile;
而用到 using backup controlfile的一个办法就是将控制文件进行reselogs选项重建，现在目标又很明确，开工！
将控制文件用resetlogs选项备份
SQL> alter database backup controlfile to trace resetlogs;
Database altered.
但是在进行控制文件重建时，后台警告日志出现错误
WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command
Default Temporary Tablespace will be necessary for a locally managed database in future release
Thu Nov 3 17:41:34 2011
Errors in file /ora10g/admin/drb/udump/drb_ora_17372.trc:
ORA-00600: internal error code, arguments: [kccscf_1], [9], [93440], [65535], [], [], [], []
Thu Nov 3 17:41:35 2011
Errors in file /ora10g/admin/drb/udump/drb_ora_17372.trc:
ORA-00600: internal error code, arguments: [kccscf_1], [9], [93440], [65535], [], [], [], []
还好这次metalink有相关解释，只要将MAXLOGHISTORY选项从93440将为65536以下数字即可，经过一番努力，控制文件终于建成功，于是再次进行不完全恢复.
悲剧的是数据库在open resetlogs时再次出现错误，实例异常终止。
SQL> recover database using backup controlfile;
ORA-00279: change 11000485137852 generated at 11/03/2011 19:28:40 needed for
thread 1
ORA-00289: suggestion :
/ora10g/oracle/product/10.2.0/db_1/dbs/arch1_2_766265181.dbf
ORA-00280: change 11000485137852 for thread 1 is in sequence #2
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
马上查看后台日志，出现熟悉的ora-600 [2662]，看到这个错误就像看到久违的老朋友一样，离我们目标就不远了！
ARC1: Becoming the heartbeat ARCH
Thu Nov 3 19:36:42 2011
SMON: enabling cache recovery
Thu Nov 3 19:36:42 2011
Errors in file /ora10g/admin/drb/udump/drb_ora_32054.trc:
ORA-00600: internal error code, arguments: [2662], [2561], [1073892802], [2561], [1073892833], [4194313], [], []
Thu Nov 3 19:37:46 2011
Shutting down instance (abort)
License high water mark = 3
Instance terminated by USER, pid = 5440
解决这个错误之前，先简单的科普一下这个错误的来历。
ERROR:
ORA-600 [2662] [a] [b] [c] [d] [e]
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
这个错误的主要意思是数据库在open或者查询时，发现数据块的内容比当前的current scn大。
知道这个意思之后，解决起来也很容易
1、用bbed工具将数据块的scn改小，如果涉及到块比较多的情况下，这个方法可行性不大
2、将Oracle的current scn加大，这个可行性较高
于是我们采用第二种方案进行修复，但是又面临一个问题，当前的current scn怎么该？该多大？这里再介绍一下修改算法
计算规则如下：Arg [c]*4得出一个数值，假设为V_Wrap,
如果Arg [d]=0，则V_Wrap值为需要的level
Arg [d] < 1073741824，V_Wrap+1为需要的level
Arg [d] < 2147483648，V_Wrap+2为需要的level
Arg [d] < 3221225472，V_Wrap+3为需要的level
本案例的话，Arg [d]为1073892802，大于1073741824，所以level值为2561*4+2。
设置隐含参数_minimum_giga_scn为10245，终于成功将数据库打开，后台日志显示，scn已经递增至11001558728704
Thu Nov 3 19:39:42 2011
Completed crash recovery at
Thread 1: logseq 1, block 3, scn 11000485157857
0 data blocks read, 0 data blocks written, 0 redo blocks read
Advancing SCN to 11001558728704 according to _minimum_giga_scn
。。。
QMNC started with pid=20, OS id=21397
Thu Nov 3 19:46:36 2011
LOGSTDBY: Validating controlfile with logical metadata
Thu Nov 3 19:46:36 2011
LOGSTDBY: Validation complete
Thu Nov 3 19:46:51 2011
Completed: alter database open resetlogs
数据打开之后，接下来就是收尾工作了，检查发现表空间为READ ONLY状态
SQL> select TABLESPACE_NAME,STATUS from dba_tablespaces where TABLESPACE_NAME='WEN';
TABLESPACE_NAME STATUS
------------------------------ ---------
WEN READ ONLY
将表空间置为read write时出现以下错误，这个错误网上搜索，又是没资料，又得靠自己了
SQL> alter database datafile 13 online;
Database altered.
SQL> alter tablespace wen read write;
alter tablespace wen read write
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcpgucv1], [13], [], [], [], [],
[], []
我们知道表空间的状态其实是存储在ts$这张表格中，其状态的意思在sql.bsq中写的很清楚
create table ts$ /* tablespace table */
( ts# number not null, /* tablespace identifier number */
name varchar2("M_IDEN") not null, /* name of tablespace */
owner# number not null, /* owner of tablespace */
online$ number not null, /* status (see KTT.H): */
/* 1 = ONLINE, 2 = OFFLINE, 3 = INVALID */
contents$ number not null, /* TEMPORARY/PERMANENT */
undofile# number, /* undo_off segment file number (status is OFFLINE) */
undoblock# number, /* undo_off segment header file number */
blocksize number not null, /* size of block in bytes */
inc# number not null, /* incarnation number of extent */
scnwrp number, /* clean offline scn - zero if not offline clean */
scnbas number, /* scnbas - scn base, scnwrp - scn wrap */
dflminext number not null, /* default minimum number of extents */
dflmaxext number not null, /* default maximum number of extents */
dflinit number not null, /* default initial extent size */
dflincr number not null, /* default next extent size */
dflminlen number not null, /* default minimum extent size */
dflextpct number not null, /* default percent extent size increase */
dflogging number not null,
/* lowest bit: default logging attribute: clear=NOLOGGING, set=LOGGING */
/* second lowest bit: force logging mode */
affstrength number not null, /* Affinity strength */
bitmapped number not null, /* If not bitmapped, 0 else unit size */
/* in blocks */
plugged number not null, /* If plugged */
directallowed number not null, /* Operation which invalidate standby are */
/* allowed */
flags number not null, /* various flags */
/* 0x01 = system managed allocation */
/* 0x02 = uniform allocation */
/* if above 2 bits not set then user managed */
/* 0x04 = migrated tablespace */
/* 0x08 = tablespace being migrated */
/* 0x10 = undo tablespace */
/* 0x20 = auto segment space management */
/* if above bit not set then freelist segment managed */
/* 0x40 = COMPRESS */
/* 0x80 = ROW MOVEMENT */
/* 0x100 = SFT */
/* 0x200 = undo retention guarantee */
/* 0x400 = tablespace belongs to a group */
/* 0x800 = this actually describes a group */
pitrscnwrp number, /* scn wrap when ts was created */
pitrscnbas number, /* scn base when ts was created */
ownerinstance varchar("M_IDEN"), /* Owner instance name */
backupowner varchar("M_IDEN"), /* Backup owner instance name */
groupname varchar("M_IDEN"), /* Group name */
spare1 number, /* plug-in SCN wrap */
spare2 number, /* plug-in SCN base */
spare3 varchar2(1000),
spare4 date
)
命令不行，那我们就直接修改基表，注意此方法在正常场合不能使用
SQL> update ts$ set ONLINE$=1 where name='WEN';
1 row updated.
可以看到表空间wen已经处于online状态
SQL> select TABLESPACE_NAME,STATUS from dba_tablespaces where TABLESPACE_NAME='WEN';
TABLESPACE_NAME STATUS
------------------------------ ---------
WEN ONLINE
并已经可以读写。
SQL> create table test111 tablespace wen as select * from v$datafile;
Table created.
此时建议数据库做一次重启操作，如果正常 ，问题解决至此，就暂时告一段落了。鼓掌！！！
0
顶
顶
1
踩
踩
分享到：
发表评论
-
buffer cache 的内部结构
2020-03-18 14:21 594BUFFER CACHE作为数据块的 ... -
Oracle OMC介绍
2020-03-18 13:19 500Oracle管理云服务（OMC）的大数据平台，自动收集的企业 ... -
参加Oracle勒索病毒防范专题培训会议
2019-09-27 17:15 5492019年7月22日，受邀参加Oracle勒索病毒防范专题培训 ... -
记一次内存换IO的Oracle优化
2019-09-27 16:50 839某客户数据库从P595物理 ... -
如何定位Oracle SQL执行计划变化的原因
2019-07-03 14:49 1483性能优化最难的是能够 ... -
如何定位Oracle SQL执行计划变化的原因
2018-10-30 09:24 1185性能优化最难的是能够 ... -
数据库性能优化目标
2018-10-08 10:59 535从数据库性能优化的场 ... -
数据库无法打开的原因及解决办法
2018-10-05 20:45 2156数据库的启动是一个相当复杂的过程。比如，Oracle在启动之前 ... -
怎么样彻底删除数据库？
2018-09-18 11:10 617Oracle提供了drop database命令用来删除数据库 ... -
Oracle减少日志量的方法
2018-09-10 10:17 879LGWR进程将LOG BUFFER中的 ... -
如何快速关闭数据库
2018-09-09 13:14 1249“一朝被蛇咬，十年怕井绳”。在没被“蛇”咬之前，很多DBA喜欢 ... -
关于《如何落地智能化运维》PPT
2018-05-17 10:19 1145在DTCC 2018发表《如何落地智能化运维》演讲，主要内容如 ... -
记录在redhat5.8平台安装oracle11.2容易忽视的几个问题
2018-05-11 19:58 590问题一：ping不通问题 在虚拟机上安装好linux系统后， ... -
《Oracle DBA实战攻略》第一章
2018-05-11 10:42 979即日起，不定期更新《OracleDBA实战攻略》一书电子版，请 ... -
Oracle 12c新特性
2018-05-11 10:33 912查询所有pdb [oracle@gj4 ~]$ sqlplu ... -
关于修改memory_target的值后数据库无法启动的问题
2017-02-28 12:24 3995操作系统：RHEL6.5 数据库版本：11.2.0.4 ... -
10g rac安装error while loading shared libraries libpthread.so.0 问题
2017-02-28 12:22 71211g rac安装在二节点跑脚本一般会报此错误： 解决这个问 ... -
记一次Oracle会话共享模式故障处理过程
2017-02-27 19:16 811故障简述 XXX第八人民医院HIS数据库7月13日11点左右从 ... -
RESMGR:cpu quantum等待事件处理过程
2017-02-27 18:23 2690由于数据库上线过程中出现大量的RESMGR:cpu quant ... -
谈谈log file sync
2014-03-19 14:18 1786数据库中的log file sync等待事件指的是，当user ...
相关推荐
风光储直流微电网Simulink仿真模型：光伏发电、风力发电与混合储能系统的协同运作及并网逆变器VSR的研究,风光储直流微电网Simulink仿真模型：MPPT控制、混合储能系统、VSR并网逆变器的设计与实现,风光储、风光储并网直流微电网simulink仿真模型。 系统由光伏发电系统、风力发电系统、混合储能系统（可单独储能系统）、逆变器VSR?大电网构成。 光伏系统采用扰动观察法实现mppt控制，经过boost电路并入母线； 风机采用最佳叶尖速比实现mppt控制，风力发电系统中pmsg采用零d轴控制实现功率输出，通过三相电压型pwm变器整流并入母线； 混合储能由蓄电池和超级电容构成，通过双向DCDC变器并入母线，并采用低通滤波器实现功率分配，超级电容响应高频功率分量，蓄电池响应低频功率分量，有限抑制系统中功率波动，且符合储能的各自特性。 并网逆变器VSR采用PQ控制实现功率入网。 ,风光储; 直流微电网; simulink仿真模型; 光伏发电系统; 最佳叶尖速比控制; MPPT控制; Boost电路; 三相电压型PWM变换器;
以下是针对初学者的 **51单片机入门教程**，内容涵盖基础概念、开发环境搭建、编程实践及常见应用示例，帮助你快速上手。
【Python毕设】根据你提供的课程代码，自动排出可行课表，适用于西工大选课_pgj
【毕业设计】[零食商贩]-基于vue全家桶+koa2+sequelize+mysql搭建的移动商城应用
电动汽车充电背景下的微电网谐波抑制策略与风力发电系统仿真研究,电动汽车充电微电网的谐波抑制策略与风力发电系统仿真研究,基于电动汽车充电的微电网谐波抑制策略研究，包括电动汽车充电负 载模型，风电模型，光伏发现系统，储能系统，以及谐波处理模块 风力发电系统仿真 ,电动汽车充电负载模型; 风电模型; 光伏发现系统; 储能系统; 谐波处理模块; 风力发电系统仿真,电动汽车充电微电网的谐波抑制策略研究：整合负载模型、风电模型与光伏储能系统
Vscode部署本地Deepseek的continue插件windows版本
内容概要：本文详细介绍了滤波器的两个关键参数——截止频率(F0)和品质因素(Q)，并探讨了不同类型的滤波器（包括低通、高通、带通和带阻滤波器）的设计方法及其特性。文章首先明确了F0和Q的基本概念及其在滤波器性能中的作用，接着通过数学推导和图形展示的方式，解释了不同Q值对滤波器频率响应的影响。文中特别指出，通过调整Q值可以控制滤波器的峰谷效果和滚降速度，进而优化系统的滤波性能。此外，还讨论了不同类型滤波器的具体应用场景，如低通滤波器适用于消除高频噪声，高通滤波器用于去除直流分量和低频干扰，而带通滤波器和带阻滤波器分别用于选取特定频段信号和排除不需要的频段。最后，通过对具体案例的解析，帮助读者更好地理解和应用相关理论。 适合人群：电子工程及相关领域的技术人员、研究人员以及高校学生，特别是那些需要深入了解滤波器设计原理的人群。 使用场景及目标：适用于从事模拟电路设计的专业人士，尤其是希望掌握滤波器设计细节和技术的应用场合。目标是让读者能够灵活运用Q值和F0来优化滤波器设计，提升系统的信噪比和选择性，确保信号的纯净性和完整性。
内容概要：本文主要讲述了利用QUARTUSⅡ进行电子设计自动化的具体步骤和实例操作，详细介绍了如何利用EDA技术在QUARTUSⅡ环境中设计并模拟下降沿D触发器的工作过程，重点探讨了系统规格设计、功能描述、设计处理、器件编译和测试四个步骤及相关的设计验证流程，如功能仿真、逻辑综合及时序仿真等内容，并通过具体的操作指南展示了电路设计的实际操作方法。此外还强调了QUARTUSⅡ作为一款集成了多种功能的综合平台的优势及其对于提高工作效率的重要性。 适用人群：电子工程、自动化等相关专业的学生或者工程师，尤其适用于初次接触EDA技术和QuartusⅡ的用户。 使用场景及目标：旨在帮助用户理解和掌握使用QUARTUSⅡ这一先进的EDA工具软件进行从概念设计到最后成品制作整个电路设计过程的方法和技巧。目标是在实际工作中能够熟练运用QUARTUSⅡ完成各类复杂电子系统的高效设计。 其他说明：文中通过具体的案例让读者更直观理解EDA设计理念和技术特点的同时也为进一步探索EDA领域的前沿课题打下了良好基础。此外它还提到了未来可能的发展方向，比如EDA工具的功能增强趋势等。
Simulink建模下的光储系统与IEEE33节点配电网的协同并网运行：光照强度变化下的储能系统优化策略与输出性能分析,Simulink模型下的光伏微网系统：光储协同，实现380v电压等级下的恒定功率并网与平抑波动,Simulink含光伏的IEEE33节点配电网模型 微网，光储系统并网运行 光照强度发生改变时，储能可以有效配合光伏进行恒定功率并网，平抑波动，实现削峰填谷。 总的输出有功为270kw（图23） 无功为0 检验可以并网到电压等级为380v的电网上 逆变侧输出电压电流稳定（图4） ,Simulink; 含光伏; 配电网模型; 微网; 光储系统; 储能配合; 恒定功率并网; 电压等级; 逆变侧输出。,Simulink光伏微网模型：光储协同并网运行，实现功率稳定输出
基于Andres ELeon新法的双馈风机次同步振荡抑制策略：附加阻尼控制（SDC）的实践与应用,双馈风机次同步振荡的抑制策略研究：基于转子侧附加阻尼控制（SDC）的应用与效能分析,双馈风机次同步振荡抑制策略（一） 含 基于转子侧附加阻尼控制（SDC）的双馈风机次同步振荡抑制，不懂就问， 附加阻尼控制 (SDC)被添加到 RSC 内部控制器的q轴输出中。 这种方法是由Andres ELeon在2016年提出的。 该方法由增益、超前滞后补偿器和带通滤波器组成。 采用实测的有功功率作为输入信号。 有关更多信息，你可以阅读 Andres ELeon 的lunwen。 附lunwen ,关键词：双馈风机、次同步振荡、抑制策略；转子侧附加阻尼控制（SDC）；RSC内部控制器；Andres ELeon；增益；超前滞后补偿器；带通滤波器；实测有功功率。,双馈风机次同步振荡抑制技术：基于SDC与RSCq轴控制的策略研究
springboot疫情防控期间某村外出务工人员信息管理系统--
高效光伏并网发电系统MATLAB Simulink仿真设计与MPPT技术应用及PI调节闭环控制,光伏并网发电系统MATLAB Simulink仿真设计：涵盖电池、BOOST电路、逆变电路及MPPT技术效率提升,光伏并网发电系统MATLAB Simulink仿真设计。 该仿真包括电池，BOOST升压电路，单相全桥逆变电路，电压电流双闭环控制部分；应用MPPT技术，提高光伏发电的利用效率。 采用PI调节方式进行闭环控制，SPWM调制，采用定步长扰动观测法，对最大功率点进行跟踪，可以很好的提高发电效率和实现并网要求。 ,光伏并网发电系统; MATLAB Simulink仿真设计; 电池; BOOST升压电路; 单相全桥逆变电路; 电压电流双闭环控制; MPPT技术; PI调节方式; SPWM调制; 定步长扰动观测法。,光伏并网发电系统Simulink仿真设计：高效MPPT与PI调节控制策略
PFC 6.0高效循环加载系统：支持半正弦、半余弦及多级变荷载功能,PFC 6.0循环加载代码：支持半正弦、半余弦及多级变荷载的强大功能,PFC6.0循环加载代码，支持半正弦，半余弦函数加载，中间变荷载等。 多级加载 ,PFC6.0; 循环加载代码; 半正弦/半余弦函数加载; 中间变荷载; 多级加载,PFC6.0多级半正弦半余弦循环加载系统
某站1K的校园跑腿小程序 多校园版二手市场校园圈子失物招领 食堂/快递代拿代买跑腿 多校版本，多模块，适合跑腿，外卖，表白，二手，快递等校园服务 需要自己准备好后台的服务器，已认证的小程序，备案的域名！
【Python毕设】根据你提供的课程代码，自动排出可行课表，适用于西工大选课
COMSOL锂枝晶模型：五合一的相场、浓度场与电场模拟研究，涵盖单枝晶定向生长、多枝晶生长及无序生长等多元现象的探索,COMSOL锂枝晶模型深度解析：五合一技术揭示单枝晶至雪花枝晶的生长机制与物理场影响,comsol锂枝晶模型 五合一 单枝晶定向生长、多枝晶定向生长、多枝晶随机生长、无序生长随机形核以及雪花枝晶，包含相场、浓度场和电场三种物理场（雪花枝晶除外），其中单枝晶定向生长另外包含对应的参考文献。 ,comsol锂枝晶模型; 五合一模型; 单枝晶定向生长; 多枝晶定向生长; 多枝晶随机生长; 无序生长随机形核; 雪花枝晶; 相场、浓度场、电场物理场; 参考文献,COMSOL锂枝晶模型：多场景定向生长与相场电场分析
嵌入式大学生 点阵代码
那个有delphi12 tedgebrowser 使用的dll
基于DQN算法的微网储能优化调度与能量管理：深度强化学习的应用与实践,基于DQN算法的微网储能优化调度与能量管理：深度强化学习的应用与实践,基于DQN算法的微网储能运行优化与能量管理 关键词：微网 优化调度 储能优化 深度强化学习 DQN 编程语言：python 参考文献:《Explainable AI Deep Reinforcement Learning Agents for Residential Demand Side Cost Savings in Smart Grids》 内容简介： 受深层强化学习（RL）最新进展的激励，我们开发了一个RL代理来管理家庭中存储设备的操作，旨在最大限度地节省需求侧的成本。 所提出的技术是数据驱动的，并且RL代理从头开始学习如何在可变费率结构下有效地使用能量存储设备，即收缩“黑匣子”的概念，其中代理所学的技术被忽略。 我们解释了RL-agent的学习过程，以及基于存储设备容量的策略。 ,微网; 优化调度; 储能优化; 深度强化学习; DQN; 家庭存储设备; 需求侧成本节省; 智能电网; RL代理; 能量存储设备。,基于DQN算法的微网储
内容概要：该文档为FM17580的原理图设计文件，重点介绍了这款非接触式IC卡读写芯片的电路设计细节。文档详细列出了各个元器件及其连接方式、引脚分配及具体值设定。特别值得注意的是，为了确保性能和可靠性，在PCB布局时强调了GND线需要尽量以最短路径连回FM175xx芯片的TVSS引脚附近，并且靠近电源输入端（TVDD）。同时明确了FM17580只兼容SPI通讯协议，其他如IIC或UART选项则不在支持范围内。此外还提供了关于降低能耗的选择——移除不必要的ADC检测电路，这对于一些特定应用场景非常有用。 适合人群：具备硬件开发经验和RFID/NFC领域基础知识的技术人员或研究人员。 使用场景及目标：适用于需要详细了解FM17580内部结构和技术特性的项目团队；旨在帮助工程师们快速上手搭建实验平台并测试FM17580的功能特性。主要目的是为实际应用开发提供技术支持和参考。 其他说明：文档最后附带了一些附加信息，包括设计师名字、公司名称以及审查流程的相关内容，但具体内容并未公开。此外还提到该文档是针对FM17580评估板（即FM17580Demo）的设计图纸。文中出现多次类似表格可能是不同版本之间的对比或者记录修改历史的部分内容。