可以使用python转译一下
python3 <<‘PY’
import re
text = open(‘dept_macro_1219.txt’).read()
for m in re.finditer(r’hex: ([0-9A-Fa-f]+)’, text):
print(bytes.fromhex(m.group(1)).decode(‘utf-8’))
PY
或者linux上执行
echo “E8B4A2E58AA1E983A8” | xxd -r -p
3 个赞
没看懂是什么意思
1 个赞
可以加我一下吗
1 个赞
不好意思 不加微信
1 个赞
做了备份就可以恢复吧
2 个赞
现在不知道OB的十六制编码规则
1 个赞
问题是dump出来的不是也已经是drop后的数据文件了么
2 个赞
|ROW[59]:trans_id=[{txid:0}],dml_flag=[N|UPDATE],mvcc_flag=[]|[{“BIGINT”:1}][{“BIGINT”:0}][{“VARCHAR”:"", collation:“utf8mb4_general_ci”, coercibility:“INVALID”}][{“BIGINT”:-1782823812113341652}][{“BIGINT”:0}][NOP][{len: 8, flag: 0, null: 0, hex: 91A0040478550600, int: 1782823812112529}][NOP][{len: 8, flag: 0, null: 0, hex: AA9C20A6CFDCBD18, int: 1782823811912080554}][{len: 8, flag: 0, null: 0, hex: AA9C20A6CFDCBD18, int: 1782823811912080554}]
这种数据，谁解析过？
1 个赞
可以先按照这样看看是否能解析linux上可以执行
echo “E8B4A2E58AA1E983A8” | xxd -r -p
比如echo " AA9C20A6CFDCBD18" | xxd -r -p
该串是业务二进制 ID / 分片哈希，不是中文文本编码，无法解码出汉字。
应该不是中文 是个数字
列0: BIGINT=1 → 可能是多版本表的版本列
列1: BIGINT=0
列2: VARCHAR="" → 空字符串
列3: BIGINT=-1782823812113341652 → 可能是 rowkey 的一部分
列4: BIGINT=0
列5: NOP → UPDATE 时未修改
列6: hex→1782823812112529 → 被修改的列
列7: NOP
列8/列9: hex→1782823811912080554（相同）→ 可能是时间戳类列
也可以参考一下这个帖子
两个值
int: 1782823812112529
int: 1782823811912080554
看有共同的组成 178282381，后面 2112529、1912080554不知道分别对应多少
不知道这里是怎么编码的
你这个是不是输出也是十六进制和十进制？
又上一课，rm/drop这类操作前，必备份。
同事的锅让他自己背吧。数据怎么找回来，没备份的话，最好让应用层想办法。
删库的下一步动作是跑路
91A0040478550600 编码过来就是1782823812112529
AA9C20A6CFDCBD18 编码过来就是1782823811912080554
1782823812112529、1782823811912080554可能是时间类型的值
第一个是微秒 第二个是纳秒 主要没有具体的列类型 不好判断
666
学习下
DROP 库又重建同名库这种情况，回收站一般也救不回来。最靠谱的是先看有没有物理备份或 OMS/备库，用备份恢复到误删之前的时间点。直接用 ob_admin 解析宏块二进制成本很高、也容易出错，不建议作为首选。如果数据很重要，建议尽快联系 OceanBase 官方支持，同时先停止往这块盘写数据，避免宏块被覆盖。
1 个赞