Come realizzare un ambiente Primavera P6 professionale, centralizzato e accessibile anche da remoto, utilizzando Oracle Database Express Edition su Windows 11.

Introduzione

Primavera P6 Professional è uno degli strumenti più diffusi nel settore della pianificazione e del controllo dei grandi progetti infrastrutturali. È una soluzione che utilizzo nell’attività professionale di project planning, programmazione lavori e project control.

Una delle questioni che mi sono posto è stata quella di realizzare un ambiente di lavoro nel quale poter gestire diversi progetti attraverso un database centralizzato, mantenendo la possibilità di accedere da più computer, anche fuori ufficio.

La soluzione che ho adottato prevede:

• Primavera P6 Professional 25.12, come applicativo di pianificazione;
• Oracle Database 21c Express Edition, come database relazionale;
• Windows 11, come sistema operativo del computer principale;
• WireGuard, per l’accesso sicuro da remoto;
• Oracle Data Pump, per i backup logici del database;
• 7-Zip e Utilità di pianificazione di Windows, per automatizzare archiviazione e conservazione dei backup.

In questo articolo descrivo la configurazione finale utilizzata, le principali operazioni necessarie e le verifiche effettuate.

L’obiettivo non è ripercorrere ogni problema incontrato durante l’installazione, ma documentare una procedura tecnica che possa essere riutilizzata.

---

1. Architettura del sistema

L’architettura è piuttosto semplice: un computer desktop ospita Oracle Database e costituisce il sistema centrale, mentre uno o più client Primavera P6 accedono allo stesso database.

La configurazione realizzata è la seguente:

Componente	Configurazione
Sistema operativo	Windows 11
Primavera P6	Professional 25.12
Database	Oracle Database 21c Express Edition
Istanza Oracle	XE
Pluggable Database	XEPDB1
Porta del listener	TCP 1521
Schema P6	ADMUSER
Accesso remoto	WireGuard
Backup	Oracle Data Pump
Compressione	7-Zip

Il computer principale può quindi contenere tutti i progetti Primavera, mentre il notebook viene utilizzato come postazione mobile.

Un aspetto importante è che i dati non sono memorizzati all’interno dell’applicazione P6, ma nel database Oracle.

Questo consente di utilizzare più installazioni dell’applicativo mantenendo un unico archivio progettuale.

2. Installazione di Oracle Database 21c Express Edition

Il primo componente da installare è Oracle Database 21c XE.

La versione Express Edition è particolarmente interessante per un ambiente personale o un piccolo studio professionale, perché è gratuita, pur prevedendo alcune limitazioni sulle risorse e sulla dimensione dei dati.

Durante l’installazione vengono predisposti:

• L’istanza Oracle XE;
• il database contenitore;
• il pluggable database XEPDB1;
• il listener Oracle sulla porta TCP 1521;
• gli strumenti di amministrazione, tra cui SQL*Plus.

Nel mio ambiente il percorso Oracle Home è:

C:\app\Andrea\product\21c\dbhomeXE

La prima verifica consiste nell’aprire un prompt dei comandi con i privilegi necessari e avviare:

sqlplus / as sysdba

Una volta entrati in SQL*Plus:

SHOW PDBS;

Dovrebbe comparire il pluggable database XEPDB1.

Se non è aperto, è possibile avviarlo:

ALTER PLUGGABLE DATABASE XEPDB1 OPEN;

Per conservarne lo stato di apertura ai successivi riavvii:

ALTER PLUGGABLE DATABASE XEPDB1 SAVE STATE;

Il passaggio successivo è selezionarlo:

ALTER SESSION SET CONTAINER = XEPDB1;
SHOW CON_NAME;

Il risultato atteso è:

XEPDB1

Questo passaggio è fondamentale: gli utenti e gli oggetti destinati a Primavera devono essere gestiti nel container corretto, non nel database contenitore principale.

3. Preparazione del database Primavera P6

Per la versione P6 Professional 25.12 ho utilizzato il pacchetto di installazione database distribuito da Oracle.

Il pacchetto contiene una directory denominata:

P6_R2512_Database

Al suo interno sono presenti gli script SQL e le utility necessarie alla configurazione del database.

Tra i componenti utilizzati figura:

dbsetup.bat

Si tratta dell’utility grafica con cui è possibile configurare il database destinato a Primavera P6.

Preparazione dell’ambiente Java

Le utility database di P6 richiedono una versione compatibile del Java Development Kit.

