Pb de refresh auto d'une vue materialisée

Version imprimable

Salut à tous !

Malgrès mes recherches sur le web je n'arrive toujours pas resoudre mon problème :

J'ai la vue materialisée suivante :
Code:

1 2 3 4 5 6 7 8 9 10 11 create materialized view doublons_auditeurs build immediate refresh start with sysdate next sysdate + 1/24 as select max(uti_cod) code_auditeur, min(uti_cod) code_auditeur_esclave, upper(min(uti_nom)) nom, initcap(min(uti_pre)) prenom, substr(uti_dat_naissance, 7, 2) || '/' || substr(uti_dat_naissance, 5, 2) || '/' || substr(uti_dat_naissance, 1, 4) date_naissance, count(*) nb_doublon from utilisateur group by convert(upper(uti_nom), 'US7ASCII'), convert(upper(uti_pre), 'US7ASCII'), uti_dat_naissance having count(*) > 1
La création ne pose pas de sousis par contre elle ne se raffraichie pas toutes les heures comme je lui demande !!

Aidez-moi SVP !

PS : Pour répondre à la question habituelle "Pourquoi une MV ?" je répond que la requete prend 35 secondes environ, que je dois l'interroger souvent et que son résultat évolue lentement d'où le refresh d'1h ! La MV retourne mes ligne immédiatement !

21/11/2006, 15h45
davy.g

Peut être que ta requête te retourne le même nombre de lignes 1 heure plus tard, non ? Il faut peut etre attendre plus ?
21/11/2006, 15h51
remi4444

Est-ce que tu as une valeur supérieure à 0 au paramètre "JOB_QUEUE_PROCESSES" ? C'est un paramètre qui peut se changer à chaud.
21/11/2006, 16h23
Omsey

En fait je n'ai pas la main sur la machine qui fait tourner Oracle alors je ne sais pas la valeur de JOB_QUEUE_PROCESSES !

Pour le nombre de lignes je pense que cela importe peut et lorsque j'interroge la table dba_jobs j'ai les données suivantes :

LAST_DATE = rien
THIS_DATE = rien
NEXT_DATE = 21/11/06:15:43:25
INTERVAL = rien
WHAT = dbms_refresh.refresh('"GRAFIC"."DOUBLONS_AUDITEURS"');

Quand je lance le script de "What", no problemo, ça me rafraichi bien la vue (quelle ai changé ou non).

Citation:

C'est un paramètre qui peut se changer à chaud.

Ah oui via SQL ? Dis-moi comment le changer si c'est possible ! On peut peut-être aussi l'interroger ?
21/11/2006, 16h33
jacquesh

tout est là

__
TIP: Click help for a detailed explanation of this page.
Bookmark Go to End

Subject: Jobs Not Executing Automatically
Doc ID: Note:313102.1 Type: PROBLEM
Last Revision Date: 14-APR-2006 Status: MODERATED

In this Document
Symptoms
Cause
Solution
References

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) Rapid Visibility (RaV) process, and therefore has not been subject to an independent technical review.

Applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.4.0
This problem can occur on any platform.
Symptoms
Jobs are no longer executing automatically.
If forced (exec dbms_job.run(<enter here job number>);), these execute fine.
Cause

Trying the most common reasons why jobs don't execute automatically and as scheduled:

1) Instance in RESTRICTED SESSIONS mode?
Check if the instance is in restricted sessions mode:
select instance_name,logins from v$instance;
If logins=RESTRICTED, then:
alter system disable restricted session;
^-- Checked!

2) JOB_QUEUE_PROCESSES=0
Make sure that job_queue_processes is > 0
show parameter job_queue_processes
^-- Checked!

3) _SYSTEM_TRIG_ENABLED=FALSE
Check if _system_enabled_trigger=false
col parameter format a25
col value format a15
select a.ksppinm parameter,b.ksppstvl value from x$ksppi a,x$ksppcv b
Where a.indx=b.indx and ksppinm=’_system_trig_enabled’;
^-- Checked!

4) Is the job BROKEN?
select job,broken from dba_jobs where job=<job_number>;
If broken, then check the alert log and trace files to diagnose the issue.
^-- Checked! The job is not broken.

