Error while unarchiving MDM Repositories

[Former Member]

Hi All,

We are trying to unarchive all our repositories but we are receiving below error:

Error writing Lob Data to table A2i_CM_XMLSchema

$$$ Operation ended in ERROR : 84020008H : Database binary object error.

Dropping failed target Repository [12/09/10 07:59:10]

All repository data has been deleted in the database. There are no xsd files saved in the repository. And I am sure that the archived copies are not corrupted as I have successfully unarchived the repositories on the other database (on the same server).

The directory where the a2a files are stored has 3GB free space. We are using Oracle database and the connection is working fine as I am able to create new repository. But when I tried to unarchive repositories, it will encounter the same error.

We have tried to restart the MDM services, then the server and the database but the error is still the same.

Any help is greatly appreciated.

Thanks!

Lhyn

[Former Member]

Hi Arlene,

Can you please check if you have access to make changes in this database system.

Case may be that you do not have access to write data in Database tables and it is stopping you from unarchiving. Please check and let me know.

Thanks and Regards,

Ankush

[Former Member]

Hi Ankush,

Thank you so much for replying. I am using the default Oracle user "system" so I am sure that we have all the proper permissions needed to create new database. Though we will double check this with our oracle support.

Please let me know if you have another suggestion you could provide as we really need to resolve the issue asap. We have tried everything we can and all possible resolution (except for reinstalling the oracle server) but we are still encountering the same error. Do you think the database has been corrupted or something?

Thanks!

[Former Member]

Hi Arlene,

The error message that you have pasted shows some problem in the XML Schema table itself.

Can you please try below:

Unarchive the repository in some other database.

Execute "Verify Repository" command in console and check report.

Also try to delete all the content from XML Schema table once again.

Then archive this repository after unloading it.

And then try unarchiving this repository in your database. Check if this works.

Please let me know. Thank you.

Regards,

Ankush Bhardwaj

[Former Member]

Hi Ankush,

I have already tried this and nothing works.

Unarchive the repository in some other database. >> this is successful. as a workaround, the business is accessing the repositories thru the other database.

Execute "Verify Repository" command in console and check report. >> when i execute verify repository, there are no error in the log.

End of verifying DB schema of repository 'R17_Packaging' on 'MU2.WORLD' (rc=00000000: No error...)

0 of 0 fatal error(s) corrected, 0 of 0 non-fatal error(s) corrected, 0 of 0 warning(s) corrected.

Also try to delete all the content from XML Schema table once again. >> there are no existing schema in the original database

Then archive this repository after unloading it.

And then try unarchiving this repository in your database. Check if this works. >> we are encountering the same error.

Thanks!

[Former Member]

Hi Arlene,

Kindly check the contents of A2i_CM_XMLSchema at database level as well.

It might be the case that some data would have been deleted but memory is not de-allocated for those XSDs.

If this does not work out, then you can try re-installing Database once.

You should Stop/start in following sequence:

Stop MDM server

Stop DB server

Start DB server

Start MDM server

Kindly check if this helps you to solve it.

Thank you.

[Former Member]

Hi Ankush,

We are unable to check the contents of the table A2i_CM_XMLSchema as we have no option to view the contents.

Reinstalling of database is not included in our options as the unarchiving is working before. Also, we need a strong justification and cause of error to push the installation of database.

Thanks.

[Former Member]

Hi Arlene,

This error could be because of corrupt xml schemas.

Now as you said there are no schemas then it makes sense when Ankush says to take a complete restart of the server.

Please test again once you have take a complete Server restart in the sequence as mention above.

Thanks,

Ravi

[Former Member]

Hi Ravi,

Thank you for assisting. We have already tried to restart the server using the sequence mentioned above. We have also requested to restart the whole server and the database but we are still encountering the same error.

If you said that the error is because of corrupted xml schemas, what would be the cause of this? And what do we need to do to resolve the issue?

I am kinda skeptic that the schema is corrupted as I have mentioned, we are able to unarchive the repositories in different database successfully. I have verified the repository and there is no error found. I have tried to archive these repositories then unarchive to the original database but the error is the same.

Do you have more ideas regarding the error?

Thanks!

[Former Member]

Hi Arlene,

In the previous post you had mentioned the following - "Also try to delete all the content from XML Schema table once again. >> there are no existing schema in the original database"

By this I understand that there are no xml schemas in your repository,are we on same page?

So going by the same logic unarchive process should work,which actually holds true for the other database.

Testing the same process for repository with xml schemas would give you a sure test for that.

Coming to 2nd part of your question the above error is caused due to the inability of the Oracle server to accommodate the repository in one data file. The maximum data file which can be created depends on the db_block_size initial configuration parameter. For an 8192 block size (default installation) the maximum data file would result in 32GB.

The way to cause MDM to create more than 1 data file for its new

repositories is to add the following parameter to the global section in

the mds.ini file:

Oracle Tablespace Files=x

Where x is the actual number of files that should be created.

Oracle Tablespace Files -  Number. When an MDM repository is created, determines how many files are used for each repository partition. This allows the repository to grow beyond the default file limit. This limit is a function of block size times 4,194.303 which for the default block size of 8KB is 32GB. Block size is determined when the database is created; if you expect to exceed that limit, set this greater than one so that MDS will handle the growth automatically, saving your DBA the trouble of adding tablespace files later. Default is 1

Thanks,

Ravi

Message was edited by: Ravi Verma

[Former Member]

Hi ravi,

Yes, there are no schemas in the original database as we have deleted all related database files prior to unarchiving the repository. This is working before and we are encountering no error.

I have already tried the ff but all fails with the same error message:

- directly unarchive the repositories

- create a new repository then unarchive

- create a new repository, import xml schema, unarchive

- unarchive the repository on other database, archive the repository then unarchive on the original database.

As for the mds.ini file, I have check the paramater Oracle Tablespace Files and the value is 1. I am not sure if this should be the correct value of this parameter, do you have any ideas?

Thanks!

Arlene

[Former Member]

Hi Arlene,

I have added those details to my above post please have a relook.

It would be best to decide based on the archive file size and test.

1 is default value.

Thanks,

Ravi

[Former Member]

Hi Ravi,

We have checked the a2a file and dbf files created and the size of these files are only ~500mb. So I think there is no need to change the value of the paramater.

Below is a screenshot of one of the tables that is encountering the same error. I am not familiar with BLOB or EMPTY_BLOB() syntax in oracle, but I hope this could help to isolate the issue.

Additionally, below is a part of the trace when I have tried to unarchive a repository on the original database just a while a ago:

<Trace Level="MIN">

<Time Millis="1347962165049">2012-09-18 10:56:05.049+01:00</Time>

<Server Format="IP">dcbsmdm***.guww.net</Server>

<LogText><![CDATA[loading of the new cache failed (err = -11041)]]></LogText>

<Source FileName="./../../../../src/plugins/CorePlugin/win/WinRegistryCache.cpp" Method="WinRegistryCache::build()" Line="149"/>

<Thread>648</Thread>

<Process>8492</Process>

</Trace>

Hope you could help me on this issue!

[Former Member]

Hi Arlene,

Thanks for the updates.

I would recommend to set Oracle Tablespace Files= 2 in the test server and check if the error persists.

Although I agree with you that archive size is much less than what is allowed still I think there could some limitation (particular table size may be) which possibly is not allowing the process to complete.

The above trace is more about a registry related run time error.

If you have a test environment I this test would not take long and we can eliminate this solution post that.Please update your findings.

Thanks,

Ravi