Nella configurazione utilizzata ho installato JDK 17, predisponendo l’ambiente affinché gli strumenti P6 potessero eseguirsi correttamente.

È opportuno verificare la versione Java attiva:

java -version

Prima di avviare la configurazione, occorre inoltre verificare i prerequisiti Oracle indicati nella documentazione della specifica release Primavera.

Esecuzione della configurazione database

La procedura di preparazione comprende:

1. Esecuzione degli script SQL preliminari previsti dal pacchetto Oracle Primavera.
2. Selezione del database XEPDB1.
3. Avvio dell’utility dbsetup.bat.
4. Configurazione delle credenziali amministrative.
5. Creazione degli utenti e degli oggetti applicativi Primavera.
6. Completamento degli script di installazione.

Nel database configurato risultano gli utenti:

ADMUSER
PRIVUSER
PUBUSER
BGJOBUSER

Questi account svolgono funzioni differenti all’interno dell’ambiente Primavera e devono essere configurati secondo i privilegi previsti dal prodotto.

Per i tablespace, l’installazione utilizza la configurazione Oracle basata su USERS e TEMP.

Le password e i privilegi devono essere gestiti con attenzione: è preferibile utilizzare credenziali distinte e conservate in modo sicuro.

4. Configurazione della connessione di Primavera P6

Terminata la predisposizione del database, si configura Primavera P6 Professional.

La connessione locale Oracle utilizza:

Host: localhost
Porta: 1521
Service name: XEPDB1

La stringa Oracle Easy Connect equivalente è:

//localhost:1521/XEPDB1

Per verificare che il database risponda è possibile utilizzare SQL*Plus:

sqlplus admuser@//localhost:1521/XEPDB1

Il programma richiede la password dell’utente.

Se la connessione riesce, significa che il listener risponde e che l’account può accedere al database.

Naturalmente, questo test non sostituisce la successiva verifica di accesso attraverso Primavera P6.

Gestione delle password applicative

Nel corso dell’utilizzo può verificarsi che Oracle segnali una password scaduta, impedendo l’accesso dell’applicazione.

È necessario quindi verificare lo stato degli utenti nel pluggable database:

ALTER SESSION SET CONTAINER = XEPDB1;

SELECT USERNAME, ACCOUNT_STATUS
FROM DBA_USERS
WHERE USERNAME IN
('ADMUSER', 'PRIVUSER', 'PUBUSER', 'BGJOBUSER');

Quando è necessario aggiornare le credenziali utilizzate da Primavera si deve tenere conto anche delle impostazioni applicative.

Nel pacchetto database è disponibile l’utility:

databaselogins.bat

Questa consente di gestire le credenziali applicative previste dalla configurazione P6.

Nel mio caso è stata parte della soluzione a un problema di accesso dovuto alla scadenza delle password.

La politica di scadenza delle password è un parametro di sicurezza da impostare consapevolmente: non è opportuno disabilitarla indiscriminatamente per tutti gli utenti Oracle.

5. Accesso da un secondo computer

Una volta configurato il database, Primavera P6 può essere utilizzato anche da un secondo computer.

All’interno della rete locale è sufficiente che il client possa raggiungere l’indirizzo IP del computer che ospita Oracle, sulla porta TCP 1521.

La connessione mantiene lo stesso service name:

XEPDB1

È necessario verificare:

• che Oracle Listener sia in esecuzione;
• che il firewall di Windows consenta l’accesso alla porta 1521 dalla rete autorizzata;
• che il computer principale abbia un indirizzo LAN stabile;
• che il client Primavera disponga dei componenti di connessione Oracle compatibili, se richiesti dalla sua modalità di installazione.

In questo modo è possibile accedere ai progetti centralizzati senza duplicare il database.

6. Accesso remoto con WireGuard

Per lavorare da fuori ufficio ho scelto WireGuard, una VPN moderna che permette di creare un tunnel cifrato tra notebook e rete domestica.

Nella mia configurazione la VPN utilizza:

Computer principale: 10.10.10.1
Notebook:            10.10.10.2

Quando il tunnel è attivo, il notebook può raggiungere il database attraverso la connessione:

//10.10.10.1:1521/XEPDB1

Una verifica preliminare si può effettuare con:

ping 10.10.10.1

E successivamente:

sqlplus admuser@//10.10.10.1:1521/XEPDB1

