首页 > 数据库 >oracle如何恢复被误误删除的pdb

oracle如何恢复被误误删除的pdb

时间：2023-04-06 11:33:59浏览次数：38  
标签：误删除 kfracdb2 12 bcd 被误 KFFIX lge EXT oracle


最近太忙，一直没时间写blog；加上前段时间blog空间除了点问题，因此整体迁移到阿里云并且重新备案了。后续有时间我会定期更新，保持写作习惯，不能把技术荒废了。

这是去年底某客户的一个case，误删除了6个pdb且带了including datafiles参数；这是一个非常复杂的恢复；据说用户开始找了国内很多恢复专家都没恢复成功；最终经过几天的努力，我们最终恢复了全部数据；针对这样的case；据我了解目前国内只有我们可以做这个恢复。

针对此Case我们最开始预想了几种方案：

1) 使用Oracle AMDU

通常当ASM磁盘组无法mount的时候常常会想到使用AMDU去抽取数据文件，那么此次故障是否可以使用amdu呢？，这显然是不能的。

   amdu抽取asm文件的原理是通过asm文件号找到该文件对应的FILEDIR(asm 1号文件)的kfffde[0-59]找到file extent信息，如果extent个数大于60还需要借助kfffde[60+]指向的INDIRECT的kffixe来获取asm file每个extent所在的disk#，au#，从而完成抽取的。如果asm 1号文件FILEDIR损坏或者清空的情况下，amdu是无法完成文件抽取的。而drop datafile操作正好会清理掉FILEDIR的kfffde[0-59]和kfffde[60+]指向的INDIRECT的kffixe。

 

2）使用老熊的ODU软件

odu在asm 1号文件FILEDIR损坏或者清空的情况下，通过配置asmdisk.txt，可以扫描该配置文件中所有的磁盘，会产生很多.odu文件，其中一个非常重要的文件是asm_fileext_meta.odu该文件以最小au也就是1M为1行记录，记录磁盘每个au所在的asmdisk#，au#，au_block#，第一个块的rdba、rfile#和block#，数据块大小等信息，相当于通过扫描磁盘建立数据文件的fileext，唯一不同的是FILEDIR记录的是asm文件号，这里记录的是相对文件号，随后即可通过extract命令根据rfile#来按照rdba的是顺序来抽取数据文件。但是此案例是删除了多个pdb，单纯的使用odu也无法实现；原因是pdb之间会存在相同rdba的情况，也就是说rfile#是一样的。在rdba相同的情况下此时odu根本不知道数据块是属于哪个pdb哪个数据文件的(除了数据文件头所在的第一个au，因为有且只有数据文件头中存在绝对文件号），从而就无法做出正确的抽取。

换句话讲；要找到其中的关系，就是本次恢复的关键所在。

那么如何寻找呢？这里我们需要通过去分析ACD（Active Change Directory）和COD（Continuing Operation Directory）元数据信息；寻找其中关键信息。

 

