Monday, October 14, 2013

OBIEE 11g Support Schema Password Change (DEV_MDS/DEV_BIPLATFORM)


OBIEE 11g DEV_MDS/DEV_BIPLATFORM has been Changed.



I have seen several posts in OTN forum, Need to change passwords supported schemas for OBIEE 11g (MDS/BIPLATFORM).  Some times    it may even get locked and the password expiration default setting of the Oracle RDBMS 11g database.  But once you change this for any reason that is where the fun begins.  The password can be changed using below syntax.



Alter user DEV_BIPLATFROM  identified by  “NEW PASSWORD”

Ex: Alter User DEV_BIPLATFORM identified by  satya1234






Frequently users got locked in database due to this the Web logic services didn’t start up properly. Ultimately the resolve was to update the user account with an unlimited password lifetime grant similar to the PL/SQL code below.  This code below simply sets the default profile with which a user/schema may be associated.









  ALTER PROFILE DEFAULT LIMIT
  FAILED_LOGIN_ATTEMPTS UNLIMITED
  PASSWORD_LIFE_TIME UNLIMITED



But once this is done it actually causes issues with the WLS and OBI system’s ability to connect to those schemas,  Either way both the MDS schema required by Fusion Middleware Control (EM) and the BIPLATFORM schema that controls the OBI Agents..

We need to make changes in both Enterprise Manager(http://satya:7001/em) for Scheduler Configuration and Console http://localhost:7001/console ) for pointing BIPLATFORM and MDS to new schemas .



Login to http:satya:7001/console  and click on Services –> Data Sources .






We have to change the connection pool for the following schemas shown in screenshot.



 Click on Connection Pool

Here we have to give the following parameters .

Password: <Enter the New password)
Confirm Password:< password again)





Similarly do the same for the schema “mds-owsm”  that I highlighted in the previous screenshot .
Now, Stop all the OBIEE services and start it again .
In windows : Start –>All Programs –> Oracle Business Intelligence –> Stop BI Services/Start BI Services .




Scheduler:




 Login to em (http://localhost:7001/em). Navigate to Business Intelligence –> coreapplication and click on Schedular tab here you can find the TNS entry and User and password of the old schemas .

Click on Lock&Edit and change the TNS Entries as per ur database and enter User and Password  of BIPLATFORM .
 






Click on Apply and Activate changes .


After activated the changes you need to restart the all OBIEE services.


Thanks,
Satya Ranki Reddy





Saturday, October 12, 2013

How to install OBIEE 11g Without RCU



OBIEE 11.1.1.7.1 installation Without RCU.



I have several posts in OTN , How  to install OBIEE 11g Without RCU? I found one workaround option but it would be suitable in production/UAT environments.

One of the prerequisites of installing OBIEE 11g is, the installation of two repository schema into a database.

1.      BIPLATFORM : This schema will store Scheduler Tables , Usage Tracking Tables etc..
2.      MDS:  'MDS'  (Metadata Service) is also required for OBIEE installation.

See the tables in below Screen:





These repository schema are created using RCU (Repository  Creation Utility). According to Oracle documentation, this is a required step. During the course of installation, RCU warrants a user with "SYSDBA" privileges to,
v  Create the repository schema accounts and 
v  create new table spaces  or map the existing table spaces to the new schema
v  Grant certain roles and privileges required by the schema. 
In Production environments Bank/Industries organizations have strictly restricted against using accounts with SYSDBA privileges.

Follow the below Steps:


 There is a way to get the repositories installed on to the target database without invoking RCU. This solution requires,
  • A local database (or, the database where you have control/privileges to create table spaces) 
  • Creation of repositories by running RCU on the local database and 
  • Exporting the repositories to the target database.
Please remember, this activity requires coordination and support from DBA team. The entire activity is transparent and should cause little or or no resistance from them to participate.

The installation activity is as follows,
  1. Create two table spaces on the local database (or the database where you have control/privileges to create table spaces) for RCU schema. 
  2. Install repository schema using RCU.
  3. Export the two repository schema.
  4. Note table space name and the schema owner (BIPLATFORM and MDS) names.
  5. Create table spaces and two users, with exact same name, on the target database (This is critical, Oracle uses these exact names)
  6. Grant following system privileges,
    • Connect, Resource, Create Sequence to BIPLATFORM and MDS 
    • Execute privileges on "DBMS_LOCK" to BIPLATFORM
    • Execute on ""DBMS_LOB" to MDS
  7. Use the export dump created earlier to import the data into the schema in the target database, created above.
  8. Following objects need recompilation,
    • procedure:"obi_biplatform"."sddeletestudy"
    •  procedure:"obi_biplatform"."sdcommitstudy"
    • procedure:"obi_biplatform"."sdgetlearningdata"
    • procedure:"obi_biplatform"."sdgetlearningidrange"
    • procedure:"obi_biplatform"."sdlearningmappingcleanup"
  9. Additionally RCU also creates two entries in the "SYSTEM.SCHEMA_VERSION_REGISTRY" table. Review these entries in your local database and create them in the target database.
  10. Grant select on this table to BIPLATFORM and MDS schema.
Your two repositories are successfully recreated on your target database. You can now safely install OBIEE target server. 

Thanks,
Satya Ranki Reddy

Thursday, August 15, 2013

What is the Difference between Adminserver/Manager Server/Nodemanager


What Are WebLogic Servers:

WebLogic Servers are the Programs Java programs which starts listening on a perticular port (Secure/Non-Secure) to serve clients requests. It can also have many sub systems for request processing like Jdbc Pools, JMS modules, Jolt connection Pools, Mail Servers,…etc are deployed on servers.
WebLogic Servers can be categorized in two categories
1). Admin Server
2). Managed Servers

