PL/SQL 解析器识别对表的操作
我正在编写一个 PL/SQL 解析器来识别当我运行过程、函数或包时在表上执行的操作(选择、插入、删除)。
目标:I 该工具的目标是确定运行该过程将影响哪些所有表,准备更好的测试用例很有趣。
任何更好的想法或工具都会有很大帮助。
输入: 一些需要过程
or proc file.
OUTPUT 的 SQL 文件是:
SELECT from: First_table, secondaryTable
->在过程 XYZ 中 -- 这是如果该过程正在调用另一个过程
INSERT into: SomeTable
INSERT into: SomeDiffTable
->程序 XYZ 结束 -- 又一个程序结束。
删除:xyzTable
插入:OnemoreTable
我的要求是当我解析 porc1 时,如果它调用另一个 proc2。我必须进入 proc2 内部,找出其中执行的所有操作,然后返回 proc1 并继续。:
为此,我必须将所有过程存储在某个位置,并且在解析时我必须检查每个标记(单词与space) 中的 tempStorage 来查明它是否是过程。
因为我的逻辑需要很多时间。任何人都可以提出更好的逻辑来实现我的目标吗?
I am writing a PL/SQL parser to identify the operations(Select,Insert,Delete) performed on the Table when I run Procedure, Function or Package.
GOAL:I Goal of this tool is to identify which all the tables will be affected by running the procedure,Fun to prepare with better test case.
Any better ideas or tool will really help a lot.
INPUT:
some SQL file with procedure
or proc file.
OUTPUT required is:
SELECT from: First_table, secondTable
-> In procedure XYZ --This is if the procedure is calling one more procedure
INSERT into: SomeTable
INSERT into: SomeDiffTable
-> END of procedure XYZ --End of one more procedure.
DELETE from: xyzTable
INSERT into: OnemoreTable
My requirement is When I am parsing porc1 if it calls another proc2. I have to go inside that proc2 to find out what all the operation is performed in that and come back to proc1 and continue.:
For this I have to store the all procedure some where and while parsing I have to check each token(word with space) in the tempStorage to find out if it is procedure or not.
As my logic's takes lot of time. Can any body suggest better logic to achieve my GOAL.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
也有可能涉及触发器。这又增加了一层复杂性。
我想说你最好使用递归查询来挖掘 DBA_DEPENDENCIES 来确定抽象的影响分析;它不会捕获动态 SQL,但没有什么能 100% 成功。在您的情况下,proc1 取决于 proc2,而 proc2 又取决于它所依赖的任何内容,依此类推。它不会告诉您依赖关系的本质 - INSERT、UPDATE、DELETE、SELECT - 但这是一个开始。
如果您确实有兴趣确定程序的单变量值运行的实际影响,请在非生产系统中实现它,然后将系统审核级别提高到 11:
运行测试,看看会发生什么执行过程中通过挖掘审计线索来触及对象。它不是万无一失的,因为它只审核被该执行触及的对象,但它确实告诉您它们是如何被触及的。
There's also the possiblity of triggers being involved. That adds an additional layer of complexity.
I'd say you're better off mining DBA_DEPENDENCIES with a recursive query to determine impact analysis in the abstract; it won't capture dynamic SQL, but nothing will 100% of the time. In your case, proc1 depends on proc2, and proc2 depends on whatever it depends on, and so forth. It won't tell you the nature of the dependency - INSERT, UPDATE, DELETE, SELECT - but it's a beginning.
If you're really interested in determining the actual impact of a single-variable-value run of a procedure, implement it in a non-production system, and then turn auditing on your system up to 11:
Run your test, and see what objects got touched as a result of the exectution by mining the audit trail. It's not bulletproof, as it only audits objects that got touched by that execution, but it does tell you how they got touched.