[cisco-voip] Heads up on CSCsx32588 - impacting all Unity Connection 7.0(1) installs

Mon Jun 7 14:24:19 EDT 2010

Hi All

I have a customer that has hit this bug, I have just tried to upgrade them
to 7.1(2)b but it failed, does anyone know for sure if the upgrade can be
completed once the bug has been hit or do we still need TAC to get the root
access beforehand?

On 13 May 2010 19:36, Kin Wai <kinwai at singnet.com.sg> wrote:

> My only CUCMBE customer faced this problem too. It seems that when it
> happens, customers will face several different behaviors. For me, I'm
> unable
> to delete the user.
>
> The very first reply from TAC is the installation got hit by the bug
> CSCsx32588. Asking me to upgrade to the latest release. However, we got the
> TAC in and applied the workaround, it works fine so far. Coming weekend,
> I'm
> going to upgrade that CUCMBE to the latest release.
>
>
>
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Pat Hayes
> Sent: Thursday, May 13, 2010 10:50 AM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] Heads up on CSCsx32588 - impacting all Unity
> Connection 7.0(1) installs
>
> For anyone running Unity Connection or CUCMBE 7.0(1), please be sure
> to take a look at defect CSCsx32588, it is currently causing a fair
> bit of trouble, see bug notes pasted below. Also documented here:
>
> https://supportforums.cisco.com/docs/DOC-9120
>
> The long and short of it is, you should get to 7.0(1)ES34 or later,
> otherwise you will eventually run into this condition. All releases
> from 7.0(2) and up also contain the fix. Once you are impacted (see
> symptoms), the only way out of it is to call TAC and have them get in
> there with root access to fix it. If you can upgrade prior to that,
> though, you can avoid the whole mess. See the notes in the condition
> section below for how to check your current status if you are running
> an impacted version.
>
> Symptom:
> Some users hear failsafe.
>
> Not able to delete messages. They get deleted but still exsist.
>
> MWI is not working. If you manually try to reset it, you get the
> following error: ISAM error: no free disk space
> Could not reset Message Waiting Indicators
>
> Trying to set traces you get the following error:
> An error occured while saving: java.sql.SQLException
>
> Applog shows the following errors:
> Jan 28 10:52:09 BPTBNVMA070A local7 3 : 971: Jan 28 03:52:09 PM.344
> UTC : %CUC_CSMGR-UCEVNT-3-EvtMiuDBWriterSQLExecError: Media component
> (Miu) DBWriter encountered the following error executing SQL:
> [0x8DBEFEF1] Failed executing stored procedure [0x8DBEFEF1] Error
> 0x8DBEFEF1 [0x8DBEFEF1] DbError: FAILED (hr=0x8dbefef1 IX000 : .
> SprocRequest=[proc='UnityDirDb:csp_VMSServerModify'
> params=[pObjectId='bba07c41-84a1-4a7c-a502-0d02a8b845db'
> pAllowNoNewCalls='0'] reqId='f715f] App ID:CuCsMgr Cluster ID: Node
> ID:BPTBNVMA070A
>
> Saw error in the CuCsMgr log like this:
> 01/28/2009 10:56:28.663
> |10651,AMER-US-CUCM-2-015,1FE25EF2F12D454D89E6C29C123653B9,CsMalUmss,18,
> src=0 desc=IX000 : Could not insert new row into the table. [Class
> IX:IX000] err=-1|
>
> Looks like you can't add anything else to the DB.
>
> CuCsMgr can also show the following errors:
>
> 01/27/2009 18:07:15.984 |13169,,,MiuGeneral,25,Miu DBWriter thread
> error executing SQL: [0x8DBEFEF1] Failed executing stored procedure
> [0x8DBEFEF1] Error 0x8DBEFEF1 [0x8DBEFEF1] DbError: FAILED
> (hr=0x8dbefef1 IX000 : Could not insert new row into the table. [Class
> IX:IX000]). Stored procedure request =
> [proc='UnityDirDb:csp_VMSServerModify'
> params=[pObjectId='bba07c41-84a1-4a7c-a502-0d02a8b845db'
> pAllowNoNewCalls='0'] reqId='f715f8fa-4353-48b5-baef-8d40c7a04769']..
> SQL=[proc='UnityDirDb:csp_VMSServerModify'
> params=[pObjectId='bba07c41-84a1-4a7c-a502-0d02a8b845db'
> pAllowNoNewCalls='0'] reqId='f715f8fa-4353-48b5-baef-8d40c7a04769']|
>
> 01/27/2009 18:07:16.023 |13169,,,-1,-1,Media component (Miu) DBWriter
> encountered the following error executing SQL: [0x8DBEFEF1] Failed
> executing stored procedure [0x8DBEFEF1] Error 0x8DBEFEF1 [0x8DBEFEF1]
> DbError: FAILED (hr=0x8dbefef1 IX000 : Could not insert new row into
> the table. [Class IX:IX000]). Stored procedure request =
> [proc='UnityDirDb:csp_VMSServerModify'
> params=[pObjectId='bba07c41-84a1-4a7c-a502-0d02a8b845db'
> pAllowNoNewCalls='0'] reqId='f715f8fa-4353-48b5-baef-8d40c7a04769']..
> SprocRequest=[proc='UnityDirDb:csp_VMSServerModify'
> params=[pObjectId='bba07c41-84a1-4a7c-a502-0d02a8b845db'
> pAllowNoNewCalls='0'] reqId='f715f8fa-4353-48b5-baef-8d40c7a04769']|
>
>
> Conditions:
> Unity Connection 7.0(1).
> This is fixed in Connection 7.0(1)ES34 and 7.0(2).
>
> To determine if you are hitting this bug refer to the following:
>
> ----------------------------------------------------------------------------
> -----------------------------------------
> There have been situations where a particular database table has
> outgrown its early limits. In situations like this, we can view the
> utilization though a command:
>
> run cuc dbquery unitydyndb select * from vw_tableinformation
>
> This will return a table of all the tables in unitydyndb. To analyze
> the disk utilization, look for the column titled dbspacepagesfree.
> This value should always be greater than zero. If it is close to zero
> then we know a problem is brewing. Another command to issue is:
>
> show cuc dbserver disk
>
> This will return a list of the system partitions. Look for the column
> titled Free MB. This should also always be greater than zero. If it is
> close to zero then we know a problem is brewing. Typically the only
> tables which grow into a state where you would want to check it is the
> dynamic database. In issuing the above two commands, if you see the
> dbspacepagesfree is zero, and the Free MB for dyn and
> /var/opt/cisco/connection/db/dyn_dbs is zero then you are running into
> this defect.
>
> ----------------------------------------------------------------------------
> -----------------------------------------
>
> Workaround:
>
> Contact TAC, requires root access
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100607/32e930b6/attachment.html>