诗檀软件专业数据库修复团队
Oracle的损坏/坏块 主要分以下几种：
ORA-1578
ORA-8103
ORA-1410
ORA-1499
ORA-1578
ORA-81##
ORA-14##
ORA-26040
ORA-600 Errors
Block Corruption
Index Corruption
Row Corruption
UNDO Corruption
Control File
Consistent Read
Dictionary
File/RDBA/BL
Error DescriptionCorruption related to:
ORA-1578ORA-1578一般为Oracle检测到存在物理坏块问题，包括其检测数据块中的checksum不正确，或者tail_chk信息不正确等。ORA-1578 is reported when a block is thought to be corrupt on read.
Block
数据块
OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)” Master Note
OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)”
Fractured Block explanation
Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g
Diagnosing and Resolving 1578 reported on a Local Index of a Partitioned table
ORA-1410
ORA-1410错误常见于从INDEX或其他途径获得的ROWID,到数据表中查询发现没有对应的记录。
该错误可能因为数据表与其索引存在不一致，也可能是分区的数据表本身存在问题。
This error is raised when an operation refers to a ROWID in a table for which there is no such row.
The reference to a ROWID may be implicit from a WHERE CURRENT OF clause or directly from a WHERE ROWID=… clause.
ORA 1410 indicates the ROWID is for a BLOCK that is not part of this table.
Row
数据行
Understanding The ORA-1410
Summary Of Bugs Containing ORA 1410
OERR: ORA 1410 “invalid ROWID”
ORA-8103
该ORA-8103可能由多个BUG引起，例如LOB在10.2.0.4之前可能会由于BUG覆盖了另一张表的segment header，导致出现ORA-8103错误。
诊断该问题可以从数据表的segment header和data_object_id入手。
The object has been deleted by another user since the operation began.
If the error is reproducible, following may be the reasons:-
a.) The header block has an invalid block type.
b.) The data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. See dba_objects.data_object_id and compare it to the decimal value stored in the block (field seg/obj).
Block
数据块
ORA-8103 Troubleshooting, Diagnostic and Solution
OERR: ORA-8103 “object no longer exists” / Troubleshooting, Diagnostic and Solution
ORA-8102ORA-8102常见于索引键值与表上存的值不一致。An ORA-08102 indicates that there is a mismatch between the key(s) stored in the index and the values stored in the table. What typically happens is the index is built and at some future time, some type of corruption occurs, either in the table or index, to cause the mismatch.
Index
索引
OERR ORA-8102 “index key not found, obj# %s, file %s, block %s (%s)
ORA-1499对表和索引做交叉验证时发现问题An error occurred when validating an index or a table using the ANALYZE command.
One or more entries does not point to the appropriate cross-reference.
Index
索引
ORA-1499. Table/Index row count mismatch
OERR: ORA-1499 table/Index Cross Reference Failure – see trace file
ORA-1498 Generally this is a result of an ANALYZE … VALIDATE … command.
This error generally manifests itself when there is inconsistency in the data/Index block. Some of the block check errors that may be found:-
a.) Row locked by a non-existent transaction
b.) The amount of space used is not equal to block size
c.) Transaction header lock count mismatch.
While support are processing the tracefile it may be worth the re-running the ANALYZE after restarting the database to help show if the corruption is consistent or if it ‘moves’.
Send the tracefile to support for analysis.
If the ANALYZE was against an index you should check the whole object. Eg: Find the tablename and execute:
ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE Block
OERR: ORA 1498 “block check failure – see trace file”
ORA-26040由于采用过nologging/unrecoverable选项的redo生成机制，且做过对应的recover，导致数据块中被填满了0XFF，导致报错ORA-26040。Trying to access data in block that was loaded without redo generation using the NOLOGGING/UNRECOVERABLE option.
This Error raises always together with ORA-1578
Block
数据块
OERR ORA-26040 Data block was loaded using the NOLOGGING option
ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING – Error explanation and solution
ORA-1578 ORA-26040 in a LOB segment – Script to solve the errors
ORA-1578 ORA-26040 in 11g for DIRECT PATH with NOARCHIVELOG even if LOGGING is enabled
ORA-1578 ORA-26040 On Awr Table
Errors ORA-01578, ORA-26040 On Standby Database
Workflow Tables ORA-01578 ORACLE data block corrupted ORA-26040 Data block was loaded using the NOLOGGING option
ORA-1578, ORA-26040 Data block was loaded using the NOLOGGING option
ORA-600[12700]
从索引获得的ROWID，对应到数据表时发现不存在数据行错误。
一把是一致性度consistent read问题
Oracle is trying to access a row using its ROWID, which has been obtained from an index.
A mismatch was found between the index rowid and the data block it is pointing to. The rowid points to a non-existent row in the data block. The corruption can be in data and/or index blocks.
ORA-600 [12700] can also be reported due to a consistent read (CR) problem.
Consistent Read
一致性读
Resolving an ORA-600 [12700] error in Oracle 8 and above.
ORA-600 [12700] “Index entry Points to Missing ROWID”
ORA-600[3020]主要问题是redo和数据块中的信息不一致This is called a ‘STUCK RECOVERY’.
There is an inconsistency between the information stored in the redo and the information stored in a database block being recovered.Redo
ORA-600 [3020] “Stuck Recovery”
Information Required for Root Cause Analysis of ORA-600 [3020] (stuck recovery)
ORA-600[4194]主要是redo记录与回滚rollback/undo的记录不一致A mismatch has been detected between Redo records and rollback (Undo) records.
We are validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block.
This error is reported when the validation fails.Undo
ORA-600 [4194] “Undo Record Number Mismatch While Adding Undo Record”
Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter
ORA-600[4193]主要是redo记录与回滚rollback/undo的记录不一致A mismatch has been detected between Redo records and Rollback (Undo) records.
We are validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied.
This error is reported when this validation fails.Undo
ORA-600 [4193] “seq# mismatch while adding undo record”
Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter
Ora-600 [4193] When Opening Or Shutting Down A Database
ORA-600 [4193] When Trying To Open The Database
ORA-600[4137]transaction id不匹配，问题可能存在与回滚段中或者对象本身存在讹误While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.
This would indicate a corrupted rollback segment.Undo/Redo
ORA-600 [4137] “XID in Undo and Redo Does Not Match”
ORA-600[6101] Not enough free space was found when inserting a row into an index leaf block during the application of undo.Index
ORA-600 [6101] “insert into leaf block (undo)”
ORA-600[2103] Oracle is attempting to read or update a generic entry in the control file.
If the entry number is invalid, ORA-600 [2130] is logged.Control File
ORA-600 [2130] “Attempt to access non-existant controlfile entry”
ORA-600[4512] Oracle is checking the status of transaction locks within a block.
If the lock number is greater than the number of lock entries, ORA-600 [4512] is reported followed by a stack trace, process state and block dump.
This error possibly indicates a block corruption.Block
ORA-600 [4512] “Lock count mismatch”
ORA-600[2662]主要是发现一个数据块的SCN甚至超过了当前SCN，常规解决途径有调整SCN等，但11.2以后Oracle公司使较多调整SCN的方法失效了A data block SCN is ahead of the current SCN.
The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN stored in a UGA variable.
If the SCN is less than the dependent SCN then we signal the ORA-600 [2662] internal error.Block
ORA-600 [2662] “Block SCN is ahead of Current SCN”
ORA 600 [2662] DURING STARTUP
ORA-600[4097]访问一个回滚段头以便确认事务是否已提交时，发现XID有问题We are accessing a rollback segment header to see if a transaction has been committed.
However, the xid given is in the future of the transaction table.
This could be due to a rollback segment corruption issue OR you might be hitting the following known problem.Undo
对于windows来说，相比unix或linux *** 作起来更麻烦，其实windows也是可以使用dd的，运用dd和UE基本上可以起到和使用bbed一样的效果。大家可以在这里下载dd for win版本dd-0.6beta3
SQL>SELECT * FROM v$version
BANNER
----------------------------------------------------------------
Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE10.2.0.4.0 Production
TNS FOR 32-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL>CREATE TABLE test1 AS SELECT owner,object_id,object_name FROM dba_objects
2> WHERE rownum <500
表已创建。
SQL>SELECT header_file,header_block FROM dba_segments WHERE segment_name='TEST1'
HEADER_FILE HEADER_BLOCK
----------- ------------
5 11
SQL>SELECT DISTINCT dbms_rowid.rowid_relative_fno(rowid) file# FROM test1
FILE#
----------
5
SQL>SELECT DISTINCT dbms_rowid.rowid_block_number(rowid) blk# FROM test1
BLK#
----------
13
12
SQL>SHOW parameter db_block
NAME TYPEVALUE
------------------------------------ ----------- ------------------------
db_block_buffers INTEGER 0
db_block_checkingstring FALSE
db_block_checksumstring TRUE
db_block_sizeINTEGER 8192
-- 关闭数据库，使用万能的UE修改file 5 block 13
SQL>conn /AS sysdba
已连接。
SQL>shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL>startup
ORACLE 例程已经启动。
Total System Global Area 314572800 bytes
Fixed SIZE 1296452 bytes
Variable SIZE 96470972 bytes
DATABASE Buffers 209715200 bytes
Redo Buffers7090176 bytes
数据库装载完毕。
数据库已经打开。
SQL>conn roger/roger
已连接。
SQL>SELECT COUNT(*) FROM test1
SELECT COUNT(*) FROM test1
*
第 1 行出现错误:
ORA-01578: ORACLE 数据块损坏 (文件号 5, 块号 13)
ORA-01110: 数据文件 5: 'G:\ORACLE\PRODUCT\10.2.0\ORADATA\ALEX\ROGER01.DBF'
说明一下的是，我这里直接修改了块头中的flg，将其修改为0xff，oracle将直接标记为物理坏块。
C:\>dbv file=G:\ORACLE\PRODUCT\10.2.0\ORADATA\ALEX\ROGER01.DBF blocksize=8192
DBVERIFY: Release 10.2.0.4.0 - Production on 星期六 7月 9 15:48:35 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY - 开始验证: FILE = G:\ORACLE\PRODUCT\10.2.0\ORADATA\ALEX\ROGER01.DBF
页 13 标记为损坏
Corrupt block relative dba: 0x0140000d (file 5, block 13)
Bad check value found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x0140000d
last change scn: 0x0000.000fbf2f seq: 0x2 flg: 0xff
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0xbf2f0602
check value in block header: 0xd7f
computed block checksum: 0xfb00
DBVERIFY - 验证完成
检查的页总数: 2560
处理的页总数 (数据): 1
失败的页总数 (数据): 0
处理的页总数 (索引): 0
失败的页总数 (索引): 0
处理的页总数 (其它): 11
处理的总页数 (段) : 0
失败的总页数 (段) : 0
空的页总数: 2547
标记为损坏的总页数: 1
流入的页总数: 0
最高块 SCN: 1031985 (0.1031985)
修复坏块的方式大家都知道有很多，我就不多说了，我这里需要说的是，windows下我用dd将该block取出来。
然后使用bbed进行修改（当然，既然我们能用UE制造坏块，那么也就可以完全用UE来修复坏块，只是非常难）
-- 使用dd 复制file 5 block 13
C:\>dd if=G:\ORACLE\PRODUCT\10.2.0\ORADATA\ALEX\ROGER01.DBF of=5.13.dd skip=13 bs=8192 count=1
rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.
skip to 106496
1+0 records in
1+0 records out
C:\Documents and Settings\Administrator>dir *dd
驱动器 C 中的卷是 system
卷的序列号是 48A6-367D
C:\Documents and Settings\Administrator 的目录
2011-07-09 15:32 8,192 5.13.dd
1 个文件 8,192 字节
0 个目录 9,338,363,904 可用字节
由于我这里是10204的，所以就不用9iR2的bbed for win版本了，我将dd出来的file 5.13.dd文件传到linux中，进行修复
[oracle@roger ~]$ ls -ltr 5.13*
-rw-r--r-- 1 oracle dba 8192 Jul 9 2011 5.13.dd
[oracle@roger ~]$ bbed parfile=par.bbd
Password:
BBED: Release 2.0.0.0.0 - Limited Production on Sat Jul 9 15:34:38 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED>info
File# NameSize(blks)
----- --------------
1 /oracle/product/oradata/roger/system01.dbf 61440
2 /oracle/product/oradata/roger/undotbs01.dbf 3200
3 /oracle/product/oradata/roger/sysaux01.dbf 30720
4 /oracle/product/oradata/roger/users01.dbf 640
5 /oracle/product/oradata/roger/roger01.dbf0
6 /home/oracle/5.13.dd 1
BBED>set file 6
FILE# 6
BBED>p kcbh
struct kcbh, 20 bytes @0
ub1 type_kcbh@00x06
ub1 frmt_kcbh@10xa2
ub1 spare1_kcbh @20x00
ub1 spare2_kcbh @30x00
ub4 rdba_kcbh@40x0140000d
ub4 bas_kcbh @80x000fbf2f
ub2 wrp_kcbh @12 0x0000
ub1 seq_kcbh @14 0x02
ub1 flg_kcbh @15 0xff (KCBHFNEW, KCBHFDLC, KCBHFCKV)
ub2 chkval_kcbh @16 0x0d7f
ub2 spare3_kcbh @18 0x0000
BBED>modify /x 4 offset 15
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /home/oracle/5.13.dd (6)
Block: 1Offsets: 15 to 511 Dba:0x01800001
------------------------------------------------------------------------
047f0d00 00010000 008ccb00 002dbf0f 00000000 00030032 00090040 01ffff00
00000000 00000000 00000000 00008000 002dbf0f 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 000001c7 00ffffa0 01dc0c3c 0b3c0b00 00c7005d
1f3e1f1d 1ffb1eda 1eb71e93 1e7b1e5f 1e4c1e3a 1e221e0a 1ef01dd4 1dbd1da4
1d891d6c 1d591d44 1d331d21 1d0b1de6 1cd51cc3 1cad1c88 1c771c65 1c4f1c2a
1c191c07 1cf11bcc 1bba1ba7 1b911b6c 1b5a1b47 1b311b0c 1bfb1ae8 1ad51ac0
1aab1a97 1a7e1a6a 1a561a3c 1a271a16 1a001aed 19d519c3 19b1199f 198a1978
195f194c 19341922 191019fd 18ea18d6 18c018b0 188b1866 1852183c 18231809
18f317d9 17bf17a5 1792177b 17681751 173d1725 171217fb 16e416d0 16b816a6
1690167a 16641654 1640162b 161216fa 15de15c2 15ab1590 15751561 15491531
1520150b 15f514db 14cb14ba 14a81495 1481146d 14581444 142f141b 140614f2
13d813bd 13ac1396 136f1359 1344132a 131213f5 12e512ca 12b61291 127b1267
12511237 121f1205 12ed11d3 11bd11a8 1192117a 1164114d 11361120 110c11f7
10dc10c3 10a4108f 10781061 10481034 101b1000 10e60fc1 0faa0f90 0f760f5a
0f3a0f1a 0f000fe3 0ec60eae 0e940e7b 0e
<32 bytes per line>
BBED>sum apply
Check value for File 6, Block 1:
current = 0x46c3, required = 0x46c3
C:\>dd if=5.13.dd of=G:\ORACLE\PRODUCT\10.2.0\ORADATA\ALEX\ROGER01.DBF seek=13 bs=8192 count=1 conv=notrunc
rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.
notrunc
1+0 records in
1+0 records out
如上是通过bbed来修改的，当然，我们还可以用dbms_repair包来 *** 作，它实质是对坏块进行标记，
然后oracle在做扫描block的时候，会跳过该坏块，类似event 10231.
SQL>BEGIN
2DBMS_REPAIR.ADMIN_TABLES (
3TABLE_NAME =>'REPAIR_TABLE',
4TABLE_TYPE =>DBMS_REPAIR.repair_table,
5ACTION =>DBMS_REPAIR.create_action,
6TABLESPACE =>'ROGER')
7END
8/
PL/SQL 过程已成功完成。
SQL>SET serveroutput ON
SQL> DECLARE num_corrupt INT
2 BEGIN
3 num_corrupt := 0
4 DBMS_REPAIR.CHECK_OBJECT (
5 SCHEMA_NAME =>'ROGER',
6 OBJECT_NAME =>'TEST1',
7 REPAIR_TABLE_NAME =>'REPAIR_TABLE',
8 corrupt_count =>num_corrupt)
9 DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt))
10 END
11 /
NUMBER corrupt: 1
PL/SQL 过程已成功完成。
SQL>SELECT object_id,RELATIVE_FILE_ID,block_id,CORRUPT_TYPE,object_name
2 FROM repair_table
OBJECT_ID RELATIVE_FILE_ID BLOCK_ID CORRUPT_TYPE OBJECT_NAME
---------- ---------------- ---------- ------------ ---------------
521085 13 6148 TEST1
SQL>DECLARE
2 fix_count int
3 BEGIN
4fix_count := 0
5DBMS_REPAIR.fix_corrupt_blocks (
6schema_name =>'ROGER',
7object_name =>'TEST1',
8object_type =>DBMS_REPAIR.table_object,
9repair_table_name =>'REPAIR_TABLE',
10fix_count =>fix_count)
11 DBMS_OUTPUT.put_line('fix count: ' || TO_CHAR(fix_count))
12END
13/
fix COUNT: 0
PL/SQL 过程已成功完成。
SQL>BEGIN
2 DBMS_REPAIR.skip_corrupt_blocks (
3schema_name =>'ROGER',
4object_name =>'TEST1',
5object_type =>DBMS_REPAIR.table_object,
6flags =>DBMS_REPAIR.skip_flag)
7END
8/
PL/SQL 过程已成功完成。
SQL>conn roger/roger
已连接。
SQL>SELECT COUNT(*) FROM test1
COUNT(*)
----------
300
BBED>p kdbt
struct kdbt[0], 4 bytes @138
b2 kdbtoffs @138 0
b2 kdbtnrow @140 199
可以发现，完全跳过了坏块file 5 block 13，现在正常数据是300条（其中坏块13中包含数据199条）.
补充一点的是，我们还可以使用基于rowid扫描，将test1表中的其他数据给提取出来。
如下是利用基于rowid扫描的方式保存除坏块以外的正常数据：
SQL>SELECT dbms_rowid.rowid_create(1,52108,5,13,0) FROM dual
DBMS_ROWID.ROWID_C
------------------
AAAMuMAAFAAAAANAAA
SQL>SELECT dbms_rowid.rowid_create(1,52108,5,14,0) FROM dual
DBMS_ROWID.ROWID_C
------------------
AAAMuMAAFAAAAAOAAA
SQL>CREATE TABLE test1_bak AS
2SELECT /* rowid(test1) */ * FROM test1
3WHERE rowid <CHARTOROWID('AAAMuMAAFAAAAANAAA')
4OR rowid >= CHARTOROWID('AAAMuMAAFAAAAAOAAA')
表已创建。
SQL>SELECT COUNT(*) FROM test1_bak
COUNT(*)
----------
300
最后再补充一点的是，如果表有索引，那么记得 *** 作完以后记得rebuild index。
方法一：用PartitionMagic等磁盘软件完成工作如PartitionMagic分区软件，先用PartitionMagic4中的“check”命令或Windows中的磁盘扫描程序来扫描磁盘，算出坏簇在硬盘上的位置，然后在Operation菜单下选择“Advanced/badSectorRetest”，把坏簇所在硬盘分成多个区后，再把坏簇所在的分区隐藏，以免在Windows中误 *** 作，这个功能是通过HidePartition菜单项来实现的。这样也能保证有严重坏道的硬盘的正常使用，并免除系统频繁地去读写坏道从而扩展坏道的面积。但是这需要对这些软件熟悉，并且有计算硬盘的经验，许多人并不容易做到准确。
方法二：用FDISK和格式化命令FORMAT
具体的方法是这样的，第一要搞清硬盘的容量，对于有问题的磁盘先用FDISK分成一个C盘，再用FORMAT进行格式化，当碰到无法修复的坏块时面对FORMAT总是试图修复，这时记录下进行的百分比.然后按CTRL+BREAK强行终止任务，用磁盘总容量×百分比，得出这部分正常的磁盘容量，用FIDSK划出一个逻辑磁盘，再将后面的磁盘估计出坏道的大概大小，大概比例为10%左右，再划分一个逻辑盘。这个小盘不用格式化，在总工作完成后将其删除，这样就将坏块给全部跳过去了。这样可能会损失一些好道，但对大容量硬盘来说无足轻重，而硬盘使用起来更加稳定。
方法三：用专门的坏盘分区工具如FBDISK
FBDISK这是一个DOS下专门发现坏道并隔离后重新分区的软件，只有一个文件，仅仅几十K。 *** 作很简单，先制作一张能启动到DOS的软盘，把FBDISK放在软盘上，用它引导系统，注意系统上只能挂一个要修理的硬盘，并且将其接在主硬盘的线上。进入DOS后，只要能发现硬盘，就运行FBDISK好了，这个小程序先会对硬盘按磁道进行扫描，发现坏道就显示出来，同时还会估计总体扫描完要用多长时间，全部扫描完后，程序会根据扫描结果和坏道情况给你提出一个全新的分区方案来，如果接受就按Y，否则不会对你的硬盘进行处理。
还有一类特别的坏道表面看起来很可怕，其实反而好修理，如系统显示“TRACK 0 BAD，DISKUNUSABLE”，意思为“零磁道损坏，硬盘无法使用”或用磁盘扫描程序扫描其它硬盘时其0扇区出现红色“B”。大家都知道硬盘扇区是最重要的地方，损坏后一点也不能用，一般人往往将出现这样故障的硬盘作报废处理。其实合理运用一些磁盘软件，把报废的0扇区屏蔽掉，而用1扇区取而代之就能起到起死回生的效果，这样的软件如Pctools9.0和NU8等。
以Pctools9.0为例来作说明。一块80G老硬盘出现上述故障，用盘启动电脑后，运行Pctools9.0目录下的DE.EXE文件。接着选主菜单Select中的Drive，进去后在Drivetype项选Physical，按空格选定，再按Tab键切换到Drives项，选中harddisk，然后OK回车后回到主菜单。打开Select菜单，这时会出现PartitionTable，选中进入后出现硬盘分区表信息。该硬盘有两个分区，找到C区，该分区是从硬盘的0柱面开始的，那么，将1分区的BeginningCylinder的0改成1就可以了，保存后退出。重新启动电脑后按Del键进入COMS设置，运行“IDEAUTODETECT”，可以看到CYLS由782变成781。保存退出后重新分区格式化该硬盘就可以了。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）