【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】
【操作系统】
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
各位大神，从Oracle迁移到TiDB,大量的存储过程你们是怎么处理的？
改成应用代码实现
1 个赞
这个事情要分开看，
- 旧的业务搬迁
- 新的业务构建，来代替旧的
- 新旧交替
要根据实际的情况来制定策略了，并不是看代码和写代码那么简单了。
存储过程一般都是几万行的哪种，可以看哭～ 建议用 AI 进行分析了…
2 个赞
tidb支持存储过程吗
企业版支持
不支持
企业版支持，社区版本不支持
应用层面来实现，研发来改造，对dba来说没有压力。。存储过程很多坑。。查询锁问题，很头疼。。。
那DBA基本失业了
能提供一份企业版的说明文档吗
- 企业版本支持
- 有企业级工具提供改造方法。
https://www.pingcap.cn/
强烈建议上线企业版。
或者跟我们一样，把存储过程都翻译到应用程序里。
这样基本都是开发来做了。调优啥的只能从代码层去做，基本不需要DBA做了。几千行的存储过程看着都头晕，要一一转换成JAVA，头疼
是的，我们当时改了小半年才改完。
业务代码重构，然后一部分一部分业务迁移过去
不支持oracle的存储过程，只能应用层重新编写。
存储过程，你要重写了。两个不同结构数据库，表你把oracle 迁移到 tidb说实，有些字符集和数据结构，能保持是很好，但存储过程，大家区别很大，如果能迁移。为什么你要放弃oracle 。oracle 是最适合使用那些存储过程，生产环境那有一家公司会这样，没有事自己找事来做。所以，这个迁移。是生产环境 ，目前根本不会有企业进行，只是一个设想模似。
都改成应用逻辑实现，去掉存储过程，工作量不就来了吗。。。
存储过程局限性太高，还是写在业务中较好