VMware Cloud Community
acruizu
Enthusiast
Enthusiast
Jump to solution

Error Connecting to vCenter Server

After a sudden lost of power I got the following error while trying to connect to the vcenter server:

Internal Server Error

2013-05-15 17:47:44,772 | DEBUG    | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | JobManager                     | **** Add activity log: <JOB_VC_START
_CONNECTION> <cloudvcs0(com.vmware.vcloud.entity.vimserver:23b4fe43-1f29-4c6f-adc1-1048b2a8845c)> |
2013-05-15 17:47:44,773 | DEBUG    | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | CJob                           | updateFailedJob(com.vmware.vcloud.ap
i.presentation.service.InternalServerErrorException) with locale=null |
com.vmware.vcloud.api.presentation.service.InternalServerErrorException: Internal Server Error
    at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.onOuterLoopBreakWithException(VcUpdateListenerImpl.java:721)
    at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.outerWaitForUpdatesLoop(VcUpdateListenerImpl.java:633)
    at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.run(VcUpdateListenerImpl.java:343)
Caused by: org.hibernate.exception.GenericJDBCException: could not execute query
    at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:126)
    at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:114)
    at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
    at org.hibernate.loader.Loader.doList(Loader.java:2231)
    at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125)
    at org.hibernate.loader.Loader.list(Loader.java:2120)
    at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118)
    at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1596)
    at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
    at com.vmware.vcloud.inventory.cache.PropertyMapDao.validateOrGet(PropertyMapDao.java:336)
    at com.vmware.vcloud.inventory.cache.PropertyMapDao.bulkValidateOrGet(PropertyMapDao.java:321)
    at com.vmware.vcloud.inventory.cache.PropertyMapDao.bulkValidateAndGetNewer(PropertyMapDao.java:267)
    at com.vmware.vcloud.inventory.cache.InventoryCacheManagerImpl.bulkGetInternal(InventoryCacheManagerImpl.java:418)
    at com.vmware.vcloud.inventory.cache.InventoryCacheManagerImpl.bulkGet(InventoryCacheManagerImpl.java:549)
    at com.vmware.vcloud.inventory.impl.InventoryServiceImpl.processUpdateSet(InventoryServiceImpl.java:931)
    at com.vmware.vcloud.inventory.impl.InventoryServiceImpl.access$300(InventoryServiceImpl.java:145)
    at com.vmware.vcloud.inventory.impl.InventoryServiceImpl$5.run(InventoryServiceImpl.java:860)
    at com.vmware.vcloud.inventory.impl.InventoryServiceImpl$5.run(InventoryServiceImpl.java:826)
    at com.vmware.vcloud.common.persist.ConversationContextExecutor.execute(ConversationContextExecutor.java:46)
    at com.vmware.vcloud.inventory.impl.InventoryServiceImpl.processAndBatchUpdates(InventoryServiceImpl.java:826)
    at com.vmware.vcloud.inventory.impl.InventoryServiceImpl.handleUpdate(InventoryServiceImpl.java:799)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
    at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
    at $Proxy187.handleUpdate(Unknown Source)
    at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.dispatchUpdates(VcUpdateListenerImpl.java:1080)
    at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.innerWaitForUpdatesLoop(VcUpdateListenerImpl.java:925)
    at com.vmware.vcloud.vimproxy.internal.impl.VcUpdateListenerImpl.outerWaitForUpdatesLoop(VcUpdateListenerImpl.java:594)
    ... 1 more
Caused by: java.sql.SQLException: ORA-01555: snapshot too old: rollback segment number  with name "" too small
ORA-22924: snapshot too old

    at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:439)
    at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:388)
    at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:381)
    at oracle.jdbc.driver.T4C8TTILob.processError(T4C8TTILob.java:789)
    at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:436)
    at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:186)
    at oracle.jdbc.driver.T4C8TTILob.read(T4C8TTILob.java:146)
    at oracle.jdbc.driver.T4CConnection.getBytes(T4CConnection.java:2313)
    at oracle.sql.BLOB.getBytes(BLOB.java:319)
    at oracle.sql.BLOB.getBytes(BLOB.java:209)
    at oracle.jdbc.driver.T4CBlobAccessor.getBytes(T4CBlobAccessor.java:464)
    at oracle.jdbc.driver.OracleResultSetImpl.getBytes(OracleResultSetImpl.java:676)
    at oracle.jdbc.driver.OracleResultSet.getBytes(OracleResultSet.java:398)
    at org.hibernate.type.AbstractBynaryType.get(AbstractBynaryType.java:101)
    at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:184)
    at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:173)
    at org.hibernate.type.AbstractType.hydrate(AbstractType.java:105)
    at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2124)
    at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1404)
    at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1332)
    at org.hibernate.loader.Loader.getRow(Loader.java:1230)
    at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:603)
    at org.hibernate.loader.Loader.doQuery(Loader.java:724)
    at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
    at org.hibernate.loader.Loader.doList(Loader.java:2228)
    ... 32 more
