Primavera P6 Professional 25.12 e Oracle XE 21c: come risolvere l’errore ORA-01017 causato dalla scadenza delle password
Ripristino della connessione al database Oracle dopo la scadenza delle credenziali degli utenti PUBUSER, PRIVUSER e ADMUSER, senza reinstallare Primavera e senza perdere i progetti.
Introduzione
Dopo diversi mesi di utilizzo senza particolari problemi, la mia installazione di Oracle Primavera P6 Professional 25.12, collegata a un database locale Oracle Database Express Edition 21c, ha improvvisamente smesso di funzionare.
All’avvio di Primavera, tentando di accedere con uno qualsiasi degli utenti applicativi, compariva il messaggio:
Unable to connect to the database. Please run the database configuration tool or contact your administrator.
Il problema interessava tutti gli utenti di Primavera e impediva completamente l’accesso ai progetti.
La prima ipotesi era un problema di connessione al database Oracle, ma il servizio risultava attivo e la configurazione apparentemente corretta.
Dopo alcune verifiche ho individuato la causa: Oracle aveva fatto scadere le password degli utenti tecnici utilizzati da Primavera P6.
La soluzione si è rivelata relativamente semplice, ma con una particolarità importante: modificare le password in Oracle non è sufficiente, perché Primavera conserva alcune credenziali in una propria configurazione interna.
In questo articolo descrivo l’intera procedura che ho seguito per ripristinare il funzionamento dell’applicazione.
1. La configurazione del sistema
Il sistema interessato presenta questa configurazione:
| Componente | Versione / configurazione |
|---|---|
| Sistema operativo | Windows 11 64 bit |
| Applicazione | Primavera P6 Professional 25.12 |
| Database | Oracle Database XE 21c |
| Host database | localhost |
| Porta Oracle Listener | 1521 |
| Servizio Oracle | XEPDB1 |
| Public Group ID | 1 |
La stringa di connessione utilizzata da Primavera è:
localhost:1521/XEPDB1
Gli utenti tecnici Oracle coinvolti sono:
PUBUSER: utente pubblico per la connessione iniziale.PRIVUSER: utente privato utilizzato da Primavera.ADMUSER: utente amministrativo del database P6.BGJOBUSER: utente utilizzato per i processi in background.
Questi account non devono essere confusi con gli utenti applicativi di Primavera, come admin o gli altri utenti creati per accedere ai progetti.
2. Individuazione del problema
Aprendo Database Configuration di Primavera e tentando di validare la connessione, veniva restituito inizialmente un errore relativo all’utente pubblico:
Bad public username or password. ORA-01017.
Il codice ORA-01017 indica che Oracle non accetta le credenziali presentate. Non dimostra, da solo, che la password sia scaduta: occorre verificarne lo stato direttamente nel database.
Collegamento a Oracle tramite SQL*Plus
Da un Prompt dei comandi di Windows, sul computer che ospita Oracle XE, ho eseguito:
sqlplus / as sysdba
Il collegamento è avvenuto correttamente.
La prima verifica è stata:
SHOW CON_NAME;
Oracle ha risposto:
CDB$ROOT
Questo è un dettaglio fondamentale.
Oracle XE 21c utilizza un’architettura multitenant, nella quale il database contenitore principale (CDB$ROOT) è distinto dal Pluggable Database (XEPDB1) utilizzato da Primavera.
Le prime interrogazioni sugli utenti non restituivano alcun risultato proprio perché mi trovavo nel contenitore sbagliato.
Per accedere al database corretto:
ALTER SESSION SET CONTAINER = XEPDB1;
Una successiva verifica con SHOW CON_NAME ha confermato il passaggio a XEPDB1.
3. Verifica degli utenti Oracle
A questo punto ho eseguito:
SELECT USERNAME, ACCOUNT_STATUS, EXPIRY_DATE
FROM DBA_USERS
WHERE USERNAME IN
('PUBUSER','PRIVUSER','ADMUSER','BGJOBUSER');
Il risultato era il seguente:
| Utente | Stato | Scadenza |
|---|---|---|
| PUBUSER | EXPIRED | 27/07/2026 |
| PRIVUSER | EXPIRED(GRACE) | 27/07/2026 |
| ADMUSER | EXPIRED | 26/07/2026 |
| BGJOBUSER | OPEN | 18/07/2026 |
La causa del malfunzionamento era finalmente chiara.
Tre dei quattro account Oracle utilizzati da Primavera avevano raggiunto la scadenza della password.
EXPIRED indica una password scaduta, mentre EXPIRED(GRACE) indica che l’account si trova nel periodo di tolleranza previsto dalla relativa policy.
4. Creazione di un profilo Oracle senza scadenza
Prima di reimpostare le password, ho verificato i profili associati agli utenti:
SELECT USERNAME, PROFILE
FROM DBA_USERS
WHERE USERNAME IN
('PUBUSER','PRIVUSER','ADMUSER','BGJOBUSER');
Tutti utilizzavano il profilo Oracle DEFAULT.
Per evitare di modificare la policy globale del database, ho preferito creare un profilo specifico per gli account tecnici di Primavera.
CREATE PROFILE PRIMAVERA_PROFILE
LIMIT PASSWORD_LIFE_TIME UNLIMITED;
Il parametro PASSWORD_LIFE_TIME UNLIMITED elimina la scadenza periodica della password per gli utenti ai quali viene assegnato il profilo.
Ho quindi associato il nuovo profilo ai quattro account:
ALTER USER PUBUSER PROFILE PRIMAVERA_PROFILE;
ALTER USER PRIVUSER PROFILE PRIMAVERA_PROFILE;
ALTER USER ADMUSER PROFILE PRIMAVERA_PROFILE;
ALTER USER BGJOBUSER PROFILE PRIMAVERA_PROFILE;
Attenzione: questa scelta è stata adottata per un’installazione locale di laboratorio. In ambienti aziendali o condivisi è preferibile rispettare le policy di sicurezza previste dall’organizzazione e utilizzare procedure controllate di rotazione delle credenziali.
L’assegnazione del nuovo profilo, inoltre, non riattiva automaticamente una password già scaduta.
5. Reimpostazione delle password
Il passaggio successivo è stato modificare le password degli utenti interessati.
I comandi utilizzati sono stati:
ALTER USER PUBUSER
IDENTIFIED BY "NuovaPasswordSicura"
ACCOUNT UNLOCK;
ALTER USER PRIVUSER
IDENTIFIED BY "NuovaPasswordSicura"
ACCOUNT UNLOCK;
ALTER USER ADMUSER
IDENTIFIED BY "NuovaPasswordSicura"
ACCOUNT UNLOCK;
Nell’esempio ho utilizzato una password segnaposto: occorre sostituirla con una credenziale sicura, preferibilmente diversa per ciascun account, conservandola in un password manager.
Per semplicità, durante il mio intervento avevo utilizzato la stessa password per i tre account.
Dopo la modifica ho controllato nuovamente lo stato:
SELECT USERNAME, ACCOUNT_STATUS
FROM DBA_USERS
WHERE USERNAME IN
('PUBUSER','PRIVUSER','ADMUSER');
Tutti risultavano OPEN.
Sembrava quindi che il problema fosse risolto.
In realtà mancava ancora un passaggio essenziale.
6. Il secondo problema: Bad private username or password
Tornando in Primavera Database Configuration, ho aggiornato la password dell’utente pubblico PUBUSER.
Questa volta la connessione iniziale funzionava, ma la validazione restituiva un nuovo messaggio:
Bad private username or password. Check the public group ID.
Ancora una volta compariva l’errore Oracle ORA-01017.
Il problema non era più lo stato dell’account Oracle, perché PRIVUSER risultava regolarmente OPEN.
Il punto è che Primavera P6 conserva separatamente le informazioni di autenticazione del private database user, associate al Public Group ID.
Avevo aggiornato la password dell’account in Oracle, ma Primavera tentava ancora di autenticarsi con la password precedentemente memorizzata.
Era quindi necessario aggiornare anche questa configurazione.
7. La soluzione: databaselogins.bat
Per risolvere il problema ho recuperato dal portale di distribuzione Oracle il pacchetto:
Primavera P6 Professional Database Setup 25
Versione 25.12, file:
V1053388-01.zip
Dopo l’estrazione, nella cartella:
P6_R2512_Database
sono disponibili diversi strumenti, tra cui:
charconversion.bat
databaselogins.bat
dbsetup.bat
migrate.bat
validate.bat
Quello che ci interessa è:
databaselogins.bat
Si tratta dell’utilità Oracle per la gestione dei login privati del database Primavera.
Dal Prompt dei comandi di Windows ho raggiunto la cartella:
cd /d E:\DOWNLOADS\V1053388-01\P6_R2512_Database
E avviato:
databaselogins.bat
Si è aperta un’interfaccia grafica per la configurazione dei login privati.
Collegamento al database
Nella prima schermata ho specificato i parametri della connessione Oracle:
| Campo | Valore |
|---|---|
| Username | privuser |
| Password | Password Oracle aggiornata |
| Host | localhost |
| Port | 1521 |
| Instance | XEPDB1 |
| Tipo connessione | Service |
È importante selezionare Service e non SID, perché XEPDB1 è il servizio del Pluggable Database utilizzato da Primavera.
Aggiornamento del Private Database Login
Dopo aver premuto Next, il programma ha mostrato la configurazione del login privato:
- Public Group ID:
1 - Private DB Username:
privuser - Campo per l’inserimento della password
Ho inserito la nuova password di PRIVUSER e premuto:
Update Password
Il pulsante è diventato inattivo, mentre il comando Save risultava disponibile.
Ho quindi premuto:
Save → OK
La configurazione è stata salvata senza errori.
8. Verifica finale: Primavera torna a funzionare
Terminata la procedura, ho chiuso lo strumento di configurazione e riavviato Primavera P6 Professional 25.12.
Questa volta l’applicazione ha superato correttamente la connessione al database e ha consentito nuovamente l’accesso.
Non è stato necessario reinstallare Oracle XE, reinstallare Primavera o ricreare il database dei progetti.
Il problema era esclusivamente legato alla scadenza delle credenziali Oracle e al mancato allineamento della password del private database user.
9. Riepilogo della procedura
Per chi dovesse incontrare lo stesso problema, i passaggi principali sono:
- Collegarsi a Oracle con
sqlplus / as sysdba. - Verificare di trovarsi nel container
XEPDB1. - Controllare lo stato di
PUBUSER,PRIVUSER,ADMUSEReBGJOBUSER. - Gestire la policy di scadenza delle password, eventualmente tramite un profilo dedicato.
- Reimpostare le password degli account scaduti.
- Aggiornare la password pubblica nel Database Configuration di Primavera.
- Eseguire
databaselogins.batdal pacchetto Database Setup della versione corrispondente. - Aggiornare e salvare la password privata associata al Public Group ID.
- Riavviare Primavera e verificare il collegamento.
10. Considerazioni finali
Questo intervento mi ha permesso di approfondire alcuni aspetti dell’integrazione tra Primavera P6 Professional e Oracle XE che, durante l’utilizzo quotidiano, rimangono generalmente nascosti.
In particolare, sono tre gli elementi da ricordare.
Primo: Oracle XE 21c utilizza un’architettura multitenant. Quando si eseguono operazioni amministrative è indispensabile verificare di essere nel container corretto.
Secondo: gli utenti tecnici Oracle non coincidono con gli utenti applicativi di Primavera. Modificare la password di PRIVUSER non significa modificare quella degli utenti che accedono a P6.
Terzo: la password del private database user deve essere sincronizzata anche attraverso gli strumenti di amministrazione di Primavera. Cambiarla direttamente in Oracle non basta.
Il file databaselogins.bat, incluso nel pacchetto ufficiale Database Setup, si è rivelato determinante per completare il ripristino.
Per chi utilizza Primavera P6 Professional con Oracle XE su una workstation personale, consiglio di conservare il pacchetto Database Setup corrispondente alla propria versione e di predisporre un backup periodico del database.
Un semplice problema di scadenza delle password può altrimenti sembrare un guasto ben più grave, soprattutto quando impedisce completamente l’accesso ai progetti.
Ambiente testato: Windows 11, Oracle Database XE 21c, Primavera P6 Professional 25.12, database XEPDB1.
La procedura descrive un intervento realmente eseguito su un’installazione locale. Prima di applicarla su sistemi di produzione è opportuno effettuare un backup e verificare le policy di sicurezza del proprio ambiente.