谁想到了术语"DIANA节点"?他们如何看待6,000,000个LOC大约是67108864(2 ** 26)个DIANA节点? [英] Who came up with the term "DIANA node" and how did they figure 6,000,000 LOC is approximately 67108864 (2**26) DIANA nodes?

问题描述

在共享内存池中，包规格，对象类型规格， 独立子程序或匿名块限制为67108864 (2 ** 26)个与令牌(例如标识符)相对应的DIANA节点， 关键字，运算符等.

In the shared memory pool, a package spec, object type spec, standalone subprogram, or anonymous block is limited to 67108864 (2**26) DIANA nodes which correspond to tokens such as identifiers, keywords, operators, and so on.

DIANA代表什么?我知道完整的表格.但是实际上是什么?

What does DIANA stand for? I know the full form. But what is it actually?

我已经介绍过 谁是戴安娜王妃，为什么会获奖?她让我的数据库对象编译吗? 因此请勿将其标记为重复.

I already referred Who is diana, and why won't she let my database objects compile? so don't mark this as duplicate.

我想知道这个概念是什么，谁创造了这个名词，等等.如果可能的话，他们如何告诉我们. 除非您超出PL/SQL编译器施加的限制，否则这将允许约6,000,000行代码"，它们如何达到该值?

I want to know what this concept is, who coined this term etc,.. And if possible how they tell us. "This allows for ~6,000,000 lines of code unless you exceed limits imposed by the PL/SQL compiler", how do they arrive at that value?

推荐答案

按照 Oracle文档，

PL/SQL基于编程语言Ada. PL/SQL使用Ada描述性中间属性表示法(DIANA)的一种变体，即树状结构中间语言. 它使用称为接口定义语言(IDL)的元符号定义. 编译器和其他工具在内部使用DIANA.

PL/SQL is based on the programming language Ada. PL/SQL uses a variant of Descriptive Intermediate Attributed Notation for Ada (DIANA), a tree-structured intermediate language. It is defined using a meta-notation called Interface Definition Language (IDL). DIANA is used internally by compilers and other tools.

在编译时，PL/SQL源代码被转换为机器可读的m代码. 过程或程序包的DIANA代码和m代码都存储在数据库中. 在运行时，它们被加载到共享内存池中. DIANA用于编译相关程序.只需执行m代码即可.

At compile time, PL/SQL source code is translated into machine-readable m-code. Both the DIANA and m-code for a procedure or package are stored in the database. At run time, they are loaded into the shared memory pool. The DIANA is used to compile dependent procedures; the m-code is simply executed.

不幸的是，您无法从解析的大小估算出DIANA节点的数量. 具有相同解析大小的两个程序单元可能需要1500个和2000个DIANA节点， 分别是因为第二个单元包含更复杂的SQL语句.

Unfortunately, you cannot estimate the number of DIANA nodes from the parsed size. Two program units with the same parsed size might require 1500 and 2000 DIANA nodes, respectively because, for example, the second unit contains more complex SQL statements.

问汤姆说

有关DIANA节点计算的更多信息，请阅读这本书"Ada-Europe '93:第12届Ada-Europe国际会议，"Ada Sans Frontieres"，1993年6月14日至18日，法国巴黎. strong>

More on DIANA node calcualtions, read this book "Ada-Europe '93: 12th Ada-Europe International Conference, "Ada Sans Frontieres", Paris, France, June 14-18, 1993. Proceedings"

以下支持说明很好地涵盖了该主题...

The following support note covers this topic well...

Article-ID:         <Note:62603.1>
Folder:             PLSQL
Topic:              General Information Articles
Title:              'PLS-123 Program too Large' - Size Limitations on PLSQL 
                    Packages
Document-Type:      BULLETIN
Impact:             MEDIUM
Skill-Level:        NOVICE
Server-Version:     07 to 08
Updated-Date:       13-JUN-2000 17:41:01
References:         

概述

