查看: 41727|回复: 117

[精华] 起个题目:关于新建数据文件无备份的恢复(archivelog)

[复制链接]
论坛徽章:
86
ITPUB元老
日期:2005-02-28 12:57:002012新春纪念徽章
日期:2012-01-04 11:49:542012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20咸鸭蛋
日期:2012-05-08 10:27:19版主8段
日期:2012-05-15 15:24:112013年新春福章
日期:2013-02-25 14:51:24
发表于 2005-3-1 23:23 | 显示全部楼层 |阅读模式
这是一个假设的例子(给出的条件并不一定都须用上):



周二晚,有一个 联机拷贝os文件的脚本,依次执行下面伪代码

backup controlfile;


set feedback,head,echo,term... off
spool  filename;
select 'alter tablespace '||tablespace_name || 'begin backup;' from dba_tablespaces;

select 'cp ' ||name || '......' from v$datafile;

select 'alter tablespace '||tablespace_name || 'end backup;' from dba_tablespaces;

spool off

then  run the  script;


但是不幸,在备份过程中失败,只有部分文件备份成功,但是dba并不知道。

周三,dba新加了一个数据文件

周四,控制文件损坏,dba手工创建了控制文件

周五,磁盘损坏,恰好丢失了所有控制文件和新加的这个数据文件(该数据文件中有非常重要的期望恢复的数据)其他数据文件都。检查备份,结果发现原来的备份只有部分数据文件拷贝成功然后备份意外终止不再继续执行下面任何代码。 很不幸,备份出来的文件也在这个磁盘上坏了。



在这种情况下,请问,该数据文件是否能恢复,如能,请描述过程,如不能,请阐述理由。
论坛徽章:
92
2011新春纪念徽章
日期:2011-01-25 15:42:33咸鸭蛋
日期:2012-03-19 10:46:00版主1段
日期:2012-05-15 15:24:11奥运会纪念徽章:排球
日期:2012-08-29 07:02:50奥运会纪念徽章:跳水
日期:2012-09-26 06:44:27ITPUB 11周年纪念徽章
日期:2012-09-28 17:34:42ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:32奥运会纪念徽章:击剑
日期:2012-10-12 07:20:332013年新春福章
日期:2013-02-25 14:51:242012新春纪念徽章
日期:2012-02-13 15:13:20
发表于 2005-3-2 01:30 | 显示全部楼层
原来的备份只有部分数据文件  如果包括 system,rbs 可以尝试建立clone db; 然后alter database create datafile 再recover ; just guess

使用道具 举报

回复
论坛徽章:
16
2010数据库技术大会纪念徽章
日期:2010-05-13 10:04:27ITPUB技术丛书作者
日期:2010-09-26 15:24:562011新春纪念徽章
日期:2011-01-25 15:41:01管理团队成员
日期:2011-05-07 01:45:082012新春纪念徽章
日期:2012-02-13 15:11:18马自达
日期:2014-01-27 11:47:11
发表于 2005-3-2 01:48 | 显示全部楼层
呵呵,难得biti这么好兴致,偶也有兴趣试了试,可以恢复出来的。
首先排除biti的一些迷惑条件,基本上知道有一个控制文件的备份,没有任何数据文件的备份,增加的数据文件是在备份控制文件之后,其他的信息都没用。
我的测试过程如下,是把这个丢失的数据文件做为一个普通的数据文件来测试的,但是如果是system文件,恐怕就会复杂很多了,不多说了,看测试过程。

之前先备份了所有的控制文件
然后增加一个数据文件:
C:\Documents and Settings\coolyl>sqlplus "/as sysdba"
SQL*Plus: Release 9.2.0.6.0 - Production on 星期三 3月 2 01:15:58 2005
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
连接到:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
SQL> alter tablespace quest add datafile 'D:\ORACLE\ORADATA\ORCL\QUEST1.DBF' size 10M;
表空间已更改。

