




版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
1、Oracle DBA 2Chapter 11:深入Dependency$对象的恢复题记: Eygle 曾经在“案例:Move 系统表 DEPENDENCY$导致索引失效的数据库故障”(.html)里描述了一个将 DEPENDENCY$表 move 后,忘记了 rebuild 索引就 shutdown后发现库再也起不来的案例。本章通过对这个案例的重现、模拟和解决,深入解析数据库字典对象的原理、作用与故障处理,希望能够帮助大家深入理解 Oracle数据库的内部体系结构。作者简介崔华,网名 dbsnakeOracleACEDirector,ACOUG不停歇,2017,云和恩墨伴你数据驱动,成就未来,
2、云和恩墨,成就所托。DBA 手记 21.1 重现 Move 表失效索引的故障首先我们先来重现一下这个问题:通过 SQL 命令移动系统表:注意此时该表的相关索引处于UNUSABLE 的状态:如果此时关闭数据库,下一次将无法正常启动数据库:检查告警日志文件,可以发现具体的错误据库无法启动:,数据库提示索引不可用,递归引导失败,数·2·Thu Jul 15 12:46:50 2010Errors in file /cadrasu01/app/oracle/admin/testdb/udump/testdb_ora_5038294.trc:SQL>shutdown immed
3、iate; Database closed.Database dismounted. ORACLE instance shut down.SQL>startup pfile=/dras20/testdb/inittestdb.ora ORACLE instance started.Database mounted.ORA-01092: ORACLE instance terminated. Disconnection forcedSQL>selectowner,index_name,tablespace_name,statusfromdba_indexeswhere table_n
4、ame='DEPENDENCY$'OWNERINDEX_NAMETABLESPACE_NAMESTATUSSYSI_DEPENDENCY1SYSTEMUNUSABLESYSI_DEPENDENCY2SYSTEMUNUSABLESQL>alter table DEPENDENCY$ move tablespace system;Table altered.P550_04_LA:oracle:/dras20/testdb#sqlplus '/ as sysdba'SQL*Plus: Release 9.2.0.6.0 - Production on Thu J
5、ul 15 12:41:08 2010 Copyright (c) 1982, 2002, Oracle Corporation.s.Connected to an idle instance.SQL>startup pfile=/dras20/testdb/inittestdb.ora ORACLE instance started.Database mounted.Database opened.深入Dependency$对象的恢复从结果里我们可以看到上述库如我们所期望的那样起不来了,故障得以重现。至于上述库为什么起不来,eygle 曾经就这个问题做过描述,我这里一下:是有的,注意,
6、我这里的方法过于 internal,我希望有没有办法可以把上述库起起来呢?朋友们永远不要在生产环境中用到,使用如下方法只是为了将 Oracle 的原理更好的展现出来,理解和懂得远比技巧更重要。我曾经对很多朋友都说过外科医生做手术的时候用的是手术刀,我们的手术刀就是·3·这一问题的根本在于,数据库启动过程中,会进行如下验证:selectowner#,name,namespace,remoteowner,linkname,p_timestamp,p_obj#,d_owner#, nvl(property,0),subname from dependency$,obj$ wher
7、e d_obj#=:1 and p_obj#=obj#(+) order by order#这一验证会导致如下执行计划:FETCH #5:c=10000,e=8426,p=3,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=17525911159627STAT #5 id=1 cnt=0 pid=0 pos=1 obj=0 op='SORT ORDER BY (cr=3 pr=3 pw=0 time=8434 us)' STAT #5 id=2 cnt=0 pid=1 pos=1 obj=0 op='NESTED LOOPS OUTER (cr=3
8、 pr=3 pw=0 time=8418 us)' STAT #5 id=3 cnt=0 pid=2 pos=1 obj=92 op='TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=3 pr=3pw=0 time=8416 us)'STAT #5 id=4 cnt=0 pid=3 pos=1 obj=122 op='INDEX RANGE SCAN I_DEPENDENCY1 (cr=3 pr=3 pw=0 time=8414 us)'STAT #5 id=5 cnt=0 pid=2 pos=2 obj=18 o
9、p='TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us)'STAT #5 id=6 cnt=0 pid=5 pos=1 obj=36 op='INDEX UNIQUE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us)'这里的'INDEX UNIQUE SCAN I_DEPENDENCY1"就导致了最后的错误:ORA-00704: bootstrap process failureORA-00604: error occurred at recursi
10、ve SQL level 1ORA-01502: index 'SYS.I_DEPENDENCY1' or partition of such index is in unusable state EXEC #1:c=0,e=633371,p=39,cr=619,cu=1,mis=0,r=0,dep=0,og=2,tim=1105782888673612 ERROR #1:err=1092 tim=1563018104可惜 Oracle 并不置所有索引于不顾,否则就有救了.ORA-00704: bootstrap process failureORA-00604: error
11、occurred at recursive SQL level 1ORA-01502: index 'SYS.I_DEPENDENCY1' or partition of such index is in unusable state Thu Jul 15 12:46:50 2010Error 704 happened during db open, shutting down database USER: terminating instance due to error 704Instance terminated by USER, pid = 5038294ORA-109
12、2 signalled during: ALTER DATABASE OPEN.DBA 手记 2BBED。1.2 故障的解决思路这个问题处理思路就是骗过 Oracle ,让数据库不知道索引 I_DEPENDENCY1 和I_DEPENDENCY2 的存在,这样 SQL 执行时自然就会选择全表扫描 dependency$,从而就在根本上规避了上述错误。一切的就在于以下这句 SQL 的执行计划选择:要想修改 dependency$上的索引 I_DEPENDENCY1 和 I_DEPENDENCY2,我们首先要知道oracle 如何去某个表上是否存在索引?实际上,oracle某个表上是否存在索引只会
13、去检索表 ind$。因此,我们此时最直观的思路就是将 ind$中的 I_DEPENDENCY1 和 I_DEPENDENCY2删除就好了, 这样 oracle 就不知道 dependency$ 上存在索引 I_DEPENDENCY1 和I_DEPENDENCY2 了。1.3 获得字典表信息要想去删除 IND$中的I_DEPENDENCY1 和 I_DEPENDENCY2,我们必须得知道这两条存在数据字典的什么地方,也就是说我们要知道其物理请注意上述库现在是处于未 open 的状态,所以我们没法去位置。数据字典。怎么办呢? 的工具进行数据卸载我们可以在其他类似数据库中去确认,也可以通过第,这里我
14、们用到老熊()写的 ODU。数据字典表 obj$ unload 出来:首先然后我们从 unload 出来的文本文件中就可以知道 DEPENDENCY$,I_DEPENDENCY1,I_DEPENDENCY2 的 object id、data object id 和 ts#分别是多少:·4·P550_04_LA:oracle:/cadrasu01/app/oracle/product/9.2.0/odu/data#ls -lrt total 8256-rw-r-r-1 oracledba3999 Jun 02 14:59 SCOTT_TEST_DELETE.txt省略显示部分
15、内容-rw-r-r-1 oracledba600 Aug 20 16:03 SYS_OBJ$.sqlODU> unload table sys.obj$Unloading table: OBJ$,object ID: 18Unloading segment,storage(Obj#=18 DataObj#=18 TS#=0 File#=1 Block#=121 Cluster=0) 30009 rows unloadedselectowner#,name,namespace,remoteowner,linkname,p_timestamp,p_obj#,d_owner#,nvl(prop
16、erty,0),subname from dependency$,obj$ where d_obj#=:1 and p_obj#=obj#(+) order by order#)深入Dependency$对象的恢复检查其中的内容:从结果中我们就可以看出,现在 DEPENDENCY$的 object id,data object id 和 ts#分别是 96, 30367,0,这里因为我们已经对 DEPENDENCY$执行了 move 操作,所以其 data object id 已经不等于 object id 了。I_DEPENDENCY1 的 object id,data object id
17、和 ts#分别是 127,127,0;I_DEPENDENCY2 的 object id,data object id 和 ts#分别是 128,128,0。现在我们已经知道了 I_DEPENDENCY1 和 I_DEPENDENCY2 的 object id,data object id和 ts#,接下来我们需要知道 I_DEPENDENCY1 和 I_DEPENDENCY2 所在的行在 ind$中的物理位置。我们还是先用 ODU 把 ind$中的全部都 unload 出来:接着我们去看一下 unload 出来的文本文件所对应的 sqlldr 的 control 文件:·5
18、3;P550_04_LA:oracle:/cadrasu01/app/oracle/product/9.2.0/odu/data#ls -lrt total 8528-rw-r-r-1 oracledba3999 Jun 02 14:59 SCOTT_TEST_DELETE.txt省略显示部分内容-rw-r-r-1 oracledba925 Aug 20 16:27 SYS_IND$.sql-rw-r-r-1 oracledba844 Aug 20 16:27 SYS_IND$.ctl-rw-r-r-1 oracledba130810 Aug 20 16:27 SYS_IND$.txtP550
19、_04_LA:oracle:/cadrasu01/app/oracle/product/9.2.0/odu/data#cat SYS_IND$.ctlODU> unload table sys.ind$Unloading table: IND$,object ID: 19Unloading segment,storage(Obj#=19 DataObj#=2 TS#=0 File#=1 Block#=25 Cluster=3) 1296 rows unloadedP550_04_LA:oracle:/cadrasu01/app/oracle/product/9.2.0/odu/data#
20、cat SYS_OBJ$.txt|grep DEPENDENCY 96|30367|0|DEPENDENCY$|1|2|2002-05-1302:16:33|2010-08-2011:43:07|2002-05-1302:16:33|1|0|0|1|0x0040007a|95127|127|0|I_DEPENDENCY1|4|1|2002-05-1302:16:34|2002-05-1302:16:34|2002-05-1302:16:34|1|0|0|65535|0x0040007b|18128|128|0|I_DEPENDENCY2|4|1|2002-05-1302:16:34|2002-
21、05-1302:16:34|2002-05-1302:16:34|1|0|0|65535|0x0040007b|19省略显示部分内容28739|1|SQLDEPENDENCYBLOCKSEQUENCESEQU|1|5|2002-05-1303:00:46|2002-05-1303:00:46|2002-05-1303:00:46|1|0|6|65535|0x0040755a|42-rw-r-r-1 oracledba725 Aug 20 16:03 SYS_OBJ$.ctl-rw-r-r-1 oracledba3860753 Aug 20 16:03 SYS_OBJ$.txtDBA 手记 2-
22、Generated by ODU,for table "SYS"."IND$"-OPTIONS(BINDSIZE=8388608,READSIZE=8388608,ERRORS=-1,ROWS=50000) LOAD DATAINFILE 'SYS_IND$.txt' "STR X'0a'" APPEND INTO TABLE "SYS"."IND$"FIELDS TERMINATED BY X'7c' TRAILING NULLCOLS (&qu
23、ot;BO#" ,"OBJ#" , "DATAOBJ#" , "TS#" ,"FILE#" ,"BLOCK#" , "INDMETHOD#" , "COLS" , "PCTFREE$" , "INITRANS" , "MAXTRANS" , "PCTTHRES$" , "TYPE#" ,"FLAGS" , "PROPE
24、RTY" , "BLEVEL" , "LEAFCNT" , "DISTKEY" , "LBLKKEY" , "DBLKKEY" , "CLUFAC" ,"ANALYZETIME" DATE "yyyy-mm-dd hh24:mi:ss", "SAMPLESIZE" ,"ROWCNT" , "INTCOLS" , "DEGREE" , "I
25、NSTANCES" , "TRUNCCNT" , "SPARE1" ,"SPARE2" ,·6·深入Dependency$对象的恢复注意到老熊这里为了 unload 数据的方便,他更改了 ind$所对应 control 文件中各个字段的顺序,他把 BO#放在了第一位。我们来看看 BO#的含义,从 sql.bsq 中我们可以清楚的看到 BO#实际上就是这个索引所在的基表的 object id,并且 ind$是一个 index cluster,其聚簇键就是 BO#。看到这里,朋友们应该已经明白了老熊为什么要把
26、 BO#放在 ind$对应 control 文件的第一位这是因为对于 index cluster 而言,其聚簇键就为这样他 unload 数据是最方便的。在 row directory 的最前面,老熊这么干就因如下是 sql.bsq 中 ind$的定义:·7·create table ind$/* index table */( obj#number not null,/* object number */* DO NOT CREATE INDEX ON DATAOBJ# AS IT WILL BE UPDATED IN A SPACE* TRANSACTION DURIN
27、G TRUNCATE */dataobj#number,/* data layer object number */ ts#number not null,/* tablespace number */ file# number not null,/* segment header file number */block# number not null,/* segment header block number */ bo#number not null, /* object number of base table */ indmethod# number not null, /* ob
28、ject # for cooperative index method */ cols number not null,/* number of columns */ pctfree$ number not null, /* minimum free space percentage in a block */ initrans number not null,/* initial number of transaction */ maxtrans number not null,/* um number of transaction */ pctthres$ number,/* iot ov
29、erflow threshold, null if not iot */ type# number not null,/* what kind of index is this? */* normal : 1 */* bitmap : 2 */* cluster : 3 */* iot - top : 4 */* iot - nested : 5 */* secondary : 6 */* ansi : 7 */* lob : 8 */"SPARE3" ,"SPARE4" CHAR(1000), "SPARE5" CHAR(1000)
30、,"SPARE6" DATE "yyyy-mm-dd hh24:mi:ss")DBA 手记 2I_DEPENDENCY1 和 I_DEPENDENCY2 的 base table 就是 DEPENDENCY$,而由前面的结果我们知道 DEPENDENCY$的 object id 是 96,即我们只需要去查 unload 出来的 ind$中全部记录所在的文本文件中那些 BO#=96 的, 查到了我们也就知道了 I_DEPENDENCY1 和I_DEPENDENCY2 所在的具体的物理位置:P550_04_LA:oracle#cat SYS_IND$.txt
31、|grep 9677|125|125|0|1|961|0|2|10|2|255|1|0|0|2|2|2002-05-13 02:16:34|0x0040001e|978|126|126|0|1|969|0|1|10|2|255|1|0|0|1|1|2002-05-13 02:16:34|0x0040001e|1096|127|127|0|1|977|0|3|10|2|255|1|0|1|3|3|2002-05-13 02:16:34|0x00400020|596|128|128|0|1|985|0|2|10|2|255|1|0|0|2|2|2002-05-13 02:16:34|0x00400
32、020|6194|196|196|0|1|1457|0|1|10|2|255|1|0|0|1|1|2002-05-13 02:16:36|0x00400024|5268|269|269|0|1|1969|0|3|10|2|255|1|0|0|3|3|2002-05-13 02:16:38|0x00400028|4从结果里我们可以知道,I_DEPENDENCY1 和 I_DEPENDENCY2 都在 0x00400020 中,即它们的物理·8·位置都在 datafile 1,block 32 中,并且它们对应的段头分别在 datafile 1,block/* cooperat
33、ive index method : 9 */flagsnumber not null,/* mutable flags: anything permanent should go into property */* unusable (dls) : 0x01 */* analyzed: 0x02 */* no logging: 0x04 */* index is currently being built : 0x08 */* index creation was incomplete : 0x10 */* key compression enabled : 0x20 */* user-sp
34、ecified stats : 0x40 */* secondary index on IOT : 0x80 */* index is being online built : 0x100 */* index is being online rebuilt : 0x200 */* index is disabled : 0x400 */* global stats : 0x800 */* fake index(internal) : 0x1000 */* index on UROWID column(s) : 0x2000 */* index with large key : 0x4000 *
35、/* move partitioned rows in base table : 0x8000 */* index usage monitoring enabled : 0x10000 */ propertynumber not null,/* immutable flags for life of the index */省略显示部分内容spare6date/* flashback timestamp */)cluster c_obj#(bo#)/深入Dependency$对象的恢复977 和 datafile 1,block 985。cdba 是 MOS 上一个标准的转换 RDBA 的过程
36、,其源码如下:·9·CREATE OR REPLACE PROCEDURE cdba ( iblock VARCHAR2, imode VARCHAR2 ) ASxNUMBER;digits# NUMBER; results NUMBER := 0; file#NUMBER := 0;block# NUMBER := 0; cur_digit CHAR(1); cur_digit# NUMBER;BEGINIF upper(imode) = 'H' THEN digits# := length( iblock );FOR x IN 1.digits# LOO
37、Pcur_digit := upper(substr( iblock, x, 1 );IF cur_digit IN ('A','B','C','D','E','F') THENcur_digit# := ascii( cur_digit ) - ascii('A') +10;ELSEcur_digit# := to_number(cur_digit); END IF;results := (results *16) + cur_digit#; END LOOP;ELSEIF upp
38、er(imode) = 'D' THEN-results := to_number(iblock,'XX'); results := iblock;ELSEdbms_output.put_line('H = Hex Input . D = Decimal Input'); RETURN;END IF;SQL> set serveroutput onSQL> exec sys.cdba('00400020','H');.The file is 1 The block is 32PL/SQL procedu
39、re successfully completedDBA 手记 2继续运算:即 96 就等价于 0x02c161即 127 就等价于 0x03c2021c即 128 就等价于 03c2021d即 0 就等价于 0x0180·10·SQL> select dump(0,16) from dual;DUMP(0,16)Typ=2 Len=1: 80SQL> select dump(128,16) from dual;DUMP(128,16)Typ=2 Len=3: c2,2,1dSQL> select dump(127,16) from dual;DUMP(1
40、27,16)Typ=2 Len=3: c2,2,1cSQL> select dump(96,16) from dual;DUMP(96,16)Typ=2 Len=2: c1,61END IF;file# := dbms_utility.data_block_address_file(results); block# := dbms_utility.data_block_address_block(results);dbms_output.put_line('.'); dbms_output.put_line( 'The file is ' | file#
41、);dbms_output.put_line( 'The block is ' | block# );END;/深入Dependency$对象的恢复由前面 sql.bsq 中关于 ind$的定义我们可以知道,ind$中非聚簇键的每一行的开头的三个字段依次是 object id,data object id 和 ts#,又根据上述 dump 结果我们可以知道,现在我们只需要去datafile 1,block 32 这个块中去字符串 03c2021c 03c2021c 0180 和 03c2021d 03c2021d0180 就可以知道 I_DEPENDENCY1 和 I_DEPE
42、NDENCY2 所在的行在 ind$中的具置了。好了,现在我们已经可以找到 I_DEPENDENCY1 和 I_DEPENDENCY2 所在的行在 ind$中的具置,但是接下来我们该如何修改呢?这就需要我们知道一点 index cluster internal 和 update internal 的知识。1.4 Index Cluster Internal我现在通过一个例子来跟大家讲述一些 index cluster internal 的知识点。首先创建一个名为 emp_dept 的 index聚簇键是 department_id:cluster,并在上面建表 departments 和 em
43、ployees,·11·Connected to Oracle9i Enterprise Edition Release 9.2.0.6.0 Connected as drasSQL> create cluster emp_dept(department_id number(4); Cluster createdSQL> create table departments2 (department_idnumber(4) primary key3 ,department_name varchar2(30)4 ,manager_idnumber(6)5 ,locat
44、ion_idnumber(4)6 CLUSTER emp_dept (department_id); Table createdSQL> create table employees2 (employee_id number(6) primary key3 ,last_namevarchar2(25)4 ,job_idvarchar2(15)5 ,department_id number(4) references departments)6 CLUSTER emp_dept (department_id);Table createdDBA 手记 2这里可以看到对于 index clus
45、ter 而言,如果不建索引,oracle 这里是不作的:你执行 insert 操在建完索引后,我们一些:此时我们有了如下示范数据:·12·SQL> select * from departments;DEPARTMENT_ID DEPARTMENT_NAMEMANAGER_ID LOCATION_ID10 Administration200170020 Marketing201180030 Purchasing114170040 Human Resources2032400SQL> select * from employees;EMPLOYEE_ID LAST
46、_NAMEJOB_IDDEPARTMENT_ID200 WhalenAD_ASST10201 HartsteinMK_MAN20SQL> create index emp_dept_index ON CLUSTER emp_dept; Index createdSQL> insert into departments values(10,'Administration',200,1700); SQL> insert into departments values(20,'Marketing',201,1800); SQL> insert
47、into departments values(30,'Purchasing',114,1700);SQL> insert into departments values(40,'Human Resources',203,2400); SQL> commit;SQL> insert into employees values(200,'Whalen','AD_ASST',10); SQL> insert into employees values(201,'Hartstein','M
48、K_MAN',20); SQL> insert into employees values(202,'Fay','MK_REP',20);SQL> insert into employees values(114,'Raphaely','PU_MAN',30);SQL> commit;SQL> insert into departments values(10,'Administration',200,1700); insert into departments values(10,
49、'Administration',200,1700)ORA-02032: clustered tables cannot be used before the cluster index is built深入Dependency$对象的恢复从下述测试结果我们可以看到,当我把 index cluster 上的索引 drop 掉后,oracle 这里连都不让我做了:·13·SQL> drop index emp_dept_index; Index droppedSQL> select * from employees; select * from e
50、mployeesORA-02032: clustered tables cannot be used before the cluster index is builtSQL> select * from departments; select * from departmentsORA-02032: clustered tables cannot be used before the cluster index is builtSQL> create index emp_dept_index ON CLUSTER emp_dept; Index createdSQL> se
51、lect * from employees;EMPLOYEE_ID LAST_NAMEJOB_IDDEPARTMENT_ID200 WhalenAD_ASST10201 HartsteinMK_MAN20202 FayMK_REP20114 RaphaelyPU_MAN30SQL> select * from departments;DEPARTMENT_ID DEPARTMENT_NAMEMANAGER_ID LOCATION_ID10 Administration200170020 Marketing2011800202 FayMK_REP20114 RaphaelyPU_MAN30
52、DBA 手记 2这里我们可以看到,对于 index cluster 而言,是不能单独的去 truncate index cluster 中的某个表的:这里我们可以看到,当 indexcluster 里面还有表的时候,你是不能 drop 整个 indexcluster的:从上述结果里我们可以看到聚簇键为 20 的·14·都在 datafile 116,block 44491 里。换算一下SQL> drop cluster emp_dept; drop cluster emp_deptORA-00951: cluster not emptySQL> alter sy
53、stem checkpoint; System alteredSQL> select t.*, dbms_rowid.rowid_relative_fno(rowid)|'_'|dbms_rowid.rowid_block_number(rowid)location from employees t;EMPLOYEE_ID LAST_NAMEJOB_IDDEPARTMENT_ID LOCATION200 WhalenAD_ASST10 116_44490201 HartsteinMK_MAN20 116_44491202 FayMK_REP20 116_44491114
54、RaphaelyPU_MAN30 116_44492 SQL> select t.*,dbms_rowid.rowid_relative_fno(rowid)|'_'|dbms_rowid.rowid_block_number(rowid)location from departments t;DEPARTMENT_ID DEPARTMENT_NAMEMANAGER_ID LOCATION_ID LOCATION10 Administration2001700 116_4449020 Marketing2011800 116_4449130 Purchasing11417
55、00 116_4449240 Human Resources2032400 116_44493SQL> truncate table employees; truncate table employeesORA-03292: Table to be truncated is part of a cluster30 Purchasing114170040 Human Resources2032400深入Dependency$对象的恢复相关数据的 16 进制格式,如下所示:·15·SQL> select dump(20,16) from dual; DUMP(20,
56、16)Typ=2 Len=2: c1,15SQL> select dump(201,16) from dual; DUMP(201,16)Typ=2 Len=3: c2,3,2SQL> select dump('Hartstein',16) from dual; DUMP('HARTSTEIN',16)Typ=96 Len=9: 48,61,72,74,73,74,65,69,6eSQL> select dump('MK_MAN',16) from dual; DUMP('MK_MAN',16)Typ=96 Le
57、n=6: 4d,4b,5f,4d,41,4eSQL> select dump(202,16) from dual; DUMP(202,16)Typ=2 Len=3: c2,3,3SQL> select dump('Fay',16) from dual; DUMP('FAY',16)Typ=96 Len=3: 46,61,79SQL> select dump('MK_REP',16) from dual; DUMP('MK_REP',16)Typ=96 Len=6: 4d,4b,5f,52,45,50SQL> select dump('Marketing',16) from dual; DUMP('MARKETING',16)DBA 手记 2我
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
最新文档
- 牛津深圳版初中英语单词表九年级下册
- 目标突破课件:3.4.1 同类项
- 河南省泌阳县2025年上半年公开招聘村务工作者试题含答案分析
- 2025年度健身中心场地租赁合同
- 2025版商铺租赁合同租赁期间合同解除条件承诺
- 2025版文化公司创意人员追诉期劳动合同示范
- 2025版租赁合同涵盖租赁物保险与风险承担
- 2025版养老院社会捐助服务合同
- 2025版银行信用卡分期付款合同规范模板下载
- 2025版三方大数据分析销售合作协议范本
- 蒋诗萌小品《谁杀死了周日》台词完整版
- 6G网络中的垂直通信和切片技术
- 入学安全第一课幼儿园
- 社区健康服务与管理教案
- 《社区康复》课件-第一章 总论
- 机械设备维护保养手册
- 人教版初中英语七至九年级单词汇总表(七年级至九年级全5册)
- 微积分的产生与发展
- 消防安全隐患排查投标方案(技术标)
- 22S803 圆形钢筋混凝土蓄水池
- 钢管顶管施工方案
评论
0/150
提交评论