|
Does anyone know how is the storage sructure of Analysis
Service. For example: I create one new cube, say sales
cube.
QUESTION:Does anyone know how is the storage sructure of Analysis
Service. For example: I create one new cube, say sales
cube.
1. How can I define the storage location of this database?
e.g. I want to store it in d:\ drive not in default
c:\drive
2. What is the database file names? (e.g. if the database
crash, what should I restore from backup?
3. If the source of the database is SQL Server, then what
is the difference between Analysis Server database file
and SQL server database file.
Sorry if some of my question maybe is not correct. I just
learn Microsoft OLAP.
ANSWER: All dimension and cube information (with one exception) is stored in a
subdirectory tree that can be wherever you want (with one exception).
The subdirectory tree is by default under the directory in which you
installed AS2K, but you can edit this. From the Analysis Manager,
right-click on the server's node, choose Properties..., and then go to
the General tab. You will see the root directory for databases shown
there. After you change it, shut down MSSQLServerOLAPService service,
copy the pre-existing directory tree to this new path, and then re-start
the service to make the changes take effect.
The one exception to the "wherever you want" is that the drive cannot be
a network drive. This will cause the service to refuse to re-start.
The one exception to the cube information storage is ROLAP cube storage,
because the additional aggregation storage used in ROLAP cube partitions
beyond the fact table is kept in the RDBMS that holds the fact table.
It also stores its own metadata (what dimensions and cubes are defined,
for example) in an RDBMS. By default, this is in an Access/Jet-format
file in the installation Bin directory, but this can be migrated into a
SQL Server for better performance, backup, and stability.
Analysis Services stores everything in its own storage except for:
source tables/views, ROLAP partition aggregations, and its own metadata.
It really isn't dependent on SQL Server for anything, and you can use it
pretty much just as easily with source databases like Access, Oracle,
DB2, etc.
|
|
|
|
