none
The specified metaverse schema has too many attributes RRS feed

  • Question

  • Hi!

    Recently I setup our environment for FIM 2010 Implementation. I used several Powershell scripts to import attributes to both FIM Sync Service and FIM Service. But during importing the attributes for FIM Sync, I received this error:
    "Update metaverse schema failed."
    "The specified metaverse schema has too many attributes."

    I tried manually adding attribute in Metaverse Designer, but I receive the same error. I restarted the service (didn't solve), tried restarting the server itself, still the same error.

    This is seriously blocking me currently and couldn't find anything userful or solution in the Internet right now. Kindly help if you know the solution or the problem. FYI, I checked the FIMSynchronization database, mms_metaverse table, I only have 200 columns.


    Monday, December 2, 2013 8:53 AM

Answers

  • Joseph,

    In your email you mentioned that you read: 

    http://blog.ilmbestpractices.com/2013/02/secrets-of-metaverse-part-3.html

    You also said that you only have 200 custom string indexable attributes and another 15 attributes. Which is clearly less than the 502 limit I calculated. 

    I would run a SQL Profiler trace to confirm on which of the 5 tables this is failing and what the specifics of the error message are.

    Something like this:

    Creating or altering table '%.*ls' failed because the minimum row size would be %d, including %d bytes of internal overhead. This exceeds the maximum allowable table row size of %d bytes.

    Of course the table name will be there as will the %d's be replaced with #'s


    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Monday, December 2, 2013 5:13 PM

All replies

  • Joseph,

    In your email you mentioned that you read: 

    http://blog.ilmbestpractices.com/2013/02/secrets-of-metaverse-part-3.html

    You also said that you only have 200 custom string indexable attributes and another 15 attributes. Which is clearly less than the 502 limit I calculated. 

    I would run a SQL Profiler trace to confirm on which of the 5 tables this is failing and what the specifics of the error message are.

    Something like this:

    Creating or altering table '%.*ls' failed because the minimum row size would be %d, including %d bytes of internal overhead. This exceeds the maximum allowable table row size of %d bytes.

    Of course the table name will be there as will the %d's be replaced with #'s


    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Monday, December 2, 2013 5:13 PM
  • In addition to David's answer, I read that removing a column in a table will not completely free-up the memory being used by that column (I think a general idea in SQL Server database).
    So using SQL Server Management Studio, Right-click on mms_metaverse > Script table as... > Drop And Create To... > Editor

    This is to recreate the table. I perform the same to mms_metaverse_lineagedate, mms_metaverse_lineageguid, mms_metaverse_multivalue just to be sure.

    And now it's working! I can add more custom attributes in Metaverse Designer.

    So you can do it at your own risk. Anybody can correct me if there's something wrong to what I did. Hope to help someone someday. Thanks.

    Tuesday, December 3, 2013 7:18 AM
  • Joseph,

    I am glad you got it working. As you point out directly modifying the SQL tables is not supported by MSFT and definitely a risk. Did you run profiler? Which table was causing the issue?

    Had you deleted a bunch of attributes?

    Dropping and recreating tables of course loses your data unless you scripted keeping the data by putting it into temp tables. Still not something to attempt on a production system.

    If the physical storage of the data was the issue then rebuilding the clustered indexes (a supported move) would probably have also solved the problem.


    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Tuesday, December 3, 2013 6:12 PM
  • Joseph

    We too have observed this in a very critical environment using 4.1.3441.0. We may also give your solution an attempt and let you know what happens

    We are unsure as to how the environment got in such a state but glad to know it isn't just us

    Matt


    Wednesday, December 4, 2013 12:53 AM
  • Ah, except that dropping the tables means we would lost our current metaverse. This may not be ideal... we'll have to see. If anyone else has any better suggestions, please let us know :)
    Wednesday, December 4, 2013 1:42 AM
  • We did resolve this issue by creating clones of the metaverse tables, inserting all the data into them, and renaming them back to the FIM names of the table (no data loss). We have since been able to have over 300+ attributes, as expected.
    • Proposed as answer by Matt Clark IdM Wednesday, December 4, 2013 11:15 PM
    Wednesday, December 4, 2013 11:15 PM
  • Hi All,

    The solution I did before (directly modify the database) works to solve the current issue but just for a short time. After that, I see some "Critical" error messages that seems caused by my previous action. Using the SQL Profiler which @David Lundell advised me to use, I am able to see that some operations are affected (ex: missing index, and some weird sql error messages).

    So clearly, my previous action was not a good idea at all. What I did, I backed-up my current setup (Export Server Configuration, and the database also). Then I uninstalled FIM Synchronization Service, deleted the database "FIMSynchronizationService" (but not the backup of course!). Then re-install FIM Sync Service, import my server configurations (MAs and mv schema), then that's it! I have no more weird errors. And I can add many attributes also.

    PS: I did this in our Dev environment so risks are lesser and experiments are more justifiable.

    Thursday, December 19, 2013 4:10 AM
  • Joseph,

    Thanks for reporting back on what you did. Interesting that a reinstall and restore of the backup solved the problem. Those are supported actions. Just to clarify did you restore the SQL Database backup or just reimport the Server Configuration? 

    If the former I would have expected your problems to continue. If the latter I would have expected that would fix the problem but you would have any empty metaverse and connector space.

    For the benefit of others that read this thread: DON'T MODIFY ANY OF THE FIM DATABASES(table structures or values) WITHOUT MSFT SUPPORT if you want to be in a supported state. If you want to mess around with a throw away copy that's up to you.


    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Thursday, January 2, 2014 5:21 PM