ALTER TABLE RECORDINGS ADD PRIMARY KEY (ID);

CREATE MATERIALIZED VIEW LOG ON RECORDINGS TABLESPACE USERS NOLOGGING;

DROP MATERIALIZED VIEW REC_SEARCH_TEST;
CREATE MATERIALIZED VIEW REC_SEARCH_TEST
REFRESH COMPLETE ON COMMIT
AS (
    SELECT DISTINCT ID, TITLE FROM RECORDINGS
);


ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view

No puede comprender lo que está mal aquí, yo sé que si me saco la cláusula DISTINCT funciona, pero ¿por qué no puedo utilizar ‘DISTINTOS’ si puedo especificar de «ACTUALIZACIÓN COMPLETA DE COMETER» que se requiere.

Si puedo usar DISTINTOS y ACTUALIZAR en la demanda no hay ningún problema, pero estos no son los requisitos.

  • Usted tiene un índice único. No hay necesidad para las distintas así que ¿por qué molestarse?
  • Tal vez el ejemplo no es la mejor, porque quiero ampliar la vista a una más complicado de consulta, que requerirá de una palabra clave distinct, ahora mismo solo estoy tratando de que funcione en un nivel básico.
  • El DISTINCT no tiene ningún sentido en absoluto. El ID en la columna seleccionar hará que todas las filas a ser distinto siempre.
InformationsquelleAutor Moz | 2012-01-16

3 Comentarios

  1. 2

    Parece que con la adición de los DISTINTOS, han hecho de la vista SQL subyacente inelegible para la actualización rápida, y por lo tanto no puede ser utilizado con COMMIT (incluso tho puede especificar actualización completa en lugar de actualizar rápido). De Oracle docs:

    Los dos actualizar modos de ejecución son EN consignación y EN la DEMANDA. Según
    en la vista materializada crear, algunas de las opciones no pueden ser
    disponible. La tabla 8-4 se describe la actualización de los modos.

    Tabla 8-4 Actualización De Los Modos De

    DE COMETER

    Se actualiza automáticamente cuando una transacción que ha modificado uno de
    la vista materializada del detalle de las tablas se compromete. Este puede ser especificado
    mientras la vista materializada es rápido actualizable
    (en otras palabras,
    no complejo). El COMETER privilegio es necesario el uso de este modo.

    SOBRE LA DEMANDA

    De actualización se produce cuando un usuario manualmente ejecuta uno de los disponibles
    la actualización de los procedimientos incluidos en el DBMS_MVIEW (paquete de ACTUALIZACIÓN,
    REFRESH_ALL_MVIEWS, REFRESH_DEPENDENT).

    El mismo vínculo de documento tiene una lista de restricciones para una rápida actualización.

  2. 1

    «Tal vez el ejemplo no es la mejor, porque quiero ampliar la vista
    para una más complicada de la consulta, que requerirá de una palabra clave distinct,
    ahora mismo solo estoy tratando de que funcione en un nivel básico. «

    La DISTINTA es la causa de la ORA-12054.

    SQL> CREATE MATERIALIZED VIEW REC_SEARCH_TEST
        REFRESH COMPLETE ON COMMIT
        AS (
           SELECT DISTINCT empno, ename FROM emp
       )
    /
      2    3    4    5    6  
           SELECT DISTINCT empno, ename FROM emp
                                             *
    ERROR at line 4:
    ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view
    
    
    Elapsed: 00:00:01.14
    SQL> SQL> 
    SQL> CREATE MATERIALIZED VIEW REC_SEARCH_TEST
        REFRESH COMPLETE ON COMMIT
        AS (
           SELECT empno, ename FROM emp
       )
    /
      2    3    4    5    6  
    Materialized view created.
    
    Elapsed: 00:00:02.33
    SQL> 

    ¿Por qué no empezar con un algo que funciona? Quitar las DISTINTAS. Obtener su MView de trabajo. Luego complicar más tarde, cuando se hace necesario.

    Aunque, como usted ya sabe que usted no puede usar un diferente tendrás que revisar tu consulta de la lógica o la actualización de la estrategia.

    • Por ejemplo, si estoy ejecutando una búsqueda y quiero rellenar un cuadro combinado. Podría seguir con una memoria caché de la materializado ver con «SELECT DISTINCT GÉNERO DE APLICACIONES;». ¿Por qué no puede un conjunto de hasta un materializa a ver como esta para actualizar a cometer? Yo sé que no puedo, pero estoy interesado en la razón y qué otras opciones están disponibles.
  3. -1

    La cosa importante a tener en cuenta acerca de la cuestión es que es no acerca de la rápida actualización, pero la actualización completa. Por lo tanto, no hay ninguna razón lógica por la que las restricciones habituales para la actualización rápida de cometer debe aplicar, excepto el que todos los objetos que se hace referencia debe ser local.

    La «actualización completa en consignación es una característica relativamente nueva, por lo que la mejor respuesta al «por qué» la pregunta es, probablemente, «Oracle no ha aplicado plenamente este, por favor revise las futuras versiones de Oracle de Base de datos». No muy útil, pero es la verdad…

Dejar respuesta

Please enter your comment!
Please enter your name here