Does MicroStrategy Web support clustering via Cisco Local Router or any other third-party clustering software?
MicroStrategy Web relies on third-party web-clustering software to provide clustering functionality. MicroStrategy Web is designed to be stateless so that each individual MicroStrategy Web node can function without the knowledge of the existence of other nodes. Therefore, any third-party software used to cluster web servers can be used.
What information is shared by the application across MicroStrategy Web nodes?
MicroStrategy Web is designed to be as stateless as possible. Therefore, no information is shared by the MicroStrategy Web application across cluster nodes. All state information for running jobs is pushed to the client browser.
When a report is submitted by a MicroStrategy Web user, the user will receive a wait page in the client browser. This wait page will poll the MicroStrategy Web Server periodically for the status of the report. This polling is performed as new http requests. This http request will contain all state information, including encrypted login information and MicroStrategy Intelligence Server connection information.
Is MicroStrategy Web "cluster-aware"?
The MicroStrategy Web application is designed so that each MicroStrategy Web cluster node does not need to know that it is a member of a cluster. MicroStrategy Web is designed to be stateless, so that each client http request can be processed individually without having to persist information within the MicroStrategy Web application. Therefore, third-party Web-server clustering software can be used to cluster together multiple web servers running MicroStrategy Web.
Should MicroStrategy Web be specifically configured to access a MicroStrategy Intelligence Server cluster?
No. When the administrator configures MicroStrategy Web to access a particular MicroStrategy Intelligence Server, the MicroStrategy Web application will automatically detect that the MicroStrategy Intelligence Server is a member of a cluster. Once this detection is made, MicroStrategy Web will automatically add all the other members of the same cluster into the pool of available MicroStrategy Intelligence Servers.
Tuesday, November 18, 2008
MICROSTRATEGY INTELLIGENCE SERVER CLUSTERING
What information is shared by the application across MicroStrategy Intelligence Server nodes?
Report caches are shared in a cluster and Object caches on each MicroStrategy Intelligence Server node are synchronized.
Is a copy of each report cache retained in each MicroStrategy Intelligence Server node?
No. Each MicroStrategy Intelligence Server retains a lookup table with information about the existence and location of report caches. When a cluster node creates a report cache, information about the location of the new cache is shared with the other cluster nodes. Each cluster node then updates its own lookup table with the location of the new cache.
If a MicroStrategy Intelligence Server node crashes, will report caches be lost?
Although report caches will not be lost, access to report caches may be affected, depending on the way in which the report cache is configured.
If a separate file server is used as a common report cache repository for all MicroStrategy Intelligence Server cluster nodes, then the loss of a cluster node will not affect access to the report cache by other nodes.
If the cluster is configured such that each node locally hosts the report cache created by that node, then those report caches residing in the lost node will naturally be inaccessible. If any report cached in that lost node is requested, then another node within the cluster will re-run and re-cache the report. When the cluster node is recovered and rejoined into the cluster, all report caches in that cluster node will be made available again to the rest of the cluster.
If a MicroStrategy Intelligence Server node is removed from a cluster manually, will report caches be lost?
If an administrator removes a cluster node from a cluster, then all report caches that had been created by that cluster node will be inaccessible by the rest of the cluster, whether or not a separate file server is used as a common report cache. This behavior is by design.
How does MicroStrategy Intelligence Server 7.0 clustering enable cache sharing?
Each node in a MicroStrategy Intelligence Server 7.0 cluster maintains indices of the caches available on the different nodes. When a report is submitted, these indices will be searched and once an existing cache is found (in any nodes), the cached results will be retrieved directly from cache locations in either the local or remote machine.
What methods can be used to guarantee availability of the MicroStrategy Intelligence Server report cache?
To prevent the loss of a MicroStrategy Intelligence Server cluster node from affecting report cache availability, the cluster can be configured such that a separate file server is used as a common report cache repository. In order to maintain cache availability, this separate file server can be configured for failover with third-party clustering software.
a report cache is created by a MicroStrategy Intelligence Server cluster node, will that report cache be seen in the Cache Monitor of another cluster node?
No. Although the new report cache will be available for use by other cluster nodes, the cache will not appear in the Cache Monitor of other cluster nodes. In order to see all report caches within a cluster, the administrator will need to create a separate data source within Desktop for each cluster node. Then, the report caches within each node can be administered separately, using the same instance of the MicroStrategy Desktop application.
objects are created, modified or deleted, will the change be reflected across all MicroStrategy Intelligence Server cluster nodes?
Yes. Object caches are synchronized across all cluster nodes. If any change affecting the Metadata is made by one cluster node, then the cluster node broadcasts the change to the other cluster nodes. The other cluster nodes will then update their local object caches.
NOTE: Client-side object caches will not be automatically be refreshed. In MicroStrategy Desktop, for example, a user may have to explicitly click on 'Refresh' to see an object change be reflected in the client application.
Should all MicroStrategy Intelligence Server cluster nodes be configured identically?
Technically, MicroStrategy Intelligence Servers in a cluster do not have to be configured identically. The only technical requirements are that all MicroStrategy Intelligence Servers point to the same metadata and that all MicroStrategy Intelligence Servers have the same projects registered and in the same state (i.e., if Node A has Project A in a 'Loaded' state, then Node B must also have Project A in a 'Loaded' state.).
However, in order to ease administration and to reduce the risk of unbalanced load across cluster nodes, it is recommended that all nodes use the same MicroStrategy Intelligence Server definition and that each machine shows identical characteristics (i.e., equal RAM, hard disk space, CPU).
Is it possible for different nodes of a MicroStrategy Intelligence Server cluster to run against different metadata repositories?
No, all the nodes in the same cluster must run against the same metadata.
Is it possible for different nodes of a MicroStrategy Intelligence Server cluster to run with different configuration settings under the same metadata repository?
Yes this is possible, using caution because users can configure different nodes at different settings. For example, differences in memory allocation for the cache, time out settings, etc can result in uneven performance across cluster nodes.
What communication protocol does MicroStrategy Intelligence Server use for intracluster communication?
MicroStrategy Intelligence Server 7.0 and MicroStrategy Intelligence Server 7.0 SP1 use TCP/IP when communicating between clusters. MicroStrategy Intelligence Server 7.1 will provide the option of using TCP/IP or UDP/IP (Universal Datagram Protocol). In 7.2, UDP support was removed as packet loss affects cluster synchronization.
If a MicroStrategy Intelligence Server cluster node is rebooted, will the node rejoin the cluster automatically?
Whenever a MicroStrategy Intelligence Server cluster node is stopped in any way besides explicitly shutting down the MicroStrategy Intelligence Server service, the node will automatically rejoin the cluster when the MicroStrategy Intelligence Server service is restarted. So, if the node crashes, then the node will rejoin the cluster automatically upon startup.
NOTE: All cluster nodes must have the same projects loaded. Therefore, MicroStrategy Intelligence Server must be configured to have the appropriate projects automatically load upon startup so that the node can successfully rejoin the cluster upon startup.
If the cluster node is stopped by explicitly shutting down the MicroStrategy Intelligence Server service (either through the MicroStrategy Desktop interface, the Windows Services window, or the MicroStrategy Service Manager), then the administrator must manually add the node back to the cluster when the node is restarted. This is by design. Since stopping the MicroStrategy Intelligence Server service requires intervention of the administrator, this behavior allows administrators to retain control over the MicroStrategy Intelligence Server application when the application is restarted.
Does MicroStrategy Intelligence Server support clustering via Microsoft Cluster Server or any other third-party clustering software?
Microsoft Cluster Server (MSCS) can be used for failover of MicroStrategy Intelligence Server. However, MSCS and other third-party clustering software will not provide the load-balancing and some of the failover capabilities of MicroStrategy Intelligence Server's native clustering solution.
Is it possible to run multiple instances of MicroStrategy Intelligence Server on the same Microsoft Windows NT machine?
MicroStrategy 7.0 does not support running multiple instances of MicroStrategy Intelligence Server on the same Microsoft Windows NT machine. This is because MicroStrategy Intelligence Server can support running multiple projects with different prioritization and configuration settings on one server. This functionality was not available in MicroStrategy DSS Server 5.x and thus, required running multiple instances of MicroStrategy Intelligence Server to accomplish the same functionality.
What is the maximum number of nodes that can be supported in a MicroStrategy Intelligence Server 7.0 cluster?
There is no technical hard limit on the maximum number of cluster nodes that can be supported by MicroStrategy Intelligence Server 7.0. However, when the number of nodes increases, there is increasing overhead put on the system by the clustering software. So, there will be practical limits related to the hardware configuration of the users' system.
MicroStrategy Intelligence Server 7.0 Caching FAQ
How is caching different and/or improved in MicroStrategy 7.0?
The MicroStrategy 7.0 architecture offers greatly improved caching support with respect to administration, security, prompting and subsetting.
There are three types of requests for which MicroStrategy 7.0 uses caching to improve response times:
- Metadata object requests. Frequently used metadata objects (i.e., templates, filters, reports, metrics, custom groups, consolidations, attributes, etc.) are stored in memory, in addition to the metadata repository, so they can be retrieved more quickly.
- Lookup table element requests. Frequently used lookup table elements are stored in memory, in addition to the warehouse database, so they can be retrieved more quickly.
- Report execution requests. Pre-calculated and pre-processed report results are stored in memory, and on disk, so they can be retrieved more quickly than re-executing the request against the warehouse database.
Space limits for caching are created when a project is initialized. In two-tier mode, an object and element cache exists in memory on the client for each project that the client accesses. In three-tier mode, for each project an object, element and report cache exists on the server (in memory for all and also on disk for report requests), and only an object and element cache exists in memory on the client. MicroStrategy 7.0 also provides strong cache administration functionality, including cache backup, cache loading and/or unloading from memory, cache updating, cache expiration, cache invalidation, and cache status.
Cache retrieval is affected by multidimensional security. Multidimensional security (also knows as the security filter) is the feature set that allows a data filter to be assigned to a project-user combination. Whenever a user runs any report within a given project, the security filter is applied to the underlying query. When a report request hits a report cache, the cache-matching algorithm accounts for the user of security filters.
Caching has also been improved to support prompts. When a report is cached, it is indexed by the answers to the prompts used for the report. In order to retrieve results from the cache, a report request must include the exact same prompt answers as the execution that created the cache. When using server caching, the user is prompted for prompt answers before the cache-matching algorithm checks for a cache match. A common usage scenario is to be able to have a prompted report use the cache, regardless of what the user requests.
What types of flat files does the report cache on the MicroStrategy Intelligence Server 7.0 create? Are they accessible from other tools?
Report caches stored on disk on the MicroStrategy Intelligence Server 7.0 are in a preprocessed, proprietary format. Therefore, they are not accessible by means other than the MicroStrategy COM API. Datamarting is implemented in MicroStrategy Intelligence Server 7.1 to address this requirement. Element and Metadata Object caches only exist in memory and are not stored on disk, unlike Report caches.
Can a SQL generation request be cached?
Yes, a SQL generation request can be cached. The next time the same report is run, the SQL is retrieved from the cache instead of being generate at the runtime.
Is there a setting that can control the client side cache?
There are no exposed settings regarding the client side cache.
Is there an expiration time for the different caches?
For the report cache default, the expiration time is 24 hours, but it is configurable up to 999,999 hours. For element cache and object cache there is no expiration time setting. The only ways of removing them are either purging the caches from the project configuration or restarting the MicroStrategy Intelligence Server.
Will Cache files be created when Caching is turned off at the Project Configuration?
If the History List (Inbox) is enabled, cache files will still be created.
MicroStrategy Administrator - Object Manager Frequently Asked Questions (FAQ)
What functionality is contained in MicroStrategy Administrator - Object Manager 7.x and 8.0.x?
MicroStrategy Administrator - Object Manager allows users to perform the following actions:
- Duplicate and upgrade projects
- Copy objects within and across related projects
- Move objects within a project
- Delete objects within a project
- Rename objects within a project
- Search for objects within a project
- Find an object's parents or children within a project
Are there any special requirements needed to move objects across projects?
Yes. In order to perform cross-project operations, the projects involved must originate from the same source project. In other words, the projects can only be related by the duplication of a single project. This ensures that the projects have a similar set of schema and application objects, and that the object ID's in the two projects are the same. MicroStrategy Object Manager uses the object and version ID's across the projects to perform comparisons. MicroStrategy Object Manager prevents the user from attempting operations across unrelated projects.
How does MicroStrategy Object Manager determine if two projects are related?
MicroStrategy Object Manager compares the Schema ID's of the two projects. Duplicated projects have different Project ID's, but their Schema ID's are the same.
What happens if a user tries to move objects between two unrelated projects?
If a user tries to perform cross-project operations between two unrelated projects, MicroStrategy Object Manager will not permit the operation and will display the following error:
Objects cannot be copied across the projects because these two projects, "Project name of the source" and "Project name of the destination", have not been created from the same source. For more information see Chapter 4: Managing Your Applications, in the System Administration Guide.
What is the Conflict Resolution Window?
The Conflict Resolution window provides the user with a means to decide how to handle object conflicts between the source project and the destination project. In addition, the Conflict Resolution window displays the object name in the original project, the object name in the destination project and the type of conflict. Users may also specify a new name for the object depending on the action chosen. A sample of the Conflict Resolution grid is shown below:
How does MicroStrategy Object Manager determine if two objects in different projects are the same?
To determine if two objects are the same, MicroStrategy Object Manager compares their Object ID's. If these ID's are the same, MicroStrategy Object Manager then compares the Version ID's. If the Version ID's are the same, the Conflict Resolution grid lists the conflict as 'Exists Identically.' If the Version ID's are different, the Conflict Resolution grid lists the conflict as 'Exists Differently.'
How can the user determine the Object ID of an object?
To view the Object ID of an object, right-mouse click on the object and select 'Properties.' The Object ID and Version ID are listed on the 'General' tab.
Why does MicroStrategy Object Manager search for object dependencies?
MicroStrategy Object Manager makes a list of all object dependencies before copying an object to prevent metadata inconsistency. The time required for dependency checking varies based on a customer's metadata size and schema complexity. For large metadata and complex schemas, gathering all the dependencies may take a long time.
Can schema objects be copied across projects with MicroStrategy Object Manager?
Yes, schema objects can be copied across projects using MicroStrategy Object Manager. MicroStrategy Object Manager moves objects seamlessly between similar projects such as from a development project version to a production project version where the warehouses are the same in terms of views, prefixes, and warehouse structure. However, subtle changes in the warehouse that relate to prefixes, views, or table structure cannot be tracked by MicroStrategy Object Manager. For situations where the projects' warehouse structures or setups are dissimilar, users may be required to make further edits of the objects to ensure full integration into the destination project. These edits may include hierarchical relationship changes or modifications to the prefixes.
How does MicroStrategy Object Manager integrate with the MicroStrategy Product Suite security model?
Security in MicroStrategy Object Manager is based on the MicroStrategy 7.x Product Suite security model. All activities that can be performed in MicroStrategy Object Manager are governed by privileges and access control lists. For example, if a user is not allowed to access a certain folder in MicroStrategy Agent, they will not be able to access the folder in MicroStrategy Object Manager.
Is it possible to use MicroStrategy Object Manager while other users are making changes in MicroStrategy Agent?
Using MicroStrategy Object Manager to copy/move objects around is not recommended while other user sessions are making changes using MicroStrategy Agent, as it could lead to metadata inconsistency. Project and schema locking prevent multiple users sessions from manipulating the schema at the same time. This prevents metadata inconsistency from occurring.
What are the tracing options available in MicroStrategy Object Manager?
Tracing is available under the Tools/Diagnostics menu. These tracing options apply to every MicroStrategy product installed on the machine.
To see the SQL that has been executed against the metadata, go to the Advanced tab and turn on 'SQL Tracing' under the DSS MDServer key.
Function level tracing can be accomplished by going to the Advanced tab and turning on 'Function Level Tracing' under the DSS ObjectManager key.
Where are dependent objects copied if they do not already exist in the destination project?
If the location exists in the destination project, the dependent object is copied to that location. If the location does not exist in the destination project, a new folder entitled 'Dependencies' is created and the object is copied to that folder.
What happens if the owner of an object does not exist in the destination project?
If the owner of the source object does not exist in the destination project, the user login for the destination project takes ownership of the object when it is copied or replaced.
Where can users find more information on MicroStrategy Object Manager?
Further information can be found in the release notes, as well as in MicroStrategy Object Manager's online help.
Monday, November 17, 2008
DWHInterview Questions
1. What is the difference between view and materialized view?
View - store the SQL statement in the database and let you use it as a table. Every time you access the view, the SQL statement executes.
Materialized view - stores the results of the SQL in table form in the database. SQL statement only executes once and after that every time you run the query, the stored result set is used. Pros include quick query results.
2. Can a dimension table contain numeric values?
Yes. But those data type will be char (only the values can numeric/char)
3.What are the data types present in bo? what happens if we implement view in the designer n report
Three different data types: Dimensions, Measure and Detail.
View is nothing but an alias and it can be used to resolve the loops in the universe.
4. What is ER Diagram?
The Entity-Relationship (ER) model was originally proposed by Peter in 1976 [Chen76] as a way to unify the network and relational database views.
Simply stated the ER model is a conceptual data model that views the real world as entities and relationships. A basic component of the model is the Entity-Relationship diagram which is used to visually represents data objects.
Since Chen wrote his paper the model has been extended and today it is commonly used for database design For the database designer, the utility of the ER model is:
it maps well to the relational model. The constructs used in the ER model can easily be transformed into relational tables.
it is simple and easy to understand with a minimum of training. Therefore, the model can be used by the database designer to communicate the design to the end user.
In addition, the model can be used as a design plan by the database developer to implement a data model in a specific database management software.
5.What is a surrogate key and where do you use it?
It is just a unique identifier or number for each row that can be used for the primary key to the table. The only requirement for a surrogate primary key is that it is unique for each row in the table.
Example:
Another benefit you can get from surrogate keys (SID) is :
Tracking the SCD - Slowly Changing Dimension.
Let me give you a simple, classical example:
On
If you used the natural business key 'E1' for your employee within your datawarehouse everything would be allocated to Business Unit 'BU2' even what actualy belongs to 'BU1.'
If you use surrogate keys, you could create on the 2nd of June a new record for the Employee 'E1' in your Employee Dimension with a new surrogate key.
This way, in your fact table, you have your old data (before 2nd of June) with the SID of the Employee 'E1' + 'BU1.' All new data (after 2nd of June) would take the SID of the employee 'E1' + 'BU2.'
You could consider Slowly Changing Dimension as an enlargement of your natural key: natural key of the Employee was Employee Code 'E1' but for you it becomes
Employee Code + Business Unit - 'E1' + 'BU1' or 'E1' + 'BU2.' But the difference with the natural key enlargement process, is that you might not have all part of your new key within your fact table, so you might not be able to do the join on the new enlarge key -> so you need another id.
6. Difference between Snow flake and Star Schema. What are situations where Snow flake Schema is better than Star Schema to use and when the opposite is true?
Star schema contains the dimension tables mapped around one or more fact tables.
It is a demoralized model. No need to use complicated joins. Queries results facility.
Snowflake schema
It is the normalized form of Star schema. contains in-depth joins ,because the tables r spitted in to many pieces. We can easily do modification directly in the tables. We have to use complicated joins, since we have more tables. There will be some delay in processing the Query.
7. What is the main difference between schema in RDBMS and schemas in DataWarehouse....?
RDBMS Schema
* Used for OLTP
* Traditional and old schema
* Normalized
* Difficult to understand and navigate
* Cannot solve extract and complex problems
* Poorly modeled
DWH Schema
* Used for OLAP systems
* New generation schema
* De Normalized
* Easy to understand and navigate
* Extract and complex problems can be easily solved
* Very good model
8. What is Data Mart ?
A data mart is a repository of data gathered from operational data and other sources that is designed to serve a particular community of knowledge workers. In scope, the data may derive from an enterprise-wide database or data warehouse or be more specialized. The emphasis of a data mart is on meeting the specific demands of a particular group of knowledge users in terms of analysis, content, presentation, and ease-of-use. Users of a data mart can expect to have data presented in terms that are familiar.
9. What the definition is of normalized and de normalized view and what are the differences between them?
Normalization is the process of removing redundancies.
Denormalization is the process of allowing redundancies.
10. What is meant by metadata in context of a Datawarehouse and how it is important?
11. What is a linked cube?
Linked cube in which a sub-set of the data can be analyzed into great detail. The linking ensures that the data in the cubes remain consistent.
12. What is junk dimension? what is the difference between junk dimension and degenerated dimension?
Junk dimension: Grouping of Random flags and text attributes in a dimension and moving them to a separate sub dimension.
Degenerate Dimension: Keeping the control information on Fact table ex: Consider a Dimension table with fields like order number and order line number and have 1:1 relationship with Fact table, In this case this dimension is removed and the order information will be directly stored in a Fact table in order eliminate unnecessary joins while retrieving order information..
Subscribe to:
Posts (Atom)