本文包含有关PL/SQL软件包大小限制的信息.当极限 到达时，您会收到以下错误:

Overview

This article contains information on PL/SQL package size limitations. When limits are reached, you receive the following error:

PLS-123 Program too large

PL/SQL软件包的大小限制

在8.1.3之前的版本中，大型程序导致PLS-123错误.这发生了 由于编译器的真正限制；不是由于错误引起的.

Size Limitations on PL/SQL Packages

In releases prior to 8.1.3, large programs resulted in the PLS-123 error. This occurred because of genuine limits in the compiler; not as a result of a bug.

编译PL/SQL单元时，编译器会构建一个解析树.最大尺寸 PL/SQL单位由解析树的大小确定.最大diana节点数 在这棵树中.

When compiling a PL/SQL unit, the compiler builds a parse tree. The maximum size of a PL/SQL unit is determined by the size of the parse tree. A maximum number of diana nodes exists in this tree.

直到7.3，您可能有2 * * 14(16K)个diana节点，从8.0到8.1.3，2 * * 15(32K) 戴安娜节点是允许的.在8.1.3中，此限制已放宽，因此您现在可以 该树中有2 * * 26(即64M)个diana节点，用于封装和类型主体.

Up to 7.3, you could have 2 * * 14 (16K) diana nodes, and from 8.0 to 8.1.3, 2 * * 15 (32K) diana nodes were allowed. With 8.1.3, this limit has been relaxed so that you can now have 2 * * 26 (i.e., 64M) diana nodes in this tree for package and type bodies.

虽然没有简单的方法可以转换源代码行中的限制，但我们观察到，每行源代码大约有5到10个节点.在8.1.3之前，编译器可以干净地编译多达3,000行代码.

While there is no easy way to translate the limits in terms of lines of source code, it has been our observation that there have been approximately 5 to 10 nodes per line of source code. Prior to 8.1.3, the compiler could cleanly compile up to about 3,000 lines of code.

从8.1.3开始，放宽了对封装主体和类型主体的限制，这些封装主体和类型主体现在可以具有大约多达6,000,000行代码.

Starting with 8.1.3, the limit was relaxed for package bodies and type bodies which can now have approximately up to about 6,000,000 lines of code.

注意:此新限制仅适用于包主体和类型主体.另外，在达到此特定的编译器限制之前，您现在可以开始达到其他一些编译器限制.

Notes: This new limit applies only to package bodies and type bodies. Also, you may now start hitting some other compiler limits before you hit this particular compiler limit.

就源代码大小而言，假定令牌(标识符，运算符，函数等)平均长度为四个字符.然后，最大值将是:

In terms of source code size, assume that tokens (identifiers, operators, functions, etc.), are on average four characters long. Then, the maximum would be:

   Up to 7.3:         4 * (2 * * 14)=64K
   From 8.0 to 8.1.3: 4 * (2 * * 15)=128K
   With 8.1.3:        4 * (2 * * 25)=256M

这是一个粗略的估计.如果您的代码包含很多空格，长标识符等，则可能 最终得到的源代码比这大.您可能还会得到较小的源代码 如果您的来源使用非常短的标识符等，则可以做到这一点.

This is a rough estimate. If your code has many spaces, long identifiers, etc., you may end up with source code larger than this. You may also end up with source code smaller than this if your sources use very short identifiers, etc.

请注意，这是按程序单位进行的，因此程序包主体最有可能遇到此问题 限制.

Note that this is per program unit, so package bodies are most likely to encounter this limit.

要检查包裹的尺寸，可以使用的最接近的相关编号是 数据字典视图USER_OBJECT_SIZE.此值提供DIANA的大小，以 存储在SYS.IDL_xxx $表中的最大字节数，而不是共享池中的大小.

To check the size of a package, the closest related number you can use is PARSED_SIZE in the data dictionary view USER_OBJECT_SIZE. This value provides the size of the DIANA in bytes as stored in the SYS.IDL_xxx$ tables and is NOT the size in the shared pool.