Nell’ambiente realizzato sono stati verificati sia il collegamento Oracle attraverso la VPN sia l’accesso a Primavera P6.

Gestione dell’indirizzo IP pubblico dinamico

Una connessione domestica può avere un indirizzo IP pubblico variabile.

Per questo motivo è opportuno utilizzare un servizio Dynamic DNS, ad esempio DuckDNS, compatibile con numerosi router.

Il servizio associa un hostname all’indirizzo pubblico corrente.

Nel file di configurazione WireGuard del notebook, l’endpoint potrà quindi utilizzare un nome DNS anziché un indirizzo numerico:

Endpoint = nome-scelto.duckdns.org:51820

La porta indicata è un esempio: deve corrispondere a quella effettivamente utilizzata dal server WireGuard.

Se il router supporta nativamente il servizio DDNS, può aggiornare l’indirizzo automaticamente, senza richiedere script aggiuntivi sul computer.

È comunque indispensabile disporre di un indirizzo pubblico raggiungibile o di un’altra soluzione che superi un eventuale CGNAT.

La porta Oracle 1521 non deve essere esposta direttamente su Internet: l’accesso remoto al database avviene attraverso la VPN.

7. Backup del database con Oracle Data Pump

Una volta completata l’installazione è necessario predisporre una procedura di backup.

Ho utilizzato Oracle Data Pump, che consente di esportare logicamente lo schema Primavera.

Creazione della directory di esportazione

Sul computer principale ho predisposto una cartella:

C:\oracle_backup_stage

All’interno del database XEPDB1 ho registrato la directory Oracle corrispondente:

ALTER SESSION SET CONTAINER = XEPDB1;

CREATE OR REPLACE DIRECTORY BACKUP_ORACLE
AS 'C:\oracle_backup_stage';

GRANT READ, WRITE ON DIRECTORY BACKUP_ORACLE
TO ADMUSER;

È importante che la directory Windows esista e sia scrivibile dall’account di servizio Oracle.

Esportazione del database applicativo

Il comando Data Pump utilizzato è:

expdp admuser@//localhost:1521/XEPDB1 schemas=ADMUSER directory=BACKUP_ORACLE dumpfile=p6_backup.dmp logfile=p6_backup.log

Il comando richiede la password e produce:

p6_backup.dmp
p6_backup.log

Il primo file contiene il dump logico, il secondo il registro delle operazioni.

L’esportazione dello schema ADMUSER è stata eseguita e completata correttamente.

Occorre però ricordare che un export di schema non equivale a un backup completo dell’istanza Oracle.

Per un sistema di produzione è opportuno integrare questa procedura con backup fisici del database e verifiche periodiche di ripristino.

8. Compressione e automazione dei backup

Per limitare lo spazio occupato dagli archivi ho utilizzato 7-Zip.

Sul computer il programma è installato in:

C:\Program Files\7-Zip\7z.exe

Il principio della procedura automatizzata è il seguente:

1. Esecuzione dell’export Oracle nella directory temporanea.
2. Controllo dell’esito dell’operazione.
3. Compressione del dump e del relativo log.
4. Trasferimento dell’archivio nella cartella dedicata ai backup.
5. Pulizia dei file temporanei.
6. Conservazione degli archivi secondo una politica di rotazione.

La struttura utilizzata è:

D:\backup_Oracle\
|
+-- scripts\
|   +-- p6_backup_daily.bat
|   +-- p6_backup_monthly.bat
|
+-- daily_10\
|
+-- monthly\
|
+-- logs\

La politica prevista è:

Tipologia	Frequenza	Conservazione
Backup giornaliero	Ogni giorno	Ultimi 10 archivi
Backup mensile	Ogni mese	Archivio storico

Gli script vengono avviati mediante Utilità di pianificazione di Windows.

Per un’esecuzione realmente non presidiata è indispensabile gestire le credenziali Oracle senza richieste interattive, ad esempio mediante un meccanismo di autenticazione sicuro.

È inoltre necessario controllare i codici di uscita di Data Pump e 7-Zip, evitando di archiviare come valido un backup incompleto.

Un’attività pianificata non costituisce, da sola, prova che il backup sia riuscito: occorre verificare i log e la presenza degli archivi.

Conservazione esterna dei backup

Un ulteriore elemento di sicurezza consiste nel mantenere almeno una copia dei backup fuori dal computer principale.

Un secondo disco locale è utile contro alcune forme di perdita dei dati, ma non protegge adeguatamente da furto, incendio, guasti multipli o attacchi che coinvolgano l’intero sistema.