5) Is the job COMMITted?
Make sure a commit is issued after submitting the job:
DECLARE X NUMBER;
BEGIN
SYS.DBMS_JOB.SUBMIT
(
job => X
,what => 'dbms_utility.analyze_schema
(''SCOTT'',''COMPUTE'',NULL,NULL,NULL);'
,next_date => to_date('08/06/2005 09:35:00','dd/mm/yyyy hh24:mi:ss')
,no_parse => FALSE
);
COMMIT;
END;
/
If the job executes fine if forced (i.e., exec dbms_jobs.run(<job_no>);), then likely a commit
is missing.
^-- Checked! The job is committed after submission.

6) UPTIME > 497 days
Check if the server (machine) has been up for more than 497 days:
For SUN , use 'uptime' OS command.
If uptime>497 and the jobs do not execute automatically, then you are hitting bug 3427424
(Jobs may stop running after 497 days uptime) which is fixed in 9206 and A102
^-- Checked! The server in this case has been up 126 days only

7) DBA_JOBS_RUNNING
Check dba_jobs_running to see if the job is still running:
select * from dba_jobs_running;
^-- Checked! The job is not running.

8) LAST_DATE and NEXT_DATE
Check if the last_date and next_date for the job are proper:
select Job,Next_date,Last_date from dba_jobs where job=<job_number>;
^-- NEXT_DATE is porper, however LAST_DATE is null since the job never executes automatically.

9) NEXT_DATE and INTERVAL
Check if the Next_date is changing properly as per the interval set in dba_jobs:
select Job,Interval,Next_date,Last_date from dba_jobs where job=<job_number>;
^-- This is not possible since the job never gets executed automatically.

10) Toggle value for JOB_QUEUE_PROCESSES
Set job_queue_processes=0, wait some time and then and set it back to the original value:
alter system set job_queue_processes=0 ;
--<Wait for some time>
alter system set job_queue_processes=4 ;
Ref: Bug 2649244 (fixed by: 9015,9203,A000)
^-- Done but did not help

11) DBMS_IJOB(Non-documented):
Last ditch effort.
Either restart the database or try the following:
exec dbms_ijob.set_enabled(true);
Ref: Bug 3505718 (Closed, Not a Bug)
@Note 90989.1 (Using DBMS_IJOB) INTERNAL NOTE

Done but did not help

These are the most common causes for this behavior.
Solution

The solution ended up to be the server (machine) uptime.
Even though it was up for only 126 days, after the server was rebooted all jobs were able to execute automatically.

To implement the solution, please execute the following steps:

1. Shutdown all applications, including databases.
2. Shutdown the server (machine)
3. Restart all applications, including databases.
4. Check that jobs are executing automatically.

.
References
Bug 2649244 - Jobs Don'T Run In Scheduled Intervals
Bug 3505718 - Jobs Not Running When Scheduled

Help us improve our service. Please email us your comments for this document. .
21/11/2006, 16h37
Omsey

Oh là là que de texte !

Je vais regarder ça !

Merci.

EDIT : Je viens d'executer "show parameter job_queue_processes" et que vois-je ? VALUE = 0 !!!!!!!!!!!!!!!!!
Faut que je le modifie et je réessaye !
21/11/2006, 16h50
Omsey

Allelouia ça marche !!!!!!

J'ai simplement fais
- un "ALTER SYSTEM SET JOB_QUEUE_PROCESSES=1;"
- J'ai supprimé et recréé ma vue

Et le refresh s'effectue bien !!!

Merci beaucoup pour ce coup de main (ça fait quelques heures que je prends la tête) !
21/11/2006, 16h55
remi4444

Citation:

Envoyé par Omsey

...
EDIT : Je viens d'executer "show parameter job_queue_processes" et que vois-je ? VALUE = 0 !!!!!!!!!!!!!!!!!
....

Eh oui, c'est la valeur par défaut, tu voudrais pas que ça soit trop facile non plus... ;)

Pour changer le paramètre à chaud (j'ai pris 3 dans mon exemple):

Code:

ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 3

Attention ici on change le paramètre à chaud mais il va être perdu lors du prochain redémarrage de la base. Pour fixer ce paramètre :

- soit ta base fonctionne avec un fichier d'init classique, et il faut y faire apparaitre la ligne:

Code:

JOB_QUEUE_PROCESSES = 3

Comme tu n'a pas la main sur la machine, il faut que tu communique ça à celui qui l'a...

- soit ta base fonctionne avec un spfile, et à ce moment là tu n'a pas besoind d'accéder à la machine et tu fais

Code:

ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 3 scope = BOTH

EDIT: On a croisé les messages... ;)