然后关闭数据库,删除所有控制文件,模拟周四的过程,虽然这步对于是否能恢复没什么意义,呵呵,还是按照biti说的做吧。重要的一点是这步做重建控制文件一定是noresetlogs的。
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area   97591104 bytes
Fixed Size                   454464 bytes
Variable Size              71303168 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
ORA-00205: ?????????????????????
SQL> shutdown immediate
ORA-01507: ??????
ORACLE 例程已经关闭。
SQL> startup nomount
ORACLE 例程已经启动。
Total System Global Area   97591104 bytes
Fixed Size                   454464 bytes
Variable Size              71303168 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
SQL> @d:\control.sql
CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS  ARCHIVELOG
    MAXLOGFILES 5
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 1
    MAXLOGHISTORY 453
LOGFILE
  GROUP 1 'D:\ORACLE\ORADATA\ORCL\REDO01.LOG'  SIZE 1M,
  GROUP 2 'D:\ORACLE\ORADATA\ORCL\REDO02.LOG'  SIZE 1M,
  GROUP 3 'D:\ORACLE\ORADATA\ORCL\REDO03.LOG'  SIZE 1M
DATAFILE
  'D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF',
  'D:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF',
  'D:\ORACLE\ORADATA\ORCL\QUEST.DBF',
  'D:\ORACLE\ORADATA\ORCL\QUEST1.DBF'
CHARACTER SET ZHS16GBK
;
RECOVER DATABASE
ALTER SYSTEM ARCHIVE LOG ALL;
ALTER DATABASE OPEN;
控制文件已创建
ORA-00283: ??????????
ORA-00264: ?????
系统已更改。
数据库已更改。
SQL> select open_mode from v$database;
OPEN_MODE
----------
READ WRITE
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF
D:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF
D:\ORACLE\ORADATA\ORCL\QUEST.DBF
D:\ORACLE\ORADATA\ORCL\QUEST1.DBF

使用道具 举报

回复
论坛徽章:
16
2010数据库技术大会纪念徽章
日期:2010-05-13 10:04:27ITPUB技术丛书作者
日期:2010-09-26 15:24:562011新春纪念徽章
日期:2011-01-25 15:41:01管理团队成员
日期:2011-05-07 01:45:082012新春纪念徽章
日期:2012-02-13 15:11:18马自达
日期:2014-01-27 11:47:11
发表于 2005-3-2 01:51 | 显示全部楼层
然后关闭数据库,删除所有控制文件和quest01.dbf文件,模拟周五的情况。
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area   97591104 bytes
Fixed Size                   454464 bytes
Variable Size              71303168 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
ORA-00205: ?????????????????????
SQL> shutdown immediate
ORA-01507: ??????
ORACLE 例程已经关闭。

拷贝最开始备份的所有控制文件回来,启动数据库到mount状态:
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area   97591104 bytes
Fixed Size                   454464 bytes
Variable Size              71303168 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
ORA-01991: ???????'D:\oracle\ora92\DATABASE\PWDorcl.ORA'
SQL> shutdown immediate
ORA-01109: ??????
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\coolyl>del D:\oracle\ora92\DATABASE\PWDorcl.ORA
C:\Documents and Settings\coolyl>orapwd file=D:\oracle\ora92\DATABASE\PWDorcl.ORA password=oracle entries=10
C:\Documents and Settings\coolyl>exit
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area   97591104 bytes
Fixed Size                   454464 bytes
Variable Size              71303168 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。

使用道具 举报

回复
论坛徽章:
16
2010数据库技术大会纪念徽章
日期:2010-05-13 10:04:27ITPUB技术丛书作者
日期:2010-09-26 15:24:562011新春纪念徽章
日期:2011-01-25 15:41:01管理团队成员
日期:2011-05-07 01:45:082012新春纪念徽章
日期:2012-02-13 15:11:18马自达
日期:2014-01-27 11:47:11
发表于 2005-3-2 01:59 | 显示全部楼层
此时如果做alter database create datafile as这个命令肯定是不行的,因为此时的控制文件还没有quest01.dbf这个文件的信息:
SQL> alter database create datafile 'D:\ORACLE\ORADATA\ORCL\QUEST1.DBF' as 'D:\O
RACLE\ORADATA\ORCL\QUEST1.DBF' reuse;
alter database create datafile 'D:\ORACLE\ORADATA\ORCL\QUEST1.DBF' as 'D:\ORACLE
\ORADATA\ORCL\QUEST1.DBF' reuse
*
ERROR 位于第 1 行:
ORA-01516: 不存在的日志文件, 数据文件或临时文件
'D:\ORACLE\ORADATA\ORCL\QUEST1.DBF'


