- 博客(160)
- 资源 (21)
- 收藏
- 关注
RSS订阅原创 记录一次asm disk加入到vg通过恢复直接open库的案例---惜分飞
通过底层对磁盘进行分析,发现备份的磁盘头均以损坏,通过深入分析确认f1b1在sdb磁盘的第10个au上,通过相关信息,使用dul工具加载磁盘组,并分析元数据信息,发现恢复数据需要的元数据都可以正常加载。1)asm disk 加入到vg,并分配给lv之后,立刻停止写入操作,避免了因为写入数据而覆盖asm 磁盘的带来的风险。客户在不清楚磁盘被asm disk使用的情况下,直接分区做pv,加入到vg中并且分配给了lv,导致数据库异常。4)是云环境的ssd磁盘,没有触发trim功能。
2025-05-07 15:01:27
427
原创 Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
至此数据库open成功,由于该库有不少坏块(包括system的一些字典),后续使用逻辑方式迁移数据到新库中(其中由于C_OBJ#簇中有坏块,导致迁移过程中大量index丢失,通过一些方法使用obj$,inde$等基表人工生成index.sql对于丢失的index进行弥补),最终客户业务正常运行。接到客户反馈,一套运行在虚拟化平台中的Oracle数据库,由于机房断电,导致数据库无法启动,最初启动报错。1.在需要实例恢复的block中有坏块,而且主要集中在3号文件(sysaux)上。
2025-04-25 13:09:08
722
原创 Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
发现2号数据文件异常,报ORA-600 6101和ORA-600 kdxlin:psno out of range错误,出现该错误的原因主要是由于数据文件的bock和redo中信息不匹配导致,对于这种情况,我这边选择使用。数据库异常断电,然后启动异常,我接手该库,尝试recover恢复。逻辑方法导出该库,完成该库的恢复工作。再次recover并且直接打开库。
2025-04-19 22:06:24
471
原创 VMware勒索加密恢复(vmdk勒索恢复)---惜分飞
客户运行VMware Esxi由于被黑客攻破,导致所有的vmdk文件均被加密,其中包含大量的数据库虚拟机,这段时间,客户找了不少人进行分析恢复,要不就是恢复效果不好,要不就是要加太高,通过底层分析,确认可以比较完美的恢复,包括虚拟机直接运行的mysql、oracle数据库,docker中运行的mysql数据库,那其中一个恢复case来说明,被加密的虚拟机文件是一个500G的vmkd文件(.vmdk.{74C1B740-FEC0-01BD-914B-5F2CBAAA094E}.tianrui)
2025-03-31 18:06:14
333
原创 虚拟化加密恢复---惜分飞
通过底层分析,确认vmdk文件可以通过找出来分区信息,确认当时运行的是一个win操作系统。README.TXT文件内容如下,预留邮箱为:tianrui@mailum.com。有客户的vm虚拟化平台被勒索病毒加密,扩展名为:.tianrui。查看对应分区中数据情况。
2025-03-20 23:35:15
212
原创 ora-600 ktugct: corruption detected---惜分飞
基于上述信息基本上可以确认是由于我们修复的undo文件和seq$中的file#=1 block#=1161不匹配导致该问题,对其进行处理之后,数据库open成功。脚本检测之后,发现undo文件offline之后,做了resetlogs操作,导致该文件目前处于WRONG RESETLOGS状态。对于该错误,可以通过rectl进行解决,但是由于undo文件的resetlog 信息不对,无法直接重建ctl,这种情况下,通过。所幸客户需要的数据直接在cdb中,直接使用expdp导出客户需要的数据,完成本次恢复。
2025-03-18 22:30:53
985
原创 .[OnlyBuy@cyberfear.com].REVRAC勒索mysql恢复---惜分飞
当然前提需要有表创建语句,这个客户有昨天的备份的被的.sql备份,通过技术手段分析,确认只有3个表的创建语句丢失,对于丢失的ddl语句,通过直接对ibdata文件解析获取,基于这些信息结合,实现数据的完美恢复。对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,可以联系专业恢复技术支持。8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。9.保存良好的备份习惯，尽量做到每日备份，异地备份。
2025-03-18 22:28:38
390
转载 ora-600 ktugct: corruption detected--故障处理---惜分飞
ORA-00600: 内部错误代码, 参数: [ktugct: corruption detected], [], [], [], [], [], [], [], [], [], [], []ORA-00600: 内部错误代码, 参数: [ktugct: corruption detected], [], [], [], [], [], [], [], [], [], [], []所幸客户需要的数据直接在cdb中,直接使用expdp导出客户需要的数据,完成本次恢复。进一步分析trace信息。
2025-03-12 21:45:02
20
转载 aix磁盘损坏oracle数据库恢复---惜分飞
客户aix环境硬盘异常导致系统无法启动,初步判断是数据文件存放在本地磁盘的空间中(本地两个盘都异常,系统无法启动),通过硬件恢复厂商镜像出来,但是通过aix文件系统直接挂载提示需要fsck,但是做fsck之后,提示大量文件丢失(最关键的数据文件和备份文件都被自动删除)基于这种情况,采用镜像主机挂载的方式肯定不行,考虑直接采用软件直接解析,能够看到软件,可惜由于大量的文件系统元数据损坏,解析出来的数据文件和dmp也不可用(大量损坏和空块)对于数据库级别恢复,这个是理论上的终极恢复方法。
2025-03-08 22:38:48
13
转载 pg误删除数据恢复（PostgreSQL delete数据恢复）---惜分飞
应用维护人员通过应用程序误删除了一些数据,希望对其进行恢复.通过咨询确认是PostgreSQL数据,wal和arch文件都在,取客户删除数据时间点相关wal文件。如果此类的数据库(oracle,mysql,sql server,PostgreSQL)等恢复请求,需要专业恢复技术支持。通过工具解析wal日志,比较顺利的获取到了undo sql语句。然后把这些sql语句反向插入到生产库,完成这些误操作数据的恢复。然后让客户提供具体涉及误删除的相关的库和表信息。
2025-03-08 22:37:56
108
转载 linux rm -rf 删除数据文件恢复---惜分飞
在这个恢复过程中,由于客户linux是物理机,而且本地空间不足,无法对其进行镜像,采用dd命令直接写镜像到其他的linux机器上（通过nfs方式),然后在win机器上直接挂载该nfs,记录下win上挂载nfs操作。有客户由于误操作删除了oracle的部分数据文件(rm -rf 方式删除),然后自己尝试进行恢复操作,对部分文件执行了offline,导致比较麻烦的后果。
2025-03-08 22:36:14
26
转载 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理---惜分飞
最近有客户在虚拟化平台运行oracle,由于机房掉电,导致oracle数据库无法正常启动,通过第三方恢复,oracle被强制拉起,但是无法进行ddl操作,比如创建表报ORA-08102: 未找到索引关键字, 对象号 39, 文件 1, 块 122448 (2) 错误。处理完上述两个明显故障之后,然后使用expdp不落地方式把客户数据迁移到新库,完成本次恢复任务。这个问题解决之后,该客户还有另外一个问题需要解决（不然数据库运行一段时间之后就会crash）
2024-12-24 20:12:30
143
转载 ORA-00227: corrupt block detected in control file---惜分飞
由于对oracle粗心对于oracle版本判断失误,导致打开数据库失败,使用正确版本打开数据库发现ctl有报错,导致打开依旧失败(这种错误一般比较少见，大部分ctl异常都是在oracle mount状态无法成功)报错提示比较明显,是由于oracle恢复需要的redo损坏,导致无法进行正常恢复,这种情况下,只能尝试强制打开库。由于服务器断电，导致oracle数据库无法正常启动，recover报ORA-00353 ORA-00312错。重建ctl,打开数据库成功,导出数据,完成本次恢复任务。
2024-12-20 20:53:09
95
转载 解决oracle数据文件路径有回车故障---惜分飞
最近遇到一个硬件恢复朋友的请求,oracle数据库文件恢复出来了,但是在linux上面启动的时候,有两个文件无法检测到,dbv检测正常.2.操作系统层面查看文件（在我的ssh工具中,可以看到带回车键文件和不带回车文件不一样,使用的是crt工具,其他工具是否显示不确定）3. 数据库层面重启看文件情况,发现文件不能被正常发现(当然不能,文件被os层面mv了)进一步检查发现原库这两个文件结尾带有回车,但是恢复出来的文件不带回车。4. 解决控制文件和数据文件实际名称不一致问题。通过分析是由于文件无法找到原因导致。
2024-12-14 08:50:21
48
原创 .wstop扩展名勒索数据库恢复---惜分飞
通过定期的网络安全培训和教育，向用户传达有关勒索病毒及其传播方式的知识，让他们能够警惕潜在的威胁，并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制：实施严格的访问控制措施，限制用户对系统和文件的访问权限，避免使用管理员权限进行日常操作，以减少恶意软件感染的风险。此外，定期进行系统维护和检查，确保系统的安全配置和设置。6. 应急响应计划：制定和实施应急响应计划，明确团队成员的责任和任务，建立应对勒索病毒和其他安全事件的应急响应流程，以最大程度地减少损失并快速恢复业务正常运营。
2024-12-08 10:11:41
1778
4
原创 Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障（文件offline）---惜分飞
客户在win上面迁移数据文件,由于原库非归档,结果导致有两个文件scn不一致,无法打开库,结果他们选择offline文件,然后打开数据库。对于这类缺少归档数据文件offline的故障Oracle Recovery Tools可以快速傻瓜式恢复。由于这两个文件处于offline状态导致客户很多操作报ORA-00376 ORA-01110之类错。后面自行尝试recover 数据文件没有成功。然后直接recover 数据文件成功。
2024-12-07 22:58:24
447
原创 dd破坏asm磁盘头恢复---惜分飞
从10.2.0.5之后版本,在第二个au的倒数第二个block上面,有asm disk header备份（每个block大小为4k）,分析au大小(通过分析正常的asm disk快速找到au 大小【使用dd备份的正常的磁盘头查看】)基于上述分析,直接使用备份的asm disk header信息进行merge或者repair修复之后,asm 磁盘头状态恢复正常。确认被损坏的磁盘只有磁盘头信息损坏(即确认第二个block是否是好的)找到被破坏的asm disk的备份磁盘头信息。
2024-12-06 20:48:50
481
原创 删除asmlib磁盘导致磁盘组故障恢复---惜分飞
有客户执行drop disk磁盘组操作之后,然后立刻从oracle asmlib层面执行了oracleasm deletedisk,并且在操作系统层面delete partition(删除磁盘分区),导致磁盘组直接dismount。通过重新分区,并且kfed repair修复磁盘头操作之后,重新mount磁盘组报错。1. 直接恢复出来该磁盘组数据然后打开该库。2. 直接提取客户需要的核心表数据。
2024-12-06 20:47:03
313
原创 ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复---惜分飞
通过对该文件底层block分析,确认最终丢失block就是最后20M(直接的数据文件的block的rdba均正确),对于这种故障,通过填补数据文件尾部,欺骗数据库完成该文件的恢复(最后20M中如果写入了业务数据,可能会丢失),做好该文件修复工作之后,尝试打开数据库,结果很不乐观,redo也损坏。客户虚拟化环境,由于断电,启动数据库报ORA-01157错误,通过操作系统层面查看,发现文件是存在的,但是dbv检测报不可访问。感觉是文件系统损坏了,尝试把该文件拷贝到其他磁盘。屏蔽一致性,强制打开库成功。
2024-10-19 22:03:30
581
原创 清空redo导致oracle故障恢复---惜分飞
这种情况下,所有redo全部被清空(包含current,active的redo),只能强制拉库,运气不错,拉库成功.客户由于空间不足,使用> redo命令清空了oracle的redo文件。数据库挂掉之后,启动报错。
2024-10-16 22:23:32
576
原创 A_H_README_TO_RECOVER勒索恢复---惜分飞
对于类似这种A_H_README_TO_RECOVER勒索恢复,建议先对系统进行镜像或者快照,然后按照先os层面恢复,在block级别恢复的方法处理,如果无法自行解决,可以联系我们进行技术支持,最大限度抢救和数据,减少损失,处理方法一般也就是先考虑os层面恢复,如果os层面无法恢复,就从block层面进行恢复,这个客户通过最终分析,恢复出来客户需要的表数据。有客户mysql数据库被黑(业务数据库被删除)，创建了一个A_H_README_TO_RECOVER库。
2024-10-05 10:16:46
680
原创 ORA-01558: out of transaction ID‘s in rollback segment SYSTEM---惜分飞
客户一个11.2.0.1的库,在重启之前报ORA-00604和ORA-01558: out of transaction ID’s in rollback segment SYSTEM错误。由于客户遇到故障之后,第一时间保护了现场,没有进行二次破坏,使用bbed进行修改block,实现完美恢复.处理方法,通过bbed对异常的block进行编辑,修改Wrap#的值,重新dumpblock进行确认。数据库关闭之后无法open,报ORA-01092 ORA-00604 ORA-01558错误。
2024-09-21 23:58:30
1295
原创 Oracle 19c异常恢复—ORA-01209/ORA-65088---惜分飞
ORA-65088参见官方:ORA-65088 while opening DB with resetlogs for multi-tenant DB in 12.2 (Doc ID 2449591.1),应该不是一个技术问题(由于重建ctl+resetlogs导致)由于raid卡bug故障,导致文件系统异常,从而使得数据库无法正常启动,客户找到我之前已经让多人分析,均未恢复成功,查看alert日志,发现他们恢复的时候尝试resetlogs库,然后报ORA-600 kcbzib_kcrsds_1错误。
2024-09-17 21:52:37
1588
原创 ORA-600 16703故障再现---惜分飞
由于此类故障出现较多,破坏性加大,对其进行了深入的研究,在没有破坏现场的情况下,通过对tab$进行直接重建,实现数据库完美恢复(数据0丢失,数据库无需逻辑迁移[原库直接可用])尽可能不要从互联网下载Oracle安装介质和Patch,避免被注入恶意脚本,并检查已经存在的安装介质的sha256码。)至今已经7年多时间了,最近依旧有客户中招。从第一次发现ORA-600 16703(
2024-09-16 09:41:50
586
原创 .[metro777@cock.li].Elbie勒索病毒加密数据库恢复---惜分飞
通过定期的网络安全培训和教育，向用户传达有关勒索病毒及其传播方式的知识，让他们能够警惕潜在的威胁，并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制：实施严格的访问控制措施，限制用户对系统和文件的访问权限，避免使用管理员权限进行日常操作，以减少恶意软件感染的风险。此外，定期进行系统维护和检查，确保系统的安全配置和设置。6. 应急响应计划：制定和实施应急响应计划，明确团队成员的责任和任务，建立应对勒索病毒和其他安全事件的应急响应流程，以最大程度地减少损失并快速恢复业务正常运营。
2024-09-13 20:59:52
406
原创 应用连接错误,初始化mysql数据库恢复---惜分飞
登录操作系统查看,发现数据库文件在根分区,创建了新库,写入了数据之外,还有几个G的binlog.全部恢复不太可能,最后客户决定需要恢复的2个核心表数据,估计也就几十M的数据.通过os层面进行分析,发现操作系统的反删除恢复无法实现这类数据恢复.最后决定从mysql innodb的的碎片级别记性扫描恢复,通过扫描发现较多碎片。有人在部署一个新网站的时候,写错了配置信息,直接导致原有数据库被清掉,并创建了新库和写入了数据(其实本质就是drop table恢复)
2024-09-10 20:24:13
483
原创 drop tablespace xxx including contents恢复---惜分飞
所以这个恢复相对比较简单,直接使用dul之类工具扫描数据文件获取到实际数据.结合客户导出的元数据和通过一些途径恢复出来的dataobj#信息,进行整合,实现数据接近完美恢复,可以业务直接启动成功,其中几个大表的lbo字段数据恢复情况。客户在咨询我的同时,也咨询了其他人,有人给客户答复是可以通过修改字典(以为有导出的元数据就可以逆向想改文件回去),然后把数据文件拷贝过去,实现恢复,成功概率65%[只能说是真牛]4)数据文件复制到新库,完全不是同一个库的,要大量修改文件头信息,我估计他们在这一步都不能成功。
2024-09-05 13:24:31
543
原创 ORA-600 krhpfh_03-1210故障处理---惜分飞
这样的情况,根据以往经验,ORA-01207: file is more recent than control file通过重建ctl即可恢复,先关闭所有节点,然后尝试启动一个节点。1. 是由于该集群本身多节点(6个节点),只要有节点是open状态,其他节点关闭再启动依旧可以正常启动,但是无法写入数据到报ORA-01207错误的数据文件中(可以读取数据).修改好这些值之后，recover database和open数据库成功,检查字典正常,业务读写也正常,完成本次恢复任务。
2024-08-26 12:28:57
767
原创 redo写丢失导致ORA-600 kcrf_resilver_log_1故障---惜分飞
有一个客户硬件故障,做完硬件恢复之后,数据库启动报ORA-600 kcrf_resilver_log_1错误.查询mos出现该问题的原因一般是由于redo log write lost导致。
2024-08-26 12:27:18
253
原创 19c库启动报ORA-600 kcbzib_kcrsds_1---惜分飞
官方关于kcbzib_kcrsds_1从解释只有:Bug 31887074 – sr21.1bigscn_hipu3 – trc – ksfdopn2 – ORA-600 [kcbzib_kcrsds_1] (Doc ID 31887074.8)一套19c的库由于某种情况,发现异常,当时的技术使用隐含参数强制拉库,导致数据库启动报ORA-00704 ORA-600 kcbzib_kcrsds_1错误。
2024-08-26 12:26:16
688
原创 200T 数据库非归档无备份恢复---惜分飞
一套近200T的,6个节点的RAC,由于存储管线链路不稳定,导致服务器经常性掉盘,引起asm 磁盘组频繁dismount/mount,数据库集群节点不停的重启,修复好链路问题之后,数据库启动报ORA-01113,ORA-01110。由于数据库是非归档模式,该库无法通过应用归档日志来实现对这些文件进行恢复,对于这种情况,直接使用dbms_diskgroup把数据文件头拷贝到文件系统中,类似操作。通过上述操作,确认bbed修改文件头成功,后续类似方法对其他9个文件进行修改,并打开数据库。
2024-08-15 21:18:30
990
原创 [comingback2022@cock.li].eking和[tsai.shen@mailfence.com].faust扩展名勒索病毒数据库可以完美恢复---惜分飞
最近接到两个由于操作系统文件被加密,其中的Oracle数据库文件被勒索病毒加密恢复的请求,通过底层分析,确认这两种勒索病毒加密的数据库能够非常好的恢复（可以通过修复,直接open库,然后导出数据,业务直接使用）通过定期的网络安全培训和教育，向用户传达有关勒索病毒及其传播方式的知识，让他们能够警惕潜在的威胁，并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制：实施严格的访问控制措施，限制用户对系统和文件的访问权限，避免使用管理员权限进行日常操作，以减少恶意软件感染的风险。
2024-08-08 11:47:20
547
原创 断电引起redo和数据文件不一致故障恢复---惜分飞
尝试数据库恢复各种报错ORA-600 kdourp_inorder2,ORA-600 3020,ORA-7445 kdxlin等。有些时候故障总是来的让人非常意外,这个在准备停机迁移数据库之前的几分钟由于某种原因直接导致主机掉电,再次开机数据库无法启动。通过分析确认有部分数据文件和redo信息不匹配,导致无法正常recover成功。后续处理异常表,lob,index等数据,客户业务测试都ok,完成本次恢复工作。然后重建ctl，recover 数据库并open成功。
2024-08-04 21:09:46
827
原创 存储宕机导致Oracle异常故障处理---惜分飞
操作到这里,后续问题就比较麻烦了,因为在asm磁盘组中数据文件重建ctl的时候遗漏3个并且还被resetlogs操作过,导致这三个文件的resetlogs scn和其他数据文件不一致,对于这个问题,解决办法通过。客户尝试重建ctl进行恢复,结果由于分析不正确,导致在重建ctl的时候,遗漏了3个数据文件,并且在屏蔽一致性的情况下,强制resetlogs操作,结果数据库没有被正常打开,而是报ORA-600 2662错误。工具或者bbed修改相关resetlogs scn,然后重建ctl。
2024-07-28 22:37:11
628
原创 ORA-00756 ORA-10567故障处理---惜分飞
由于无法直接应用日志打开库,尝试屏蔽一致性,强制打开库,报ORA-600 kcbzib_kcrsds_1错误。数据库异常断电之后，recover 报ORA-00756 ORA-10567等错。,open数据库之后，尝试导出数据,报各种错误。),然后打开库,报ORA-600 6711。alert日志报大量block逻辑错误。使用Patch_SCN工具修改scn(dbv检查system文件报有坏块。进行处理,数据库可以正常导出。ORA-600 6711报错。ORA-01578报错。
2024-07-17 22:13:05
1078
原创 ORA-01092 ORA-00604 ORA-08103故障处理---惜分飞
因为数据库启动执行的delete from histgrm$操作不是必须的,因此在数据库启动过程中让该sql不执行,实现数据库open成功。跟踪启动过程发现delete from histgrm$ where obj# = :1遭遇到ORA-08103错误。然后再对histgrm$表对象进行处理,数据库恢复正常。对应的alert日志。
2024-07-15 16:25:06
464
原创 数据库启动报ORA-600 6711故障分析处理---惜分飞
确认对对象为cluster C_OBJ#_INTCOL#,对应的表为HISTGRM$(统计信息中存储直方图信息表)，明白这一些,处理起来就比较容易了,open数据库过程中绕过该对象访问,然后对该表进行处理即可。几个月以前的一个数据库故障,今天拿出来在win上重新分析,数据库启动报ORA-600 6711错。通过对相关rdba进行dump分析,确认对象id为64和trace中报的信息匹配。进一步分析该id为什么对象,使用dul unload obj$查看对应的trace文件。这个操作触发了递归查询。
2024-07-15 16:24:24
468
原创 Patch SCN使用说明---惜分飞
该软件是惜分飞（https://www.xifenfei.com）开发，仅用来查看和修改Oracle数据库SCN(System Change Number),主要使用在数据库因为某种原因导致无法正常启动的情况下使用该工具进行解决.特别是Oracle新版本中使用隐含参数,event,oradebug等方法无法推进Oracle SCN的情况下，使用该工具能够快速修改SCN,实现数据库启动成功.
2024-07-05 22:37:21
946
原创 异常断电数据库恢复-从ORA-600 2131到ORA-08102: 未找到索引关键字, 对象号 39---惜分飞
该对象属于bootstrap$中核心对象，无法直接rebuild,参考下面文章处理,然后再尝试导出数据。错误，这些错误本质都是由于redo信息和block信息不匹配导致。obj 39 为OBJ$的I_OBJ4对象报ORA-08102。尝试导出数据报ORA-08102,导致数据库无法正常导出。通过屏蔽一致性,修改文件头scn,强制打开数据库。重建ctl，然后重试recover 数据库，报。
2024-06-06 11:21:33
663
原创 ORA-600 2131故障处理---惜分飞
这个错误是由于controlfile损坏导致,有这个库以前部署过rman备份，解决起来比较简单，使用rman还原控制文件,并尝试recover。这种恢复情况下,如果现在要打开库,需要resetlogs方式,考虑通过创建ctl直接打开（不想用resetlogs）数据库启动报ORA-600 2131错误,查看alert日志发现是在mount过程报错。
2024-05-30 22:35:24
634
oracle scn修改利器-Patch SCN最新版-202501
2024-07-05
Patch-SCN 小工具使用说明
2024-07-05
Oracle Recovery Tools-最新版（202501）
2023-04-10
ORA-702_Recovery使用说明
2022-07-21
Oracle Recovery Tools-202207版
2022-06-26
修改oracle scn小工具(patch scn)
2022-06-18
oracle patch scn--修改oracle scn工具（oracle异常恢复利器）
2022-06-18
Oracle Recovery Tools-202208版本
2021-10-19
Oracle Recovery Tools 使用说明
2021-10-06
12c – 使用跨平台增量备份来减少传输表空间的停机时间 (Doc ID 2102859.1).pdf
2020-08-15
rman_xttconvert_VER4.3.zip.7z
2020-08-15
ufsxpci64.zip
2020-03-08
基于odp.net的oraclehelper
2010-04-16
silverlight访问数据库汇总
2009-08-19
html+ashx论坛
2009-06-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人