What is Administration Server :-

Administration Server is WebLogic Server instance that maintains configuration data for a domain. You can deploy your application on administration Server but it is recommended to create managed Server and deploy your application in managed server and leave Administration domain for configuration and maintenance.
AdminServer helps us to Migrate Servers and Services within the domain.
AdminServer helps us to Deploy Applications within the domain…targeted to ManagedServers/Clusters or targeted to AdminServer itself.


What is Managed Server :-


Any Web Logic Server instance apart from Administration Server is called as Managed Servers. This is web logic server where you deploy your application (Though you can deploy your application in Administration server as well but it is not recommended in production/UAT instance)
Each Managed Server is independent of all other Managed Servers in the domain. Managed Servers can be part of Clusters to work together as a Unit. We can have one or more than one Managed Servers in a domain according to our requirement. The Managed Servers can reside inside the Physical box of AdminServer or they can run on a Separate Physical Box as well.
What is Cluster in WebLogic:-

Group of WebLogic Managed Server Instances that work together to provide high availability and scalability for applications is called cluster. WebLogic Servers with in cluster can run on same machine or different machines. These are also called as managed Server cluster.

What is WebLogic Domain:-

A WebLogic Domain is a logically related group of WebLogic Server instances (Admin + managed Servers)that you manage from a single set of configuration artifacts. A weblogic Domain contains exactly one AdministrationServer and zero or more than zero managed Servers.
All WebLogic Server instances within the same domain must be at the same major and minor version.
Servers within a domain can be at different Maintenance Pack levels as long as the Administration Server is at the same Maintenance Pack Level or higher than its Managed Servers.

How Managed Servers interacts with Admin Server:-

The Administration Server stores the master copy of the domain configuration, which contains all the configuration for all managed servers in the domain including other resource configurations like DataSource, JMS respurces, WLDF , mail Session…etc configurations as part of the “config.xml” file which is placed inside the: “Bifoundation\config” directory
Example: C:\oracle\user_projects\domains\Bifoundation\config\config.xml
Every Managed Server stores a local copy of its configuration with the help of NodeManagers.
If AdminServer is already started then while startup operation of Managed Server, it connects to the Administration Server to synchronize the configuration and in case of any modifications in the “config.xml” it collects those changes from the AdminServer.
If AdminServer is not already running and if we will try to start Managed Servers (in MSI Mode) then Managed Servers get the Cached Configuration file which is provided by the NodeManager with the name of “msi-config.xml”
What Is a WebLogic Server Cluster:-

A cluster is part of a particular WebLogic Server domain.
A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide LoadBalancing and Failover features. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. We can add any number of Managed Servers as part of a Cluster. Each server instance in a cluster must run the same version of WebLogic Server. At any point of time Any Managed Server can not belong to more than one Clusters.
If a domain contains multiple clusters, each cluster in the domain has the same Administration Server.

How Cluster and Domain Are Related:-

A domain is an interrelated set of WebLogic Server resources that are managed as a unit. A domain includes one or more WebLogic Server instances, which can be clustered, non-clustered, or a combination of clustered and non-clustered instances. A domain can include multiple clusters. A domain also contains the application components deployed in the domain, and the resources and services required by those application components and the server instances in the domain. Examples of the resources and services used by applications and server instances include machine definitions, optional network channels, connectors, and startup classes.
What Are the Benefits of Clustering:- 

Scalability (Load Balancing/Load Sharing): The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster without interruption of service, the application continues to run without impact to clients and end users.
High-Availability (Failover): In a WebLogic Server cluster, application processing can continue when a server instance fails. You “cluster” application components by deploying them on multiple server instances in the cluster so, if a server instance on which a component is running fails, another server instance on which that component is deployed can continue application processing.

What is NodeManager:-