indirect：kfracdb2.lge[0].bcd[0].kfbl.blk:    323 ; 0x020: blk=323
kfracdb2.lge[0].bcd[0].kfbl.obj:      1 ; 0x024: file=1
kfracdb2.lge[0].bcd[0].kfcn.base:4325033 ; 0x028: 0x0041fea9
kfracdb2.lge[0].bcd[0].kfcn.wrap:     0 ; 0x02c: 0x00000000
kfracdb2.lge[0].bcd[0].oplen:        12 ; 0x030: 0x000c
kfracdb2.lge[0].bcd[0].blkIndex:    323 ; 0x032: 0x0143
kfracdb2.lge[0].bcd[0].flags:        28 ; 0x034: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[0].bcd[0].opcode:      133 ; 0x036: 0x0085
kfracdb2.lge[0].bcd[0].kfbtyp:        4 ; 0x038: KFBTYP_FILEDIR
kfracdb2.lge[0].bcd[0].redund:       17 ; 0x039: SCHE=0x1 NUMB=0x1
kfracdb2.lge[0].bcd[0].pad:       63903 ; 0x03a: 0xf99f
kfracdb2.lge[0].bcd[0].KFFFD_EXT.xtntcnt:7263 ; 0x03c: 0x00001c5f
kfracdb2.lge[0].bcd[0].KFFFD_EXT.xtntblk:61 ; 0x040: 0x003d
kfracdb2.lge[0].bcd[0].KFFFD_EXT.xnum:0 ; 0x042: 0x0000
kfracdb2.lge[0].bcd[0].KFFFD_EXT.xcnt:0 ; 0x044: 0x0000
kfracdb2.lge[0].bcd[0].KFFFD_EXT.setflg:0 ; 0x046: 0x00
kfracdb2.lge[0].bcd[0].KFFFD_EXT.flags:0 ; 0x047: O=0 S=0 S=0 D=0 C=0 I=0 R=0 A=0
kfracdb2.lge[0].bcd[0].au[0]:        10 ; 0x048: 0x0000000a
kfracdb2.lge[0].bcd[0].disks[0]:      0 ; 0x04c: 0x0000
kfracdb2.lge[0].bcd[1].kfbl.blk:2147483663 ; 0x050: blk=15 (indirect)
kfracdb2.lge[0].bcd[1].kfbl.obj:    323 ; 0x054: file=323
kfracdb2.lge[0].bcd[1].kfcn.base:4325033 ; 0x058: 0x0041fea9
kfracdb2.lge[0].bcd[1].kfcn.wrap:     0 ; 0x05c: 0x00000000
kfracdb2.lge[0].bcd[1].oplen:        16 ; 0x060: 0x0010
kfracdb2.lge[0].bcd[1].blkIndex:     15 ; 0x062: 0x000f
kfracdb2.lge[0].bcd[1].flags:        28 ; 0x064: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[0].bcd[1].opcode:      161 ; 0x066: 0x00a1
kfracdb2.lge[0].bcd[1].kfbtyp:       12 ; 0x068: KFBTYP_INDIRECT
kfracdb2.lge[0].bcd[1].redund:       17 ; 0x069: SCHE=0x1 NUMB=0x1
kfracdb2.lge[0].bcd[1].pad:       63903 ; 0x06a: 0xf99f
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xtntblk:3 ; 0x06c: 0x0003
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xnum:3 ; 0x06e: 0x0003
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xcnt:1 ; 0x070: 0x0001
kfracdb2.lge[0].bcd[1].KFFIX_EXT.ub2spare:0 ; 0x072: 0x0000
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xptr[0].au:4294967295 ; 0x074: 0xffffffff
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xptr[0].disk:65535 ; 0x078: 0xffff
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xptr[0].flags:0 ; 0x07a: L=0 E=0 D=0 S=0
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xptr[0].chk:42 ; 0x07b: 0x2a
kfracdb2.lge[0].bcd[1].au[0]:     28230 ; 0x07c: 0x00006e46
kfracdb2.lge[0].bcd[1].disks[0]:      7 ; 0x080: 0x0007

 

LGE为ACD redo log record，BCD为ACD block change descriptor。改动向量0和1组成的重做记录0，这点和redo基本一样。

