标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,747)
- DB2 (22)
- MySQL (75)
- Oracle (1,593)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (162)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (68)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (584)
- Oracle安装升级 (95)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (84)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (30)
- SQL Server恢复 (11)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (38)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (21)
-
最近发表
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
- 虚拟机故障引起ORA-00310 ORA-00334故障处理
- pg创建gbk字符集库
- PostgreSQL运行日志管理
- ora-600 kdsgrp1 错误描述
- GAM、SGAM 或 PFS 页上存在页错误处理
- ORA-600 krhpfh_03-1208
- VMware勒索加密恢复(vmdk勒索恢复)
- ORA-39773: parse of metadata stream failed故障处理
- sql数据库备份失败—失败: 23(数据错误(循环冗余检查)
- vmdk文件被加密恢复(虚拟机文件加密)
- 差点被误操作的ORA-600 kcratr_nab_less_than_odr故障
- win平台19c 打patch遭遇2个小问题汇总
- pg单个数据库目录恢复-pdu恢复单个数据库目录数据
- pg删除数据恢复—pdu恢复pg delete数据
- .[OnlyBuy@cyberfear.com].REVRAC勒索mysql恢复
- 表dml操作权限授权给public,导致只读用户失效
- 21c数据库恢复遭遇ora-600 ktugct: corruption detected
- pg_control丢失/损坏处理
分类目录归档:数据库
pg创建gbk字符集库
记录下,Postgres库创建中文字符集
postgres=# CREATE DATABASE mydb_gbk postgres-# ENCODING 'EUC_CN' postgres-# LC_COLLATE 'zh_CN' postgres-# LC_CTYPE 'zh_CN' postgres-# TEMPLATE template0; CREATE DATABASE postgres=# \l List of databases Name | Owner | Encoding | Collate | Ctype | ICU Locale | Locale Provider | Access privileges -----------+----------+----------+-------------+-------------+------------+-----------------+----------------------- mydb_gbk | postgres | EUC_CN | zh_CN | zh_CN | | libc | postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | libc | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | libc | =c/postgres + | | | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | libc | =c/postgres + | | | | | | | postgres=CTc/postgres (4 rows)
前提系统必须支持zh_CN语言包,检查命令为:
[root@xifenfei yum.repos.d]# locale -a |grep zh_CN zh_CN zh_CN.gb18030 zh_CN.gbk zh_CN.utf8
如果没有使用yum以下命令安装
yum groupinstall "fonts" yum install glibc-langpack-zh.x86_64
PostgreSQL运行日志管理
PostgreSQL目前配置中,不直接记录日志文件,这样的情况给数据库后期出现问题(特别是无法正常启动的情况)分析带来很大麻烦,不知道具体问题所在,建议在PG安装完成之后,启用日志功能,便于数据库运行状态检查和错误跟踪,主要日志参数涉及以下配置
log_destination = 'stderr' # Valid values are combinations of # stderr, csvlog, jsonlog, syslog, and # eventlog, depending on platform. # csvlog and jsonlog require # logging_collector to be on. # This is used when logging to stderr: logging_collector = on # Enable capturing of stderr, jsonlog, # and csvlog into log files. Required # to be on for csvlogs and jsonlogs. # (change requires restart) //是否将日志重定向至文件中,默认是off。 # These are only used if logging_collector is on: log_directory = 'pg_log' # directory where log files are written, # can be absolute or relative to PGDATA //日志文件目录,默认是PGDATA的相对路径,即PGDATA的相对路径,即{PGDATA}/pg_log,也可以改为绝对路径。 //日志文件可能会非常多,建议将日志重定向到其他目录或分区。 //将此配置修改其他目录时,必须先创建此目录,并修改权限,使得postgres用户对该目录有写权限。 log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern, # can include strftime() escapes log_file_mode = 0600 # creation mode for log files, # begin with 0 to use octal notation log_rotation_age = 1d # Automatic rotation of logfiles will # happen after that time. 0 disables. log_rotation_size = 10MB # Automatic rotation of logfiles will # happen after that much log output. # 0 disables. #log_truncate_on_rotation = off # If on, an existing log file with the # same name as the new log file will be # truncated rather than appended to. # But such truncation only occurs on # time-driven rotation, not on restarts # or size-driven rotation. Default is # off, meaning append to existing files # in all cases. //当日志文件已存在时,该配置如果为off,新生成的日志将在文件尾部追加,如果为on,则会覆盖原来的日志。
上述配置得到的结果如下
[postgres@xifenfei pg_log]$ pwd /data/pg/15/data/pg_log [postgres@xifenfei pg_log]$ ls -l total 4 -rw------- 1 postgres postgres 1263 Apr 3 22:37 postgresql-2025-04-03_223117.log
ora-600 kdsgrp1 错误描述
当 fetch作找不到预期的行时,会引发 ora-600 [kdsgrp1] 错误。该错误在内存中命中,因此可能是仅内存错误或由磁盘损坏导致的错误。
此错误可能表示(但不限于)以下任何情况:
- 丢失写入
- 并行 DML 问题
- 索引损坏
- 数据块损坏
- 一致性读取 [CR] 问题
- 缓冲区缓存损坏
说明 285586.1 - ORA-600 [kdsgrp1] 中
提供了已知问题的完整列表:
每个错误都有一个简短描述,指示遇到它的情况。可以通过选择您的数据库版本来缩短 bug 列表,以仅显示可能影响您的问题。
此问题可能是间歇性的,也可能持续存在,直到修复底层磁盘级别损坏为止。间歇性问题可能是基于内存的(但是,对损坏的间歇性访问可能会与间歇性内存问题相混淆)。
常见的解决方法
如果问题仅在内存中,我们可以尝试通过刷新缓冲区缓存来立即解决问题,但请记住考虑对生产系统的性能影响:
更改系统刷新buffer_cache;
如果我们遇到间歇性一致性读取问题,我们可以尝试禁用 rowCR,这是一种优化,通过在初始化文件中设置 _row_cr=FALSE 来减少查询期间的一致性读取回滚。但是,这可能会导致查询的性能下降。请检查“RowCR hits”/“RowCR attempts”这两个统计信息的比率,以确定是否要使用解决方法。
如果这是索引损坏的结果,那么我们可以删除并重新构建索引。请注意,这将需要在 生产系统上有一个 maintenance window。
根本原因确定
现在让我们看看我们如何发现问题的根本原因:查找此问题根本原因的第一步是检查生成的跟踪文件。ora-600 将在跟踪目录中生成跟踪文件,并在事件目录中的事件 ID 下生成事件文件。
跟踪文件的顶部告诉我们遇到错误时正在运行的 SQL:
—–此会话的当前 SQL 语句 (sql_id=9mamr7xn4wg7x) —–
这立即向我们显示了访问的数据对象。在跟踪文件中搜索文本字符串 ‘Plan Table’ 将找到此跟踪文件中转储的 SQL 执行计划。对于持久性问题,这允许我们确定哪些索引已被访问,从而确定应验证以检查块损坏的索引:
SQL>分析索引 <OWNER>.<INDEX NAME>在线验证结构;
指数分析。
我们可以采取的另一种方法是使用 trace 文件中包含的 file 和 block 信息。在跟踪文件的顶部,我们将找到有关发现损坏的块的信息:
会话 ID:(3202.5644) 2011-03-19 04:12:16.910
行 07c7c8c7.a 在
文件# 31 块# 510151插槽 11 未找到的延续
行 07c7c8c7.a 在
文件# 31 块# 510151插槽 11 未找到的延续
此信息可用于识别 dba_extents 中的对象详细信息:
从 dba_extents 中选择 owner、segment_name、segment_type、partition_name,tablespace_name
其中 relative_fno = <文件 id>
并且 <block#> 在 block_id 和 (block_id+blocks-1) 之间;
其中 relative_fno = <文件 id>
并且 <block#> 在 block_id 和 (block_id+blocks-1) 之间;
然后我们可以验证这个对象,例如一个表和它的所有索引:
分析表 <OWNER>.<TABLE NAME>在线验证结构级联;
请记住,我们可能正在处理不在对象块本身中的永久损坏。这方面的示例包括:
- 可传输表空间作导致的字典损坏问题:检查 dba_tablespaces 以查看表空间是否已插入。
- ASM 磁盘组镜像中的写入丢失 – 最有可能在存在大量 IO 和磁盘重新同步活动时看到。要检查此内容,请运行 dbms_diskgroup.checkfile 以检测镜像差异
如果 analyze 报告没有损坏,则检查表上是否有任何链接的行。如果存在这些,则可能存在未检测到的损坏,并且每当运行 SQL 时,问题都会再次出现。导出表也会检测到此问题。
如果 analyze 和 export 表(在存在链式行的情况下)都报告没有错误,则应将其视为一致性读取问题。
了解问题的性质后,您可以查看已知 bug 列表并确定哪个 bug 与您的条件匹配。如果您无法确定哪个问题影响了您,请向 Oracle 技术支持提交服务请求,并上传所有节点的 RDBMS 和 ASM(如果适用)实例警报日志、生成的任何跟踪和事件文件以及问题性质的完整描述。
|