A Node Manager process is not associated with a specific WebLogic domain but with a machine. Node Manager process to control server instances in any WebLogic Server domain until the server instances reside on the same machine as the Node Manager process.
Node Manager is a WebLogic Server utility that enables you to start, shut down, and restart Administration Server and Managed Server instances from a remote location. Although Node Manager is optional, it is recommended if your WebLogic Server environment hosts applications with high availability requirements.
A Node Manager process is not associated with a specific WebLogic domain but with a machine. You can use the same Node Manager process to control server instances in any WebLogic Server domain, as long as the server instances reside on the same machine as the Node Manager process.
Why We Need Nodemanagers:-

1). It can Start, Shut Down, and Restart an Administration Server which has assigned a Machine.
2). It can Start, Shut Down, and Restart an Managed Server which has assigned a Machine.
3). It can Restart Administration and Managed Servers. (Crash Recovery of Servers is an Interesting feature)
4). It can be used to Monitor Servers and View Log Data

Types of Node Managers:-

1). Java Based Nodemanager: This can be used in Windiows as well as UNIX based Operating systems. Java Based Node Manager is not supported on Open VMS, OS/390, AS400, UnixWare, or Tru64 UNIX.
2). Script Based Nodemanager: This nodemanager can be used in UNIX based operating systems. The advantage of the script-based Node Manager is that it can remotely manage servers over a network that has been configured to use SSH.
For More Information on NodeManager please refer to:

General Questions in interview point of view:-


1.       What is the difference between Node and Node Manager ?
A
Node Manager is a WebLogic Server utility that enables you to start, shut down, and restart Administration Server and Managed Server instances from a remote location.
Node now there is nothing like node in weblogic servers but many people refer managed servers as Nodes.

2. What is the difference between Admin server Vs managed server ?
A
Admin server can be only one for a Domain, which works like a Central Configuration/Monitoring controller for the entire domain
Managed server are similar to the Administration Servers, except few differences. Like Managed Servers will not have Administration Console Application (consoleapp) deployed in it

3. What is the relationship between Node/Node Manager to Admin/Managed Server ?
A Now Node Manager is needed to start/stop managed servers from the Admin consoles

Whoever want to learn the web logic concepts, I hope it will help you for basic understand .

Thanks,
Satya Ranki Reddy

Friday, July 19, 2013

OBIEE HLD and LLD


OBIEE HIGH LEVEL DESIGN AND LOW LEVEL DESIGN


Yesterday, I got the chance to prepare HLD document in current project. Here am contributing my experience and knowledge.


HLD document preparation you need to cover below things


1. Scope of the project
2. Source database design
3. High level warehouse design ( Star schema /snowflake schema) structure
4. Fact tables and Dimension tables and relation between the tables
4. Oracle BI Distributed architecture
5. Authorization and Authentication Details (User and group)
6. Standard Guidelines


LLD document preparation you need to cover below things.
1. Scope of the project
2. Data source system structure which includes all columns and its details
3. Repository details (Physical layer details, tables and join between tables, BMM Layer details and Presentation Layer Details) and variables and user group details
4. Report Details
5. Users and Security details


Template you have to maintain below points.

1.Document Control
2.Reviewers
3. Introductio
4. Intended Audience
5. Related Documents
6. Environment
7. Glossary – Project Terms
8. Applicable Requirements
9. BI Apps Architecture
10. Analytics (OBIEE) Repository Star schemas     
11.Assumptions
12.Dependencies
13.Issues
14.Risks
15.Open items
16.Closed item


Thanks,
Satya Ranki Reddy

Sunday, July 7, 2013

Dashboard List for specific User

What are the Dashboards list permission having for each user.

I want to show on a dashboard page  what are the dashboards list  having access in logged user.

Step 1:

I'm using a javascript in a text object in a dashboard page, which generates the list of dashboards.

Copy the below java script and go to Dashbaord--> Page--> Add Text --> paste the below code and Check the HTML option.

<img id="loading" src="/analytics/res/sk_blafp/catalog/loading-indicator-white.gif" />
<div id="dash_list"></div>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.1/jquery.min.js"></script>
<script type="text/javascript">
$.ajaxSetup({
    beforeSend:function(){
        $("#loading").show();
    },
    complete:function(){
        $("#loading").hide();
    }
});

$.ajax({
url: "saw.dll?getDashboardList"
}).done(function( data ) {
    var start = data.indexOf('[');
    var end = data.lastIndexOf(']');
    var len = end-start+1;
    var json_str = data.substr(start,len);
    var json_obj = jQuery.parseJSON(json_str);
    var str = 'You have access to the following dashboards:<br/>';
    $.each(json_obj, function() {
        if (this.folderName!=='Welcome'){
            str += '<div style="float:left;margin:5px 10px;";><b>' + this.folderName + '</b><br/>';
            $.each(this.portals, function() {
                    str += '<a href="saw.dll?Dashboard&PortalPath=' + this.portalPath + '">' + this.portalName + '</a><br/>';
            });
            str += '</div>';
        }
    });
$('#dash_list').html(str);
});
</script>