Risoluzione dei problemi di allocazione della memoria non riuscita durante l'elaborazione delle query dopo l'aggiunta del trunk SIP

Introduzione

Questo documento descrive come risolvere il messaggio di errore "Allocazione di memoria non riuscita durante l'elaborazione delle query" su CUCM quando non è possibile aggiungere un trunk SIP.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• VOS (Voice Operating System)
• CUCM (Cisco Unified Communications Manager)
• SIP (Session Interface Protocol).
• Database Informix.
• CLI (Command Line Interface).

Componenti usati

Questo documento è stato redatto per CUCM e non è limitato a versioni software e hardware specifiche.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Quando si aggiunge un trunk SIP al server CUCM, in alcuni casi viene visualizzato l'errore mostrato nell'immagine.

Eseguire i passaggi successivi prima di riprodurre il problema.

Passaggio 1. Impostare i registri al livello di dettaglio in tutti i nodi CUCM

- Traccia CM
- Monitor Layer di database
- Servizio Web CCMAdmin
- Servizio Web CCMUser

Passaggio 2. Riprodurre il problema. Tentare di aggiungere il trunk SIP e contrassegnare il momento in cui non riesce a completare l'attività

Risoluzione dei problemi

Passare all'RTMT (Real-Time Monitor Tool) e ottenere le seguenti tracce:

- Traccia CM
- Monitor Layer di database
- Servizio Web CCMAdmin
- Servizio Web CCMUser

- Registri delle applicazioni del Visualizzatore eventi

- Registri di sistema del Visualizzatore eventi

Analisi log

Dai registri del servizio Web CCMAdmin

Il trunk SIP viene inserito nel database

2024-03-14 09:51:12,487 DEBUG [http-nio-1027-exec-7] formhandlers.TrunkFormHandler - Insert Trunk
2024-03-14 09:51:12,570 DEBUG [http-nio-1027-exec-7] utilities.DbRead - reading from cache...
2024-03-14 09:51:12,573 DEBUG [http-nio-1027-exec-7] utilities.DbRead - reading from cache...

Il dispositivo trunk SIP viene aggiornato con un ID univoco

2024-03-14 09:51:12,590 DEBUG [http-nio-1027-exec-7] formhandlers.TrunkFormHandler - Updating SIP - devicePkid = e277a39a-1437-84ba-5047-57adddc75a43
...
The SP Trunk starts to be configured within the database
2024-03-14 09:51:12,618 DEBUG [http-nio-1027-exec-7] formhandlers.Device - update initiated
2024-03-14 09:51:12,620 DEBUG [http-nio-1027-exec-7] formhandlers.Device - Insert/update device
...
2024-03-14 09:51:13,449 DEBUG [http-nio-1027-exec-7] utilities.DbRelatedUtil - 1 row(s) affected.
...
2024-03-14 09:51:13,910 DEBUG [http-nio-1027-exec-7] utilities.DbRelatedUtil - 1 row(s) affected.
2024-03-14 09:51:13,913 INFO  [http-nio-1027-exec-7] utilities.SIPDeviceUtil - Entering checkSecurityProfilePortDuplicates
...

L'inserimento del dispositivo non riesce e la configurazione inizia il rollback

2024-03-14 09:51:14,294 ERROR [http-nio-1027-exec-7] formhandlers.Device - insert/update failed.  Rollback changes

Eccezione handle generata dal database

2024-03-14 09:51:14,338 ERROR [http-nio-1027-exec-7] formhandlers.TrunkFormHandler - Exception: Memory allocation failed during query processing.
java.sql.SQLException: Memory allocation failed during query processing.
2024-03-14 09:51:14,360 INFO  [http-nio-1027-exec-7] actions.BaseAction - SQLException :: -208::java.sql.SQLException: Memory allocation failed during query processing.
2024-03-14 09:51:14,363 DEBUG [http-nio-1027-exec-7] actions.BaseAction - Db Error :: Memory allocation failed during query processing.
2024-03-14 09:51:14,365 DEBUG [http-nio-1027-exec-7] actions.BaseAction - Error could not be mapped using zero :: Memory allocation failed during query processing.
java.lang.NumberFormatException: For input string: "Memory allocation failed during query processing."
2024-03-14 09:51:14,370 DEBUG [http-nio-1027-exec-7] actions.BaseAction - Error Code :: 0
2024-03-14 09:51:14,410 DEBUG [http-nio-1027-exec-7] actions.BaseAction - DBE Error code was not set :: java.sql.SQLException: Memory allocation failed during query processing.
2024-03-14 09:51:14,412 DEBUG [http-nio-1027-exec-7] actions.BaseAction - Parsing Database Specific Error :: java.sql.SQLException: Memory allocation failed during query processing. :: error.add
2024-03-14 09:51:14,414 ERROR [http-nio-1027-exec-7] actions.BaseAction - Caller Specified DatabaseException [error.add] :: java.sql.SQLException: Memory allocation failed during query processing.

Nei log di CCM Informix è possibile visualizzare diversi di questi errori

ERROR Estimate FAILED for table 'ccm12_5_1_16900_48:"informix".

In alcuni scenari è possibile visualizzare un errore NTP

Mar 14 09:51:23 FXSDCWCMFPUB user 4 platform: Response from 'ntpdate -q': server X.X.X.X, stratum 0, offset 0.000000, delay 0.00000#01214 Mar 09:51:23 ntpdate[8646]: no server suitable for synchronization found.

Soluzione

Passaggio 1. Riavviare il servizio Cisco Tomcat (utility service restart Cisco Tomcat) dalla CLI.

Il riavvio di Cisco Tomcat implica che funzionalità quali Extension Mobility, il portale Self-Care, l'interfaccia utente di CUCM e l'accesso degli utenti non sono accessibili quando il servizio è inattivo.

Dopo il riavvio del servizio, la GUI impiega circa 5 minuti per essere disponibile; si prevede quindi un errore 404 Not Found.

Passaggio 2. Aggiungere il dispositivo SIP Trunk a CUCM.

Passaggio 3. Se il passaggio 2 non viene completato correttamente, riavviare il servizio A Cisco DB nel nodo di pubblicazione CUCM tramite la CLI (utilizza il servizio per riavviare un database Cisco),

Tenere presente che quando si riavvia Un database Cisco nel server di pubblicazione, tutti i database vengono riavviati, pertanto non è possibile configurare o aggiungere funzionalità e configurazioni nei server CUCM e il tentativo di aggiungere o configurare qualsiasi elemento nei server può andare perduto dopo il ripristino del servizio e la nuova configurazione di tutti i database, poiché tutti i database dei sottoscrittori diventano di sola lettura mentre il servizio A Cisco DB è in modalità di riavvio.

Tuttavia, è possibile effettuare chiamate telefoniche, poiché queste informazioni sono memorizzate nel database in memoria come di sola lettura, è possibile configurare i gruppi di gestione delle chiamate specificamente a scopo di failover, che dipende dal nodo che si desidera riavviare, in modo che i telefoni vengano mantenuti registrati.

Passaggio 4. Dopo aver riavviato il servizio A Cisco DB in tutti i nodi, attendere circa 15-20 minuti, quindi aggiungere il trunk SIP.

Passaggio 5. Se il problema persiste dopo il riavvio di Cisco Tomcat e A Cisco DB nel server di pubblicazione, riavviare i servizi nei nodi del Sottoscrittore destinati all'elaborazione delle chiamate.