sql >> Database teknologi >  >> RDS >> Oracle

JDBC med Spring langsomme metadata henter Oracle

Efter at have omvendt den faktiske kommunikation mellem klient og server kan jeg afsløre, at Oracles DatabaseMetaData.getColumns()-metoder sender følgende SQL-forespørgsel (selvom dette kan ændre sig med ODBC-driverversioner og -indstillinger):

    declare
    in_owner varchar2(128);
    in_name varchar2(128);
    in_column varchar2(128);
    xyzzy SYS_REFCURSOR;
    begin
    in_owner := :1;  // Which resolves to the schema (user) name supplied
    in_name := :2;   // Which resolves to the table name supplied
    in_column := :3; // Which gets set to '%';
    open xyzzy for
    SELECT NULL AS table_cat,
        t.owner AS table_schem,
        t.table_name AS table_name,
        t.column_name AS column_name,
    DECODE(  (SELECT a.typecode
        FROM ALL_TYPES A
        WHERE a.type_name = t.data_type),
    'OBJECT', 2002,
    'COLLECTION', 2003,
    DECODE(substr(t.data_type, 1, 9),
        'TIMESTAMP',
        DECODE(substr(t.data_type, 10, 1),
            '(',
            DECODE(substr(t.data_type, 19, 5),
                'LOCAL', -102, 'TIME ', -101, 93),
            DECODE(substr(t.data_type, 16, 5),
            'LOCAL', -102, 'TIME ', -101, 93)),
        'INTERVAL ',
        DECODE(substr(t.data_type, 10, 3),
        'DAY', -104, 'YEA', -103),
        DECODE(t.data_type,
        'BINARY_DOUBLE', 101,
        'BINARY_FLOAT', 100,
        'BFILE', -13,
        'BLOB', 2004,
        'CHAR', 1,
        'CLOB', 2005,
        'COLLECTION', 2003,
        'DATE', 93,
        'FLOAT', 6,
        'LONG', -1,
        'LONG RAW', -4,
        'NCHAR', -15,
        'NCLOB', 2011,
        'NUMBER', 2,
        'NVARCHAR', -9,
        'NVARCHAR2', -9,
        'OBJECT', 2002,
        'OPAQUE/XMLTYPE', 2009,
        'RAW', -3,
        'REF', 2006,
        'ROWID', -8,
        'SQLXML', 2009,
        'UROWI', -8,
        'VARCHAR2', 12,
        'VARRAY', 2003,
        'XMLTYPE', 2009,
        1111)))
    AS data_type,
        t.data_type AS type_name,
        DECODE (t.data_precision, null,
            DECODE(t.data_type, 'NUMBER',
                DECODE(t.data_scale, null, 0 , 38),
                    DECODE (t.data_type, 'CHAR', t.char_length, 'VARCHAR', t.char_length, 'VARCHAR2', t.char_length, 'NVARCHAR2', t.char_length, 'NCHAR', t.char_length, 'NUMBER', 0, t.data_length) ), t.data_precision)
        AS column_size,
        0 AS buffer_length,
        DECODE (t.data_type, 'NUMBER', DECODE(t.data_precision, null, DECODE(t.data_scale, null, -127 , t.data_scale), t.data_scale), t.data_scale) AS decimal_digits,
        10 AS num_prec_radix,
        DECODE (t.nullable, 'N', 0, 1) AS nullable,
        NULL AS remarks,
        t.data_default AS column_def,
        0 AS sql_data_type,
        0 AS sql_datetime_sub,
        t.data_length AS char_octet_length,
        t.column_id AS ordinal_position,
        DECODE (t.nullable, 'N', 'NO', 'YES') AS is_nullable,
        null as SCOPE_CATALOG,
        null as SCOPE_SCHEMA,
        null as SCOPE_TABLE,
        null as SOURCE_DATA_TYPE,
        'NO' as IS_AUTOINCREMENT,
        t.virtual_column as IS_GENERATEDCOLUMN
    FROM all_tab_cols t
    WHERE t.owner LIKE in_owner ESCAPE '/'
    AND t.table_name LIKE in_name ESCAPE '/'
    AND t.column_name LIKE in_column ESCAPE '/'
    AND t.user_generated = 'YES'
    ORDER BY table_schem, table_name, ordinal_position;
    end;

Du kan forstå, hvorfor det kan være lidt langsomt, især da ALL_TAB_COLS- og ALL_TYPES-tabellerne hver kan være 1000-vis af poster lange. Ikke desto mindre, mens Oracle kæmper for at udføre den første påkaldelse nogensinde (minutter), returnerer efterfølgende opkald resultater næsten øjeblikkeligt. Dette er et klassisk table-join-ydeevneproblem, hvor selv om en delmængde af data er påkrævet, forbinder motoren hele datasættet før beregne og levere den nødvendige delmængde. Efterfølgende data-/resultatcache arbejder for at forbedre ydeevnen af ​​efterfølgende forespørgsler.

Den bedre løsning kan være at bruge get_ddl() og parse den returnerede tabeldefinition som pr. denne tråd .

Alternativt du kan muligvis forespørge om metadataene på en tabel hurtigere ved at udføre en dummy-forespørgsel og derefter bruge resultSetMetadata som følger (Bemærk:kolonnebemærkninger, metadata er muligvis ikke umiddelbart tilgængelige):

    ResultSet rs = connection.CreateStatement.executeQuery("SELECT * from MyTable WHERE 1=0");
    ResultSetMetaData md = rs.getMetaData();
    for (int ix = 1; ix <= md.getColumnCount(); ix++)
    {
      int colSize = md.getPrecision(ix);
      String nativeType = md.getColumnTypeName(ix);
      int jdbcType = md.getColumnType(ix);
      // and so on....
    }


  1. MySQL langsom forespørgsel - Venter på forespørgselscachelås

  2. Grupper for uge i MySQL

  3. Løndatamodel

  4. SQL Server 2005:diskplads optaget af droppede kolonner