PL/SQL代码的DIANA部分(在编译期间使用)的大小在 共享池比系统表中的共享池多.

The size of the DIANA portion of PL/SQL code (used during compilation) is MUCH bigger in the shared pool than it is in the system table.

例如，当PARSED_SIZE在 USER_OBJECT_SIZE不超过50K.

For example, you may begin experiencing problems with a 64K limit when the PARSED_SIZE in USER_OBJECT_SIZE is no more than 50K.

对于包，解析的大小或DIANA的大小仅对整个包有意义 对象，而不是单独针对规格和主体.

For a package, the parsed size or size of the DIANA makes sense only for the whole object, not separately for the specification and body.

如果您为程序包选择parsed_size，则会收到单独的源代码大小和代码大小 规范和正文，但对于整个对象而言，只有有意义的解析大小， 在包装规格行上输出. parsed_size的输出为0 在包装体的线上.

If you select parsed_size for a package, you receive separate source and code sizes for the specification and body, but only a meaningful parsed size for the whole object which is output on the line for the package specification. A 0 is output for the parsed_size on the line for the package body.

下面的示例演示了这种行为:

The following example demonstrates this behaviour:

CREATE OR REPLACE PACKAGE example AS  
  PROCEDURE dummy1;  
END example;  
/  
CREATE OR REPLACE PACKAGE BODY example AS  
  PROCEDURE dummy1 IS  
  BEGIN  
    NULL;  
  END;  
END;  
/  

SQL> start t1.sql;  

Package created.  


Package body created.  

SQL> select parsed_size from user_object_size where name='EXAMPLE';  


PARSED_SIZE  
-----------  
        185  
          0  


SQL> select * from user_object_size where name='EXAMPLE';  

  .....

Oracle将DIANA和MCODE都存储在数据库中. MCODE是实际运行的代码， 而特定库单元X的DIANA包含 使用库单元X编译过程.

Oracle stores both DIANA and MCODE in the database. MCODE is the actual code that runs, while DIANA for a particular library unit X contains information that is needed to compile procedures using library unit X.

以下是一些注意事项:

a)DIANA以IDL表示. IDL的线性版本存储在磁盘上.这 实际的分析树已构建并存储在共享池中.这就是为什么 共享池中的DIANA通常大于磁盘上的DIANA.

a) DIANA is represented in IDL. The linear version of IDL is stored on disk. The actual parse tree is built up and stored in the shared pool. This is why the size of DIANA in the shared pool is typically larger than on disk.

b)仅当您创建共享池时，才需要共享池中用于被调用过程的DIANA 程序.在生产系统中，共享池中不需要DIANA (但仅适用于MCODE).

b) DIANA for called procedures is required in the shared pool only when you create procedures. In production systems, there is no need for DIANA in the shared pool (but only for the MCODE).

c)从7.2版开始，包装体的DIANA被丢弃，不再使用， 而不是存储在数据库中.这就是为什么PARSED_SIZE(即DIANA的大小)为 包实体为0.

c) Starting with release 7.2, the DIANA for package bodies is thrown away, not used, and not stored in the database. This is why the PARSED_SIZE (i.e. size of DIANA) of PACKAGE BODIES is 0.

因此，应始终定义大型过程和功能 在包装内！

Therefore, large procedures and functions should always be defined within packages!

与过程一样，程序包也存储在数据库中的DIANA中.一个包可以用来 但是打破了依赖链，也许可以消除这种依赖.我相信所有 生产(实际)代码应放在程序包中，而不是在独立的过程或函数中.

A package is stored in DIANA in the database, just like a procedure. A package can be used to break the dependency chain however, perhaps making this go away. It is my belief that ALL production (real) code should be in a package, never in a standalone procedure or function.

这篇关于谁想到了术语"DIANA节点"?他们如何看待6,000,000个LOC大约是67108864(2 ** 26)个DIANA节点?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！