2013-05-15 17:47:44,774 | DEBUG    | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | JobString                      | Job object - Object : cloudvcs0(com.
vmware.vcloud.entity.vimserver:23b4fe43-1f29-4c6f-adc1-1048b2a8845c) operation name: JOB_VC_START_CONNECTION |
2013-05-15 17:47:44,842 | DEBUG    | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | CJob                           | No last pending job   : [cloudvcs0(c
om.vmware.vcloud.entity.vimserver:23b4fe43-1f29-4c6f-adc1-1048b2a8845c)], status=[3] |
2013-05-15 17:47:44,846 | DEBUG    | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | CJob                           | Update last job       : [cloudvcs0(c
om.vmware.vcloud.entity.vimserver:23b4fe43-1f29-4c6f-adc1-1048b2a8845c)], status=[3], [5/15/13 5:47 PM] |
2013-05-15 17:47:44,964 | DEBUG    | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | ValidationServiceImpl          | Skipping queuing of validator for co
m.vmware.ssdc.backend.valeventhandler.ProviderVdcVALStateValidator validator since it is a duplicate, current validation queue length: 1 |
2013-05-15 17:47:44,966 | INFO     | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | InventoryServiceImpl           | Received listener stopped for VC 23b
4fe43-1f29-4c6f-adc1-1048b2a8845c |
2013-05-15 17:47:44,966 | WARN     | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | InventoryRecordPurger          | Inventory records purger for 23b4fe4
3-1f29-4c6f-adc1-1048b2a8845c is not active |
2013-05-15 17:47:44,968 | INFO     | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | VcUpdateListenerImpl           | Releasing the ownership of VC proxy
23b4fe43-1f29-4c6f-adc1-1048b2a8845c |
2013-05-15 17:47:44,968 | INFO     | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | VcUpdateListenerImpl           | trying to clear cell instance id on
vc 23b4fe43-1f29-4c6f-adc1-1048b2a8845c (current number of retries 0). |
2013-05-15 17:47:44,969 | INFO     | 23b4fe43-1f29-4c6f-adc1-1048b2a8845cListener (260) | VcUpdateListenerImpl           | VC 23b4fe43-1f29-4c6f-adc1-1048b2a88
45c: Attempt to set cell instance id from 70 to 0 |

Caused by: java.sql.SQLException: ORA-01555: snapshot too old: rollback segment number  with name "" too small

ORA-22924: snapshot too old

I found these two articles in the KB:

VMware KB: The vCloud Director Web UI reports the error: ORA-01555: snapshot too old: rollback segme...

VMware KB: Make sure you have adequate undo tablespace before upgrading a vCloud Director Oracle dat...

I added more space to the undo tablespace, new redologs, also change the retention parameter for all the lobs in the vCloud Scheme without any different result.

Does anyone has an idea about this?

Best regards,

Tags (2)
1 Solution

Accepted Solutions
acruizu
Enthusiast
Enthusiast
Jump to solution

I finally got an answer for the Oracle error.

I did a full export of the vcloud database and detect an error in this table:

ORA-31693: Table data object "VCLOUD"."PROPERTY_MAP" failed to load/unload and is being skipped due to error:

ORA-02354: error in exporting/importing data

ORA-01555: snapshot too old: rollback segment number  with name "" too small

ORA-22924: snapshot too old

This MOS note details this condition:

Export Fails With Errors ORA-2354 ORA-1555 ORA-22924 And How To Confirm LOB Segment Corruption Using Export Utility? [ID 833635.1]

View solution in original post

0 Kudos
8 Replies
IamTHEvilONE
Immortal
Immortal
Jump to solution

Yes, I have heard of this.  The ORA-01555 isn't a VMware error state ... if you already applied the one fix by inserting/updating tables to reduce the amount of simultaneous queries done by vCloud ... there isn't much else that I am aware of to configure in vCloud Director itself.

I would highly recommend engaging Oracle for confirmation of next steps.  Once this issue is addressed, it's entirely possible that you may have to restore a good instance of the DB where we didn't hit error states.

0 Kudos
acruizu
Enthusiast
Enthusiast
Jump to solution

I'm aware of that thank you.

