Cómo ajustar la longitud máxima de la entrada de sentencia SQL en Oracle
La longitud de la declaración SQL de Oracle no debe exceder 1000
El número máximo de LISTAS en la cláusula IN es 1000. Si excede este número, se informará un error A. La longitud de caracteres del texto de la declaración CREATE TRIGGER no puede exceder los 32 KB (los tipos LONG, LONG RAW no se pueden usar en los activadores; se puede hacer referencia a los valores de las columnas de tipo LOB en los activadores, pero los datos en las columnas LOB no se pueden modificar a través de: NUEVO;) Por cierto, ahora la palabra clave PARENT en el disparador solo es válida en los disparadores de tablas anidadas. Antes de 11G, la longitud del SQL de entrada de DBMS_SQL no puede exceder los 32 K. El parámetro solo puede ser de tipo VARCHAR2. Después de 11G, CLOB se puede usar como La introducción de parámetros cancela esta restricción. El tamaño máximo de un paquete, procedimiento, función y activador de PL/SQL es 64 K en UNIX y 32 K en WINDOWS (32 K deben). no es exacto, vea la prueba a continuación) SQL ¿Cuánto tiempo puede tener una declaración? (Un internauta dijo) El documento ORACLE dice que es 64K. De hecho, puede ser menor que este valor debido a las limitaciones de algunas herramientas. Lo probé y descubrí que puede ser muy largo, incluso más de 1 M (he probado 170 K y no hay problema). La longitud específica de 10G no se especifica, pero está relacionada con muchos entornos: configuración de la base de datos, espacio en disco y cantidad de memoria. . .
En PL/SQL, la longitud de la expresión/SQL en sí puede alcanzar una longitud relativamente larga (50 K), como por ejemplo: v_str:=:new.f1||:ndw.f2. . . ; seleccione :nuevo.f1||:nuevo.f2. . . en v_str desde dual; También se encuentra, si escribe así: v_str := 'a'||'b'||. . . La longitud de expresión permitida se reducirá considerablemente. Si la expresión/SQL es demasiado larga y excede la longitud máxima del programa permitida por un paquete/procedimiento ORACLE, se producirá un error pls-123: programa demasiado grande durante la compilación. Esto se debe a las limitaciones del propio compilador pl/sql. es decir, la longitud de la expresión /SQL está limitada en PL/SQL por el tamaño máximo del paquete/procedimiento ============================ ======= =================Problema y solución del límite de longitud de la declaración SQL de Oracle
Al escribir declaraciones SQL recientemente, encontré dos problemas:
1) ORA-01795: el número máximo de expresiones en una lista es 1000 Causa: Escribí una declaración SQL como esta: SELECT PALLET_ID,BOX_ID,STATUS FROM SD_CURRENT_BOX WHERE PALLET_ID IN('"+pallets+"'); donde pallets Es una cadena compuesta por muchos pallet_ids.
Análisis: Evidentemente, según el mensaje de error, podemos saber: el límite de elementos en in es 1000.
Solución: utilizar subconsulta para reemplazar la larga cadena de paletas.
2) ORA-01704: cadena literal demasiado larga
Causa: Declaración SQL escrita como esta: UPDATE PDM_MEMBERLIST SET MEMBERS='
Análisis: El campo MIEMBROS del diseño de la base de datos está en formato tipo xml y, cuando se almacenan los datos, se almacenan en forma de cadenas. De esta manera, cuando la cantidad de datos xml es grande, la instrucción SQL es demasiado larga y se excede el límite de 2k.
Solución: sentencia sql parametrizada.
============================================ === =======Declaraciones SQL parametrizadas----Prevención de ataques de inyección SQL (Parte 2)
Originalmente se planeó que los principios básicos de la inyección SQL escritos en el artículo anterior fueran seguidos por Este artículo, pero por razones de tiempo, nunca terminé de escribir. Hoy es el feriado del Primero de Mayo, así que finalmente encontré tiempo para escribir.
Como programadores, somos la primera línea de defensa contra la inyección SQL. Siempre que dejemos algunas lagunas en el programa, las características de seguridad del programa mejorarán. Entonces, lo que tenemos que hacer es escribir un programa seguro para evitar la inyección de SQL en el programa. Ahora no empalme cadenas de SQL. Debe parametrizar SQL o escribir un procedimiento almacenado aquí.
En el ejemplo, se utilizan C# y Oracle para implementarlo. La implementación en Java u otras bases de datos también es similar.
usando System.Data.OracleClient;//Introducir el paquete de operaciones de Oracle//Definir la declaración DML
string strSQL = @"select user.name from user donde user.name =:userName ";// En la oración anterior: nombre de usuario es el marcador de posición para el parámetro en la declaración SQL. Es decir, cuando esta declaración SQL se ejecuta en el servidor de la base de datos, este marcador de posición será reemplazado por otra cosa. ¿Cuál debería ser? reemplazado con? Bueno, entonces mira hacia abajo OracleParameter[] param = {
new OracleParameter(":userName",txtName);}//Aquí se define una matriz de parámetros, en la que se pueden colocar múltiples parámetros sql. escrito Aquí solo hay uno, así que simplemente escriba un parámetro Aquí, el marcador de posición corresponde a su reemplazo, es decir, el valor del parámetro txtName es el valor de reemplazo del marcador de posición. La interfaz de usuario puede contener caracteres para ataques de inyección, ahora el servidor de la base de datos sabe con qué reemplazar los marcadores de posición.
Después de definir la instrucción SQL y los parámetros, se ejecuta. Durante la ejecución, la instrucción SQL y los parámetros deben pasarse al mismo tiempo, de modo que las cadenas con caracteres ilegales ingresadas por el usuario sean. tratados como parámetros en la base de datos, no se confundirán con los caracteres de la declaración SQL y la propia base de datos, evitando ataques de inyección.
OracleCommandcmd = new OracleCommand();
cmd.CommandText= strSQL;//Definir el contenido de texto del comando de Oracle para(oracleParameter p in param)//Pasar los parámetros a {
cmd.Parameters.Add(p);
}
cmd.ExecuteNonQuery();//Ejecutar el comando
Básicamente, lo anterior es un SQL parametrizado completo. Los diferentes servidores de bases de datos tienen diferentes marcadores de posición en la declaración SQL. El marcador de posición del parámetro es dos puntos (:) más un nombre. Se utiliza un marcador de posición, y en MySQL, se utiliza un signo de interrogación (?) más un nombre como marcador de posición de parámetro. Los símbolos de los parámetros en diferentes bases de datos son diferentes, por lo que debe prestar atención a esto.
Prevención de ataques de inyección SQL (Parte 1)
La inyección SQL es un método de ataque de entrada extremadamente baja y extremadamente dañino. Si el SQL está empalmado con cadenas, definitivamente será atacado por inyección Hace algún tiempo, se informó que un gran sitio de redes sociales extranjero fue atacado por inyección de SQL.
Los camaradas que vienen aquí para ver el método de ataque de inyección SQL deben ser muy claros al empalmar cadenas, si la entrada está entre comillas simples, entonces ingrese laf'or 1='1 '--Esto será. evadir la verificación de condiciones, si va seguida de algunas condiciones como apagar y eliminar, la pérdida será básicamente devastadora.
Durante el proceso de desarrollo de la unidad hace unos días, descubrí que casi todos no prestan atención a la seguridad. Si una persona que escribe código no presta atención a la seguridad y solo presta atención a la implementación, el código que escribe básicamente se verá. como una hermosa mujer sin ropa frente al atacante.
La siguiente es una experiencia de uno de mis desarrolladores, utilizada principalmente para prevenir la inyección de SQL.
1. Primero, otorgue privilegios mínimos al usuario que ejecuta sql. Esta teoría es también la teoría de privilegios mínimos en el campo de la seguridad. Un programa debe ejecutarse con privilegios mínimos, por lo tanto, no le dé al usuario privilegios de DBA. Las limitaciones deben ser Después de los permisos, puede evitar algunos ataques devastadores. Incluso si ingresa, no se le cerrará para modificar la tabla o cosas similares.
2. No utilice empalme de cadenas para construir sql. Debe utilizar sql parametrizado. Los procedimientos almacenados se pueden considerar como parámetros sql. Para los simples, simplemente construya sql parametrizado. , pero no debes usar cadenas en procedimientos almacenados. He visto a algunas personas usar cadenas en procedimientos almacenados. Esto aún no puede evitar ser atacado y es muy problemático durante la depuración.
3. Controle estrictamente la entrada. El sistema debe usarse para la interacción. Todas las entradas del usuario deben controlarse adecuadamente. Se pueden utilizar varios métodos para verificar la entrada del usuario para garantizar que sea legal. Puede configurar caracteres confidenciales para evitar que los usuarios los ingresen. Aunque esto no es muy fácil de usar, garantiza la seguridad. Para la verificación, puede utilizar expresiones regulares o verificación de programa. No importa qué método se utilice, siempre que se excluyan los caracteres confidenciales y sospechosos, no se podrán realizar ataques. Sin embargo, limitar la entrada sigue siendo defectuoso en términos de teoría de seguridad. Solo se puede determinar si es legal, pero no se puede determinar si es ilegal. Por ejemplo, si restringe las entradas legales en la interfaz, el resto son ilegales. En este momento, todas las entradas deben ser legales. Si lo que restringes es ilegal, puedes asegurarte de que todas las restricciones que hagas sean ilegales. Si un día encuentras uno ilegal que ya no está dentro de tus límites, serás atacado.
4. Realice su propio trabajo de inspección y prueba. Puede realizar ataques de inyección SQL usted mismo y utilizar herramientas para comprobarlo.
5. Debemos desarrollar programadores conscientes de la seguridad y pensar siempre en la seguridad.
Los más importantes son 1 y 2. Debe prestar atención a las restricciones de permisos, de lo contrario morirá miserablemente. El segundo es el hábito de los programadores: debe utilizar SQL parametrizado y la interacción de la base de datos.