ASO update of attribute associations causes Data to be "converted"?

Question

Has anyone seen the issue in 11.1.2.3(.506) where associating attributes  with a dimension causes Essbase to reorganize the data (it is referred to as convert)?
e.g.
import database app.db dimensions connect as user identified by password using server rules_file 'DimFuel' on error write to '/essapp/subject/sos/logs/sosp04_dims.build_dim_sosp04_sosp04_dimopen.20150429011053.err':
  OK/INFO - 1270086 - Restructuring converted [5.72103e+08] input cells and removed [0] input cells.
  OK/INFO - 1270087 - Restructuring converted [32] and removed [0] aggregate views.
  OK/INFO - 1007067 - Total Restructure Elapsed Time : [1944.88] seconds.
Previoiusly this process ran in 3 seconds in 11.1.2.2(.100)

Answer 1

I agree with everything that Tim has said.  Let me elaborate some more that might be helpful: 
The fact that agg views are not based on query tracking makes no difference in the analysis.  Query tracking only affects WHICH views are selected.  Once views are selected by whatever means they are handled in the same way.  Is there a reason you think otherwise?
Let's divide the question into two parts: 
    1.  What is a restructure and Why is a restructure needed?
    2.  Why must the agg views be converted
But first realize there are two possibilities concerning WHICH agg views actually exist:
  a. All views might be on the primary hierarchy only.  (You told Essbase to consider alternate hierarchies when creating aggregates) - let's call that the Agg_Primary option
  b. Views might be based on both primary and alternate (which includes attribute) hierarchies - let's call that the Agg_Any option
All of this is is discussed in my Chapter "How ASO Works and How to Design for Performance" in the book "Developing Essbase Applications" edited by Cameron Lackpour.  You will also find a discussion of the bitmap in the section of the DBAG entitled "An aggregate storage database outline cannot exceed 64 bits per dimension" (Essbase Administrators Guide Release 11.1.2.1 Chapter 62 page 934). and in a presentation I made at Kscope 20120 which you can find on ODTUG.com
1.  Why a restructure?  As Tim says the outline has changed and anytime the number of levels per hierarchy or the width of the hierarchy changes then the coding system used for the data changes.  OK what do i mean by this?  The binary system by which each piece of data in your cube is described is called the "BitMap".  In actuality, this bitmap only reflects the data's position in the primary hierarchy for each dimension.  The primary hierarchy for a specific dimension is not necessarily the first hierarchy seen in your outline.  It is the "widest" hierarchy - the one requiring the greatest number of bits to represent all Level 0 (L0) members found in that hierarchy and each L0's full ancestry within that hierarchy.
If you read the references above you will see that the number of bits used to determine the "widest" hierarchy is a function of the number of levels and the size of the largest "family" in a hierarchy.  A hierarchy of 5 levels where the largest family has 17 members will require 3 bits more than a hierarchy of 5 levels with 4 members in the family (17 requires 5 bits and 4 requires 2 bits).  So you can see that any time you add more members you could be causing the size of the largest family to exceed a power of 2 boundary.
Additionally, if the primary hierarchy is NOT all inclusive - i.e. it contains all L0 members for that dimension then you have to add a sufficient number of bits to enumerate the hierarchies.
So, in summary changes to the width or the height (number of levels) will require a restructure forcing the the identifying bits on every piece of data to be updated.
In the case the OP mentions where the ONLY changes are to add attribute associations you normally would NOT expect to see a change in the bitmap due to the number of bits required.  This is because attribute dimensions can never have new unique L0 members (you can not associate to something that does not exist).  If you go thru the math (and realize that the bitmap for an attribute dimension does NOT have consider size of the L0 families of the primary hierarchy - or whichever Level the association is based on) you will find that there is no possible attribute dimension that can require more bits than the primary hierarchy.  UNLESS you have been sloppy and you have a primary dimension with x L0 members and a very large secondary hierarchy with x-n members UNIQUE L0 members (i.e. L0 members not appearing in the primary hierarchy).
So the answer is to inspect the statistics tab before and after your addition of member associations.
Note - (and this does NOT pertain in the OP's Case) a similar situation exists if all secondary hierarchies contain ONLY members that already exist within the primary hierarchy.  However, remember that the FIRST hierarchy in your outline is not necessarily the primary hierarchy.  Most people however consider the first hierarchy as the de-facto primary.  If one is in a hurry and adds the member to that first hierarchy but does not add it to ALL of the alternate hierarchies (one of which is the true primary), then bits will have to be added to each piece of data to enumerate the hierarchies - thus triggering a restructure.
Finally, I am relying on the OP's description of the conditions where it was stated that ONLY associations were added and that no upper level attribute members created.  If upper level attribute members are added it is possible that the number of levels for the attribute dimension is changed.  In this case a mini restructure would be required - one that would not change the bitmap on every data item but a change to the mapping table that relates alternate hierarchies to the primary hierarchy.  Note the existence of this table and its exact structure is not acknowledged by Oracle - I (Dan Pressman) have postulated it as one possible implementation of the observed functionality.
2.  Aggregate View Conversion:  Each data item is tagged not only with a bitmap indicating its position within each primary hierarchy but with a "View ID".  This is the number that is seen in the ASO version of the .CSC file created whenever the view definition is saved.  The input data is always identified by a View ID of 0.  The view ID of other views is a function of the number of levels and the bits required therefore of ALL hierarchies of ALL dimensions.  Therefore any restructure will require that the View IDs of all aggregate views be translated (or converted) from the old scheme to the new scheme.  Note that this is purely a translation and no aggregation is required.
Please excuse me if I post this now and add some more later on this second question - actually let me know if anyone has actually read this far and is interested.
Please note in the above whenever i have said "Each data item" I am referring to the situation where no dimension has been tagged as the "compression" dimension.  If a compression dimension has been used then replace the phrase "Each data item" with the phrase "each data bundle".  I will leave it to the reader to find the section of the DBAG that describes compression and data bundles.