Oracle Analytics Cloud and Server

Welcome to the Oracle Analytics Community: Please complete your User Profile and upload your Profile Picture

Multiple Connection Pools for Usage Tracking

Received Response
91
Views
6
Comments

How can I specify multiple Connection Pools from different databases (In System Settings -> Usage Tracking) for inserting records into the Usage Tracking tables? I believe currently we can provide only one Connection Pool from one Database.

Answers

  • What would be the need?

    Do you have the usage tracking tables split in 2 different databases? Or do you expect "double" insert in 2 different places in parallel duplicating all the rows?

    Quite sure that for usage tracking the connection pool has always been one, even in OBIEE 10g, 11g and 12c.

  • SaurabhJaiswal-Oracle
    SaurabhJaiswal-Oracle Rank 5 - Community Champion

    This is the requirement for a leading bank where multiple vendors are working on different database but sharing the same OAC instance, in this situation is there any way to specify multiple Usage Tracking?

  • The product never supported that.

    They can setup an ETL process doing the job: reading usage tracking from the central place and pushing the relevant rows around to the various databases.

    Or more simply just sending the whole content. Can be batch based or near real-time with the the various options the various ETL tools available can use.

  • BalaGuddeti-Oracle
    BalaGuddeti-Oracle Rank 5 - Community Champion

    Agree with @Gianni Ceresa, in an other approach, you can assign different Subject areas to diffrent vendors. So the Different Subject area names will be captured on UT tables. You can allow access through DB views on the Usage Tracking tables based on SUBJECT_AREA_NAME column.

    Bala Guddeti

    Principal Analytics Technologist

    https://www.linkedin.com/in/balaguddeti-oracledataintelligence/

  • SiddharthDang-Oracle
    SiddharthDang-Oracle Rank 5 - Community Champion

    Dear Saurabh,

    One easy solution to your requirement would be to read the folder path of the object being run and segregate the object based on the project folder path.

    Exam - A DV, Classic report placed in folder project a would be of project a whereas an object called from folder project B will be of project B. This can be simply manipulated by SQL and then further placed in separate tables by calling an ETL process. Then you can build reporting on top of this to find out the usage of each project. If you need any help you can reach out to me. We have implemented the same in our instances where we have two teams working in OAC on separate projects.

    Regards,

    Siddharth Dang

  • @SaurabhJaiswal-Oracle ,

    keeping it simple what you asked never existed as a feature in the product, and not even worth raising an ER for it because it doesn't really fit in with the architecture of the product. Usage tracking is a technical feature, Oracle Analytics is still a single-instance product (they did try adding a multi-instance concept in OBIEE 12c, never really went any further than adding the concept of instance, "ssi" by default, but never managed to make it really multi-instance) and therefore usage tracking, which is the equivalent of logging, is unique for the whole instance.

    As posted by many you can implement workarounds to cover your needs, and if you don't have anything else you could even try with a dataflow in OAC itself and schedule it to run automatically every day (or hour or what you need). In the end a dataflow is a "lightweight" ETL, so you can do the job of splitting the single usage tracking table into multiple pieces and push the data back to separate tables in the database.

    You can choose the solution you like the most, even just a filter on data at a screen level based on the accounts (roles) of users looking at an analysis/workbook built on top of usage tracking data.

    If you got the info you needed, feel free to close the thread by marking as required (which will also help others with similar questions identifying important pieces in a thread).