But I'm sure this error is because a table needs to be fixed, not in a physical or logical manner in the database, the database is mounted and open in a consistent state.

I'm looking forward with the Oracle support, but If I can get them at least the DML statement that cause that error is going to be very dificult to move this case.

Thank you for your advice,

0 Kudos
IamTHEvilONE
Immortal
Immortal
Jump to solution

The Oracle Alert log file should also contain  this error state.  vCloud doesn't record precise statements in the logs when in trace mode .... it'll just be a bunch of place holders.  So I couldn't give you an exact query.

But most ORA errors should be cross logged in the alert file.

See here for some examples: Monitoring Errors and Alerts

acruizu
Enthusiast
Enthusiast
Jump to solution

Exactly! And that's another very strange thing, I don't get the error in the alert log or the trace files. So far I know is not in an rollback segment, in the Oracle KB says when you get that error with no name " with name "" too small" is because is a LOB segment.

0 Kudos
IamTHEvilONE
Immortal
Immortal
Jump to solution

Really ... that is odd.  I think the net result of this conversation is the same ... but I am really curious about Oracle's reply for next steps.  then I could document them internally.

0 Kudos
acruizu
Enthusiast
Enthusiast
Jump to solution

I finally got an answer for the Oracle error.

I did a full export of the vcloud database and detect an error in this table:

ORA-31693: Table data object "VCLOUD"."PROPERTY_MAP" failed to load/unload and is being skipped due to error:

ORA-02354: error in exporting/importing data

ORA-01555: snapshot too old: rollback segment number  with name "" too small

ORA-22924: snapshot too old

This MOS note details this condition:

Export Fails With Errors ORA-2354 ORA-1555 ORA-22924 And How To Confirm LOB Segment Corruption Using Export Utility? [ID 833635.1]

0 Kudos
IamTHEvilONE
Immortal
Immortal
Jump to solution

good to know. Smiley Happy

0 Kudos
angelomk
Contributor
Contributor
Jump to solution

Just in case someone runs into the same issue.

Today after an Oracle DB crash, vCloud Director started complaining that it cannot execute queries anymore with the following message:

Internal Server Error

- could not execute query

- ORA-01555: snapshot too old: rollback segment number with name "" too small

ORA-22924: snapshot too old

Backup (expdp) also lead to the same issue with PROPERTY_MAP table.

ORA-31693: Table data object "VCLOUD"."PROPERTY_MAP" failed to load/unload and is being skipped due to error:

ORA-02354: error in exporting/importing data

ORA-01555: snapshot too old: rollback segment number  with name "" too small

ORA-22924: snapshot too old

I engaged VMware support team and their suggestion was to clean up all inventory tables and force vCloud to re-sync back from vCenter.

The procedure goes like this: [ON YOUR OWN RESPONSIBILITY]

1. Make sure you keep latest valid backup of vCloud Director [just in case]

2. Graceful shutdown of all vCloud Director cells

3. Using Oracle SQL Developer connect to Oracle vCloud Director scheme.

4. Run the following queries:

delete from task;

update jobs set status = 3 where status = 1;

update last_jobs set status = 3 where status = 1;

delete from busy_object;

delete from QRTZ_SCHEDULER_STATE;

delete from QRTZ_FIRED_TRIGGERS;

delete from QRTZ_PAUSED_TRIGGER_GRPS;

delete from QRTZ_CALENDARS;

delete from QRTZ_TRIGGER_LISTENERS;

delete from QRTZ_BLOB_TRIGGERS;

delete from QRTZ_CRON_TRIGGERS;

delete from QRTZ_SIMPLE_TRIGGERS;

delete from QRTZ_TRIGGERS;

delete from QRTZ_JOB_LISTENERS;

delete from QRTZ_JOB_DETAILS;

delete from compute_resource_inv;

delete from custom_field_manager_inv;

delete from cluster_compute_resource_inv;

delete from datacenter_inv;

delete from datacenter_network_inv;

delete from datastore_inv;

delete from dv_portgroup_inv;

delete from dv_switch_inv;

delete from folder_inv;

delete from managed_server_inv;

delete from managed_server_datastore_inv;

delete from managed_server_network_inv;

delete from network_inv;

delete from resource_pool_inv;

delete from storage_pod_inv;

delete from task_inv;

delete from vm_inv;

delete from property_map;

commit; --most important one

5. Start up vCloud Director cells and check the cell.log to verify that cells are booting up properly.

6. Login to the web UI and check vCenters status - you should see that the Inventory is being synced.

7. Re-run DB export (expdp)

0 Kudos