以上描述了asm file 323的FILEDIR kfffde[60](kfffde从0开始计算)所指向的INDIRECT(disk#为28230 au#为7)的kffixe[3]被清空。

即asm file号为323的extent号为7263的file extent map被清理。

备注：：对于indirect，extent#=KFFIX_EXT.xnum+60+indirect block#*480=3+60+15*480=7263，一个indirect block包含480个extent信息

 

direct：kfracdb2.lge[12].valid:               1 ; 0x3c4: V=1 B=0 M=0
kfracdb2.lge[12].chgCount:            1 ; 0x3c5: 0x01
kfracdb2.lge[12].len:                68 ; 0x3c6: 0x0044
kfracdb2.lge[12].kfcn.base:     4363270 ; 0x3c8: 0x00429406
kfracdb2.lge[12].kfcn.wrap:           0 ; 0x3cc: 0x00000000
kfracdb2.lge[12].bcd[0].kfbl.blk:   321 ; 0x3d0: blk=321
kfracdb2.lge[12].bcd[0].kfbl.obj:     1 ; 0x3d4: file=1
kfracdb2.lge[12].bcd[0].kfcn.base:4363269 ; 0x3d8: 0x00429405
kfracdb2.lge[12].bcd[0].kfcn.wrap:    0 ; 0x3dc: 0x00000000
kfracdb2.lge[12].bcd[0].oplen:       20 ; 0x3e0: 0x0014
kfracdb2.lge[12].bcd[0].blkIndex:   321 ; 0x3e2: 0x0141
kfracdb2.lge[12].bcd[0].flags:       28 ; 0x3e4: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[12].bcd[0].opcode:     133 ; 0x3e6: 0x0085
kfracdb2.lge[12].bcd[0].kfbtyp:       4 ; 0x3e8: KFBTYP_FILEDIR
kfracdb2.lge[12].bcd[0].redund:      17 ; 0x3e9: SCHE=0x1 NUMB=0x1
kfracdb2.lge[12].bcd[0].pad:      63903 ; 0x3ea: 0xf99f
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xtntcnt:48 ; 0x3ec: 0x00000030
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xtntblk:48 ; 0x3f0: 0x0030
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xnum:48 ; 0x3f2: 0x0030
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xcnt:1 ; 0x3f4: 0x0001
kfracdb2.lge[12].bcd[0].KFFFD_EXT.setflg:0 ; 0x3f6: 0x00
kfracdb2.lge[12].bcd[0].KFFFD_EXT.flags:0 ; 0x3f7: O=0 S=0 S=0 D=0 C=0 I=0 R=0 A=0
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xptr[0].au:4294967295 ; 0x3f8: 0xffffffff
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xptr[0].disk:65535 ; 0x3fc: 0xffff
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xptr[0].flags:0 ; 0x3fe: L=0 E=0 D=0 S=0
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xptr[0].chk:42 ; 0x3ff: 0x2a
kfracdb2.lge[12].bcd[0].au[0]:       10 ; 0x400: 0x0000000a
kfracdb2.lge[12].bcd[0].disks[0]:     0 ; 0x404: 0x0000

 

以上描述了asm file 321的FILEDIR的kfffde[48] extent信息被清空。

即asm文件号为321的extent号为48的file extent map被清理。

备注：对于direct extent#=KFFFD_EXT.xnum=48。

但是始终没有看到drop之前的file extent map记录。由于drop datafile已经完成，所以COD也清空了更改之前的信息。 那么如何找到之前的记录呢？这将是本次恢复的核心技术点所在。

 

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            8 ; 0x002: KFBTYP_CHNGDIR
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                    1777 ; 0x004: blk=1777
kfbh.block.obj:                       3 ; 0x008: file=3
kfbh.check:                   918117267 ; 0x00c: 0x36b95b93
kfbh.fcn.base:                  4365702 ; 0x010: 0x00429d86
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfracdb2.aba.seq:                    18 ; 0x000: 0x00000012
kfracdb2.aba.blk:                  1776 ; 0x004: 0x000006f0
kfracdb2.ents:                       23 ; 0x008: 0x0017
kfracdb2.ub2spare:                    0 ; 0x00a: 0x0000
kfracdb2.instNum:                     1 ; 0x00c: 0x00000001
kfracdb2.timestamp:          1004905358 ; 0x010: 2019-4-6 20:22:38
kfracdb2.lge[0].valid:                1 ; 0x014: V=1 B=0 M=0
kfracdb2.lge[0].chgCount:             3 ; 0x015: 0x03
kfracdb2.lge[0].len:                172 ; 0x016: 0x00ac
kfracdb2.lge[0].kfcn.base:      4365703 ; 0x018: 0x00429d87
kfracdb2.lge[0].kfcn.wrap:            0 ; 0x01c: 0x00000000
kfracdb2.lge[0].bcd[0].kfbl.blk:     58 ; 0x020: blk=58
kfracdb2.lge[0].bcd[0].kfbl.obj:2147483656 ; 0x024: disk=8
kfracdb2.lge[0].bcd[0].kfcn.base:4365702 ; 0x028: 0x00429d86
kfracdb2.lge[0].bcd[0].kfcn.wrap:     0 ; 0x02c: 0x00000000
kfracdb2.lge[0].bcd[0].oplen:        24 ; 0x030: 0x0018
kfracdb2.lge[0].bcd[0].blkIndex:     58 ; 0x032: 0x003a
kfracdb2.lge[0].bcd[0].flags:        28 ; 0x034: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[0].bcd[0].opcode:       66 ; 0x036: 0x0042
kfracdb2.lge[0].bcd[0].kfbtyp:        3 ; 0x038: KFBTYP_ALLOCTBL
kfracdb2.lge[0].bcd[0].redund:       18 ; 0x039: SCHE=0x1 NUMB=0x2
kfracdb2.lge[0].bcd[0].pad:       63903 ; 0x03a: 0xf99f
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.curidx:2888 ; 0x03c: 0x0b48
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.nxtidx:8 ; 0x03e: 0x0008
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.prvidx:8 ; 0x040: 0x0008
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.asz:0 ; 0x042: KFDASZ_1X
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.frag:0 ; 0x043: 0x00
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.total:0 ; 0x044: 0x0000
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.free:0 ; 0x046: 0x0000
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.fnum:4294967295 ; 0x048: 0xffffffff
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.xnum:4294967295 ; 0x04c: 0xffffffff
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.flags:0 ; 0x050: 0x00000000
kfracdb2.lge[0].bcd[0].au[0]:         0 ; 0x054: 0x00000000
kfracdb2.lge[0].bcd[0].au[1]:        11 ; 0x058: 0x0000000b
kfracdb2.lge[0].bcd[0].disks[0]:      8 ; 0x05c: 0x0008
kfracdb2.lge[0].bcd[0].disks[1]:      8 ; 0x05e: 0x0008
kfracdb2.lge[0].bcd[1].kfbl.blk:2147483659 ; 0x060: blk=11 (indirect)
kfracdb2.lge[0].bcd[1].kfbl.obj:    320 ; 0x064: file=320
kfracdb2.lge[0].bcd[1].kfcn.base:4365702 ; 0x068: 0x00429d86
kfracdb2.lge[0].bcd[1].kfcn.wrap:     0 ; 0x06c: 0x00000000
kfracdb2.lge[0].bcd[1].oplen:        16 ; 0x070: 0x0010
kfracdb2.lge[0].bcd[1].blkIndex:     11 ; 0x072: 0x000b
kfracdb2.lge[0].bcd[1].flags:        28 ; 0x074: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[0].bcd[1].opcode:      163 ; 0x076: 0x00a3
kfracdb2.lge[0].bcd[1].kfbtyp:       12 ; 0x078: KFBTYP_INDIRECT
kfracdb2.lge[0].bcd[1].redund:       17 ; 0x079: SCHE=0x1 NUMB=0x1
kfracdb2.lge[0].bcd[1].pad:       63903 ; 0x07a: 0xf99f
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xtntblk:0 ; 0x07c: 0x0000
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xnum:313 ; 0x07e: 0x0139
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xcnt:1 ; 0x080: 0x0001
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.ub2spare:0 ; 0x082: 0x0000
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xptr[0].au:4294967292 ; 0x084: 0xfffffffc
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xptr[0].disk:8 ; 0x088: 0x0008
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xptr[0].flags:0 ; 0x08a: L=0 E=0 D=0 S=0
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xptr[0].chk:33 ; 0x08b: 0x21
kfracdb2.lge[0].bcd[1].au[0]:      8360 ; 0x08c: 0x000020a8
kfracdb2.lge[0].bcd[1].disks[0]:      0 ; 0x090: 0x0000
kfracdb2.lge[0].bcd[2].kfbl.blk:      2 ; 0x094: blk=2
kfracdb2.lge[0].bcd[2].kfbl.obj:      4 ; 0x098: file=4
kfracdb2.lge[0].bcd[2].kfcn.base:4365702 ; 0x09c: 0x00429d86
kfracdb2.lge[0].bcd[2].kfcn.wrap:     0 ; 0x0a0: 0x00000000
kfracdb2.lge[0].bcd[2].oplen:         8 ; 0x0a4: 0x0008
kfracdb2.lge[0].bcd[2].blkIndex:      2 ; 0x0a6: 0x0002
kfracdb2.lge[0].bcd[2].flags:        28 ; 0x0a8: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[0].bcd[2].opcode:      211 ; 0x0aa: 0x00d3
kfracdb2.lge[0].bcd[2].kfbtyp:       16 ; 0x0ac: KFBTYP_COD_DATA
kfracdb2.lge[0].bcd[2].redund:       17 ; 0x0ad: SCHE=0x1 NUMB=0x1
kfracdb2.lge[0].bcd[2].pad:       63903 ; 0x0ae: 0xf99f
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.offset:60 ; 0x0b0: 0x003c
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.length:4 ; 0x0b2: 0x0004
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.data[0]:45 ; 0x0b4: 0x2d
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.data[1]:0 ; 0x0b5: 0x00
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.data[2]:0 ; 0x0b6: 0x00
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.data[3]:128 ; 0x0b7: 0x80
kfracdb2.lge[0].bcd[2].au[0]:         6 ; 0x0b8: 0x00000006
kfracdb2.lge[0].bcd[2].disks[0]:      1 ; 0x0bc: 0x0001

最终答案是什么呢？由此通过amdu抽取出asm 3号文件ACD，遍历ACD元数据块筛选出drop pdb的时间戳AT条目的所有变更记录，则可以完全的恢复被drop掉的asm file的extent map。然后重新构造asm_fileext_meta.odu文件并结合odu最终完美的恢复了被误删除的6个pdb。

 

不得不都说ODU非常的强大。这种方法我们验证可以恢复12c以及以后版本。

标签：误删除,kfracdb2,12,bcd,被误,KFFIX,lge,EXT,oracle
From： https://blog.51cto.com/databasenotes/6172474

相关文章

  • oracle之检查点（Checkpoint）
    转载于：oracle之检查点（Checkpoint）-张冲andy-博客园(cnblogs.com)检查点是一个数据库事件，它把修改数据从高速缓存写入磁盘，并更新控制文件和数据文件。检查点分为三类：1）局部检查点：单个实例执行数据库所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。触发......
  • 《oracle马拉松》plsql篇
    安装和配置安装plsql的安装比较简单，根据系统，安装64位或32位的plsql，一路next即可。配置（Instantclient）0、安装前注意。instantclient和plsql的版本要对应，64位plsql对应64位的instantclient。否则，报错Initializationerror不能初始化oci.dl。1.下载，解压InstantClient压......
  • oracle data guard集群之参数文件详解
    #############  1.log_archive_config该参数必须显式声明主备库的db_unique_name，且主库的db_unique_name永远放在第一位。其他备库的跟随其后。该参数适用于：主库、物理备库、逻辑备库、快照备库。log_archive_config='dg_config(db_unique_name,db_unique_name,.........
  • Win10 安装Oracle21c 教程
    Win10安装Oracle21c教程1：(官方)下载地址https://www.oracle.com/database/technologies/oracle21c-windows-downloads.htmlOracleDatabase21c (21.3)OracleDatabase21c (21.3)forMicrosoftWindowsx64(64-bit)DownloadDescriptionWINDOWS.X64_2130......
  • oracle 中Version counts高原因分析
    (18条消息)Oracle高Versioncounts问题说明_Dave的博客-CSDN博客主要查看视图v$sqlareav$sql_shared_cursor ......
  • Linux静默安装Oracle21C
    Linux静默安装Oracle21C1、修改主机名及配置hosts[root@localhost~]#hostname #查看主机名[root@localhost~]#hostnameoracledb #修改主机名[root@localhost~]#vim/etc/hosts #修改hosts[root@localhost~]#cat/etc/hosts2、关闭selinux和防火墙[root@l......
  • Linux centos7虚拟机安装Oracle11g完全教程
                      Linuxcentos7虚拟机安装Oracle11g完全教程Linux下安装Oracle相比windows安装Oracle要显得繁琐很多，繁琐在前期准备工作很多，Oracle有两次安装前的检查，前期的准备工作其实也就是围绕这两次检查来做的。第一次检查：Oracle安装程......
  • 《oracle马拉松》基础语法篇-字段类型
    常见字段类型原文链接：https://www.cnblogs.com/zhouweiye/p/3594268.html1.字符型CHAR型：定长字符串，短则用空格填充，长则出错。VARCHAR2型：变长字符串。字段长度根据实际字符串长度自动调整，不用空格填充。2.数值型NUMBER(PRECISION,SCALE)精度PRECISION指定所有数字位的个数，范......
  • Oracle JDK7 bug 发现、分析与解决实战
    作者：vivo官网商城开发团队众所周知，OracleJDK 是Java语言的绝对权威，很多时候JDK与Java语言近似一个概念。但我们始终要保持实事求是的精神，敢于质疑。本文记录了一次线上troubleshoot实战，包含问题分析、解决并提交 OracleJDK bug的核心过程。一、背景现象 总之就是......
  • 数据库流行度排名：Oracle 稳居第一
    数据库流行度排名：Oracle稳居第一播报文章砍柴网2018-12-0222:00砍柴网官方百家号关注日前，DB-Engines数据库流行度排行榜公布了最新的一组数据，数据显示，Oracle数据库虽然相比于前两月有所下滑，但依旧家底雄厚位列第一名。第二名同样是来自Oracle的MySQL......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99