La strategia dovrebbe quindi includere anche una copia esterna, preferibilmente cifrata e con versionamento.

9. Verifica del ripristino

Un backup è realmente utile soltanto se può essere ripristinato.

Per questo ho effettuato una prova di importazione Data Pump su uno schema separato, denominato:

ADMTEST

L’importazione utilizza la funzione REMAP_SCHEMA:

impdp admtest@//localhost:1521/XEPDB1 directory=BACKUP_ORACLE dumpfile=p6_backup.dmp logfile=restore_test.log remap_schema=ADMUSER:ADMTEST

La prova ha confermato che il dump era leggibile e che Data Pump riusciva a importare diversi oggetti e dati.

Sono tuttavia comparsi errori relativi ai privilegi di creazione di alcune viste e ad alcuni oggetti dipendenti.

Questo significa che il test ha verificato la leggibilità dell’archivio, ma non ancora un ripristino completo e utilizzabile da Primavera P6.

Il passo successivo dovrà essere una prova di disaster recovery su un ambiente Oracle separato, con installazione e configurazione applicativa correttamente predisposte.

10. Lavorare offline con Primavera P6

Rimane un’ultima esigenza: poter lavorare sul notebook quando non è disponibile una connessione Internet.

In questa situazione la VPN non è utilizzabile e il database centrale risulta irraggiungibile.

La soluzione che ho scelto non prevede l’installazione di una seconda istanza Oracle sul notebook.

Il notebook dispone già di un database locale SQLite utilizzabile con Primavera P6.

L’organizzazione prevista è:

Computer principale

Contiene Oracle XE e l’insieme dei progetti. Rappresenta l’archivio centralizzato di riferimento.

Notebook

Contiene il database SQLite locale, utilizzato esclusivamente per i progetti sui quali è necessario lavorare senza connessione.

Per trasferire un progetto fra i due ambienti si possono utilizzare i file XER esportati da Primavera P6.

Il flusso operativo è:

1. Esportare da Oracle il progetto da portare sul notebook.
2. Importarlo nel database SQLite locale e verificarlo.
3. Modificare il progetto offline, evitando modifiche parallele alla versione centrale.
4. Esportare il progetto aggiornato in XER.
5. Reimportarlo nel database centrale, verificando attentamente le opzioni di aggiornamento.
6. Controllare la corrispondenza dei dati, delle relazioni e delle impostazioni di progetto.

Questo procedimento non è una sincronizzazione automatica dei database.

È un trasferimento controllato di informazioni progettuali, che richiede particolare attenzione a calendari, risorse, codifiche, campi personalizzati e dati globali.

Prima di utilizzarlo su progetti reali è opportuno collaudare l’intero ciclo su una copia di prova.

11. Considerazioni finali

L’esperienza mi ha consentito di realizzare un ambiente Primavera P6 articolato, ma relativamente semplice dal punto di vista dell’architettura:

• un database Oracle centralizzato;
• più postazioni Primavera P6;
• accesso remoto cifrato tramite WireGuard;
• esportazioni periodiche con Oracle Data Pump;
• archiviazione compressa e conservazione storica;
• possibilità di lavorare temporaneamente offline attraverso SQLite e scambio di file XER.

La parte più delicata non è tanto l’installazione dell’applicativo, quanto la corretta configurazione dell’infrastruttura Oracle e delle procedure di protezione dei dati.

La distinzione fra database contenitore e pluggable database, i privilegi applicativi, la gestione delle credenziali e la verifica dei backup sono tutti aspetti che meritano attenzione.

Per un planner o un project manager che gestisce autonomamente più commesse, un’architettura di questo tipo può rappresentare una soluzione interessante per centralizzare il lavoro senza adottare infrastrutture server particolarmente complesse.

Restano fondamentali la valutazione dei limiti di Oracle XE, la compatibilità delle versioni software e l’esecuzione di prove di ripristino complete.

La conclusione più importante è che un sistema di pianificazione affidabile non dipende soltanto dal software utilizzato, ma soprattutto dalla possibilità di accedere, proteggere e recuperare correttamente i dati dei progetti.

---

Articolo tecnico basato su una configurazione reale di Primavera P6 Professional 25.12 e Oracle Database 21c Express Edition. I comandi sono riportati a scopo documentale e devono essere adattati e verificati nell’ambiente di destinazione.