Come per tutte le cose, dipende.
Se stai usando OCI, suppongo che stai sviluppando un'applicazione client / server. Vorrei in genere che il database in quella situazione supporti le connessioni al server condiviso e vorrei richiedere una connessione al server condiviso quando l'applicazione si è connessa al database. Ciò migliora le prestazioni dell'applicazione limitando la quantità di lavoro che il database deve svolgere per creare una nuova sessione. Ciò ha l'effetto collaterale di lasciare più risorse disponibili sul server per gli altri. L'uso delle connessioni al server condiviso implica un percorso di codice più lungo quando il database esegue le query successive poiché la query deve essere inviata a un processo del server condiviso, ma generalmente non è un grosso problema se il numero di processi del server condiviso è ragionevole.
L'apertura di un numero di sessioni potrebbe anche essere un problema se il DBA non utilizza la gestione PGA automatica. Se si utilizza la gestione PGA manuale, PGA è configurato in base alla sessione in modo che ogni sessione possa allocare una distinta SORT_AREA_SIZEper ordinamento tra gli altri componenti PGA. Se hai creato un gran numero di sessioni in un database utilizzando la gestione PGA manuale e ogni sessione ha cercato di massimizzare l'utilizzo della PGA, potresti facilmente far morire di fame il server di RAM e causare problemi di prestazioni a tutti. Supponendo che si stia utilizzando Oracle 10.1 o versioni successive, tuttavia, è disponibile la gestione PGA automatica. In tal caso, il DBA configura un PGA_AGGREGATE_TARGET(o include la PGA in MEMORY_TARGETin 11g) e il database si occupa di garantire che la PGA aggregata in tutte le sessioni sia limitata in modo che il database esaurisca le risorse.
Se il database supporta connessioni server condivise, l'applicazione ottiene una connessione server condivisa e il database utilizza la gestione PGA automatica, la maggior parte dei DBA non si preoccuperà troppo di quante sessioni create.
Ora, se stai creando molte sessioni in modo da poter fare più lavoro in parallelo, ciò creerebbe problemi di prestazioni oltre al numero di sessioni. È abbastanza facile configurare il database per supportare 1000 sessioni, ad esempio, è molto più difficile configurare il database in modo che non muoia in pila se tutte le 1000 sessioni emettono simultaneamente una query carnosa su un data warehouse. Se l'applicazione utilizza tutte le risorse disponibili nel database per le query, è probabile che il DBA voglia prendere in considerazione l'utilizzo di Oracle Resource Managerdare la priorità a diverse applicazioni e / o diversi utenti. Ad esempio, il DBA potrebbe configurare Resource Manager in modo che se l'utilizzo della CPU va al 100%, l'applicazione nell'aggregazione ottiene il 50% della CPU, un'altra applicazione nell'aggregazione ottiene il 25% e tutte le altre ottengono il restante 25% . Se non vi fossero altre richieste in sospeso, l'applicazione sarebbe libera di utilizzare tutto il 100% della CPU.
Se si eseguono operazioni in parallelo, potrebbe anche essere utile esaminare la capacità di Oracle di eseguire istruzioni in parallelo perché ciò potrebbe comportare un sovraccarico minore rispetto alla scrittura del proprio codice di parallelizzazione. Mi aspetterei, ad esempio, che sarebbe molto più semplice e molto probabilmente più veloce scrivere un'applicazione client che presentava in serie dichiarazioni che utilizzavano query parallele Oracle per eseguire anziché aprire più sessioni ed eseguire ciascuna istruzione da un thread separato dell'applicazione mentre Oracle non utilizzava query parallele per eseguire nessuna delle istruzioni. Se si utilizza la query parallela, il database può anche regolare il numero di slave paralleli generati in modo che quando il database è particolarmente occupato vengono avviati meno slave paralleli e quando il database è relativamente inattivo vengono avviati più slave paralleli.