必须先使用旧的控制文件进行不完全恢复到控制文件中包含了quest01.dbf文件先:
SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 1229498 (在 03/02/2005 01:13:44 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:\ORACLE\ORA92\RDBMS\ARC00516.001
ORA-00280: 更改 1229498 对于线程 1 是按序列 # 516 进行的
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00283: 恢复会话因错误而取消
ORA-01244: 未命名的数据文件由介质恢复添加至控制文件
ORA-01110: 数据文件 4: 'D:\ORACLE\ORADATA\ORCL\QUEST1.DBF'
ORA-01112: 未启动介质恢复

SQL> recover database using backup controlfile until cancel;
ORA-00283: 恢复会话因错误而取消
ORA-01111: 数据文件 4 名称未知 - 请重命名以更正文件
ORA-01110: 数据文件 4: 'D:\ORACLE\ORA92\DATABASE\UNNAMED00004'
ORA-01157: 无法标识/锁定数据文件 4 - 请参阅 DBWR 跟踪文件
ORA-01111: 数据文件 4 名称未知 - 请重命名以更正文件
ORA-01110: 数据文件 4: 'D:\ORACLE\ORA92\DATABASE\UNNAMED00004'

我们看到此时控制文件中已经包含了这个数据文件的信息,但是因为被删除后恢复出来的,所以oracle不知道这个文件的具体名字,给了个奇怪的名字,没关系,我们重新命名一下这个文件:
SQL> alter database create datafile 'D:\ORACLE\ORA92\DATABASE\UNNAMED00004' as '
D:\ORACLE\ORADATA\ORCL\QUEST1.DBF' reuse;
数据库已更改。

这样数据库就存在了quest1.dbf这个文件的信息了,然后我们继续做不完全恢复:
SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 1229668 (在 03/02/2005 01:16:11 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:\ORACLE\ORA92\RDBMS\ARC00516.001
ORA-00280: 更改 1229668 对于线程 1 是按序列 # 516 进行的
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: 更改 1229717 (在 03/02/2005 01:18:36 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:\ORACLE\ORA92\RDBMS\ARC00517.001
ORA-00280: 更改 1229717 对于线程 1 是按序列 # 517 进行的
ORA-00278: 此恢复不再需要日志文件 'D:\ORACLE\ORA92\RDBMS\ARC00516.001'
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: 无法打开存档日志 'D:\ORACLE\ORA92\RDBMS\ARC00517.001'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) The system cannot find the file specified.
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01152: 文件 1 没有从完备的旧备份中恢复
ORA-01110: 数据文件 1: 'D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF'

上面恢复失败,看来'D:\ORACLE\ORA92\RDBMS\ARC00517.001'
还没存在,没关系,当前的所有redolog都在,用这个就行了,重新恢复一次:
SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 1229717 (在 03/02/2005 01:18:36 生成) 对于线程 1 是必需的
ORA-00289: 建议: D:\ORACLE\ORA92\RDBMS\ARC00517.001
ORA-00280: 更改 1229717 对于线程 1 是按序列 # 517 进行的
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
D:\oracle\oradata\orcl\redo01.log
已应用的日志。
完成介质恢复。
SQL> alter database open resetlogs;
数据库已更改。
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------

D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF
D:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF
D:\ORACLE\ORADATA\ORCL\QUEST.DBF
D:\ORACLE\ORADATA\ORCL\QUEST1.DBF

至此,丢失的那个重要的数据文件恢复完毕。

使用道具 举报

回复
论坛徽章:
16
2010数据库技术大会纪念徽章
日期:2010-05-13 10:04:27ITPUB技术丛书作者
日期:2010-09-26 15:24:562011新春纪念徽章
日期:2011-01-25 15:41:01管理团队成员
日期:2011-05-07 01:45:082012新春纪念徽章
日期:2012-02-13 15:11:18马自达
日期:2014-01-27 11:47:11
发表于 2005-3-2 02:09 | 显示全部楼层
总结一下整个的恢复过程:
biti给了很多迷惑的信息,让人觉得看似没法恢复似的。但是了解了备份恢复的机制,就很少排除这些迷惑信息了,因为没有备份,要恢复这个数据文件,首先保证在控制文件中有这个新增加的数据文件的信息,加上所有的归档日志在就可以了,biti给出的条件满足恢复的前提,因此理论上就应该是可以恢复的。
因为开始备份的控制文件无这个新增加的数据文件的信息,因此恢复就得分为两步了,先恢复到控制文件中存在了这个新增的数据文件的时候,因为是利用归档恢复出来的,控制文件中关于这个数据文件的信息不一定准确,需要我们去手工来重命名为正确的数据文件,然后剩下的恢复就跟普通的恢复一样了。

欢迎biti指正和补充,^_^。

BTW:困了,睡觉去了,biti你害我这么晚还没睡,去杭州就看我怎么宰你吧,嘿嘿

使用道具 举报

回复
论坛徽章:
112
2008新春纪念徽章
日期:2008-02-13 12:43:03马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14马上有车
日期:2014-11-03 12:40:39沸羊羊
日期:2015-03-04 14:43:432015年新春福章
日期:2015-03-06 11:57:31慢羊羊
日期:2015-03-09 16:15:39
发表于 2005-3-2 09:01 | 显示全部楼层
强!超强!几位大师你们真是太牛了!

这个问题是所有搞Oracle的都面临的棘手的问题.在你们看来象玩游戏一样那么轻松就搞定了. 实在让人佩服啊!!

另外,各位大虾对Oracle的热爱和对学术的严谨精神值得我们学习!!


再次感谢各位给我们这些使用Oracle处于迷茫期的后生们以启迪!


使用道具 举报

回复
论坛徽章:
3
授权会员
日期:2005-11-10 08:36:21ITPUB元老
日期:2005-11-10 08:36:01会员2006贡献徽章
日期:2006-04-17 13:46:34
发表于 2005-3-2 09:27 | 显示全部楼层
最初由 Kamus 发布
[B]如果我们作得是backup controlfile to trace,我们甚至可以做到不resetlogs就recover数据库

[php]
d:\\Temp>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.5.0 - Production on Wed Mar 2 04:28:33 2005

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to an idle instance.

SQL> startup nomount
ORACLE instance started.

Total System Global Area  177282760 bytes
Fixed Size                   454344 bytes
Variable Size             150994944 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS  ARCHIVELOG
  2  --  SET STANDBY TO MAXIMIZE PERFORMANCE
  3      MAXLOGFILES 5
  4      MAXLOGMEMBERS 3
  5      MAXDATAFILES 100
  6      MAXINSTANCES 1
  7      MAXLOGHISTORY 226
  8  LOGFILE
  9    GROUP 1 'C:\\ORACLE\\ORADATA\\ORCL\\REDO01.LOG'  SIZE 10M,
10    GROUP 2 'C:\\ORACLE\\ORADATA\\ORCL\\REDO02.LOG'  SIZE 10M,
11    GROUP 3 'C:\\ORACLE\\ORADATA\\ORCL\\REDO03.LOG'  SIZE 10M
12  -- STANDBY LOGFILE
13  DATAFILE
14    'C:\\ORACLE\\ORADATA\\ORCL\\SYSTEM01.DBF',
15    'C:\\ORACLE\\ORADATA\\ORCL\\UNDOTBS01.DBF',
16    'C:\\ORACLE\\ORADATA\\ORCL\\INDX01.DBF',
17    'C:\\ORACLE\\ORADATA\\ORCL\\TOOLS01.DBF',
18    'C:\\ORACLE\\ORADATA\\ORCL\\USERS01.DBF',
19    'C:\\ORACLE\\ORADATA\\ORCL\\O1_MF_TS_TEST_0ZZF1Z2Y_.DBF',
20    'C:\\ORACLE\\ORADATA\\ORCL\\O1_MF_TS_TEST_0ZZFKG5T_.DBF',
21    'C:\\ORACLE\\ORADATA\\ORCL\\O1_MF_LOGMNRTS_11MH1CJ9_.DBF'
22  CHARACTER SET ZHS16GBK
23  ;

Control file created.

SQL> recover database until time '2005-3-2 04:28:05';
ORA-00283: recovery session canceled due to errors
ORA-01244: unnamed datafile(s) added to controlfile by media recovery
ORA-01110: data file 8: 'C:\\ORACLE\\ORADATA\\ORCL\\TS_FUN01.DBF'


SQL> alter database create datafile 8 as 'C:\\ORACLE\\ORADATA\\ORCL\\TS_FUN01.DBF';

Database altered.

SQL>
SQL> recover database;
Media recovery complete.
SQL> alter database open;

Database altered.

SQL>
[/php] [/B]


Kamus的意思是不是在做恢复时,在备份的Trace里直接加入'C:\\ORACLE\\ORADATA\\ORCL\\TS_FUN01.DBF'的语句,使得新生成的控制文件包含有TS_FUN01.DBF'的信息。这就省去了Coolyl在一开始所做的恢复

使用道具 举报

回复
论坛徽章:
86
ITPUB元老
日期:2005-02-28 12:57:002012新春纪念徽章
日期:2012-01-04 11:49:542012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20咸鸭蛋
日期:2012-05-08 10:27:19版主8段
日期:2012-05-15 15:24:112013年新春福章
日期:2013-02-25 14:51:24
 楼主| 发表于 2005-3-2 09:36 | 显示全部楼层
呵呵,再继续进一步,假如周二没有备份控制文件呢?

其实这里包含了几个信息:
1:归档都在
2:所有备份都没有
3:新创建的数据文件没了
4:由于备份没有正常结束,则所有文件头scn还是冻结状态的,此处可以衍生为逐个表空间 begin  backup  and  end  backup ,也就是说各数据文件状态可能不一致,由此也可能会引出恢复时间点的提前

所以目的要有2个:
1:找到创建文件的时间点
2:要使得备份可能从文件创建之前进行恢复







当然,kamus 说的控制文件已经resetlogs之后,在10g前的版本,我们需要获得这个resetlogs的时间点,假定dba根本忘记了到什么状态resetlogs的。 呵呵,在数据文件头的信息中,有一个 resetlogs scn  and  time 的记录,我们是可以dump出来的,即使所有控制文件丢失,我们create  controlfile 之后也能从数据文件头读出这个信息到控制文件中然后  dump 出来,而得到  resetlogs  scn and  time 。我没有注意过 alert log 之中是否有时间点记录,呵呵,如果有也是一个办法。




当然,以上内容,本人未亲自做过实验,都是引导别人做过,自己完全是从 备份与恢复原理 以及对 db 的结构的理解来判断的。

使用道具 举报

回复
论坛徽章:
16
2010数据库技术大会纪念徽章
日期:2010-05-13 10:04:27ITPUB技术丛书作者
日期:2010-09-26 15:24:562011新春纪念徽章
日期:2011-01-25 15:41:01管理团队成员
日期:2011-05-07 01:45:082012新春纪念徽章
日期:2012-02-13 15:11:18马自达
日期:2014-01-27 11:47:11
发表于 2005-3-2 09:47 | 显示全部楼层
如果open resetlogs,alert文件中是肯定应该有记录的。
Wed Mar 02 01:27:05 2005
alter database open resetlogs
Wed Mar 02 01:27:05 2005
RESETLOGS after complete recovery through change 1229883
Resetting resetlogs activation ID 1076941119 (0x4030d13f)

这个是我昨天resetlogs的记录。

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会,7折限时优惠重磅来袭!
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。

限时七折期:2019年8月31日前


----------------------------------------

大会官网>>
TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表