在 OceanBase 運維過程中，你是否遇到過這樣的場景：執行存儲過程或查詢含 LOB 列的表時，突然拋出 ORA-00600: internal error code, arguments: -4067, RPC session not found 錯誤？導致 SQL 執行失敗、表級恢復任務卡住？ 今天這篇文章，就為大家深度剖析這個報錯背後的“元兇”——流式 R
“明明給字段建了索引，可帶函數的查詢還是走全表掃描，數據量大了直接卡到超時……” 如果你在使用 OceanBase 或 MySQL 時遇到過這種問題，大概率是沒用到函數索引！當查詢條件包含函數計算（比如LOWER(name)、MD5(customer_id)）時，普通索引完全失效，而函數索引能直接基於計算結果建立索引，讓查詢效率飆升10倍+！ 今天這篇乾貨，從定義、用
在數字化轉型浪潮席捲各行各業的今天，數據已成為企業的核心資產。而數據庫作為數據的承載基石，其性能、可擴展性、穩定性和成本效益，直接關係到企業業務的敏捷性與未來發展。許多企業最初選擇開源MySQL數據庫，是因其簡單易用、生態豐富而備受青睞，但隨着業務規模的飛速擴張，MySQL在面臨海量數據、高併發事務及分佈式部署等場景時，常常在擴展性、容災能力和運營成本上遇到瓶頸。 Ocea
在 OceanBase 數據庫運維中，創建索引是高頻操作之一，尤其面對海量數據時，索引構建可能持續數小時甚至更久。實時掌握建索引進度、判斷當前所處階段，不僅能避免運維人員盲目等待，更能及時發現異常並介入處理。 本文基於 OceanBase 2.2.77 版本，從索引創建的核心階段出發，結合系統表查詢實戰，帶大家全方位監控建索引全流程。 一、OceanBase 建索引的
在 OceanBase 數據庫運維中，最讓人頭疼的場景莫過於：一條看似普通的業務 SQL，突然執行超時，前端直接報錯，而你盯着 SQL 和執行計劃，一時找不到突破口。 問題描述 最近技術部門就處理了一起典型案例：應用側反饋某核心業務 SQL 執行 900s 仍無結果，前端應用直接報查詢超時。經過排查與優化，最終將執行時間壓縮至 2-5s，效率提升超 180 倍！今天就
OceanBase 數據庫中Oracle 租户PLSQL 調優的關鍵第一步，就是找到藏在程序包、存儲過程裏的慢 SQL。尤其是遇到嵌套調用的場景，手動排查堪比大海撈針。今天分享2個實戰方法，幫你快速發現問題 SQL，為後續調優節省時間！ 一、DBMS_PROFILER 逐行追蹤，鎖定存過內慢 SQL 位置 DBMS_PROFILER 是 Oracle 自
問題描述 在 Oracle 數據庫遷移至 OceanBase 4.2.1 Oracle 租户的過程中，不少研發同學會遇到 SQL 兼容性問題。最近技術部門反饋，一條SQL在Oracle中查詢正常，OceanBase 中查詢報錯ORA-01722: invalid number，表字段是VARCHAR2類型，使用regexp_like
