Oracle Analytics Cloud and Server

Products Banner

OAC - Pricing Info

Accepted answer
159
Views
14
Comments

Hi,

In case anyone knows, please share the inputs.

We have a database of around 50TB sitting in private cloud of a company owned cloud setup.

We are looking at OAC as an Analytics tool for reporting purposes.

We have to provide access to around 450 users initially. (Read/Consume Access to 420, and 30 Authors)

Can you share some of the pricing models for this combination?

If you have any other information regarding this, please share.


Thanks.

Best Answer

  • Gianni Ceresa
    Answer ✓

    its own private cloud setup

    Do you mean the customer has an OCI dedicated region? Keeping it simple: their own Oracle cloud region in-house? In that case the dedicated region should also be able to run OAC (in theory a dedicated region is supposed to offer the same services as public regions).

Answers

  • Federico Venturin
    Federico Venturin ✭✭✭✭✭

    Hi @User_FD52V ,

    OCI provides a user friendly Cost Estimator: https://www.oracle.com/cloud/costestimator.html

    Select "Analytics and BI" as the category, then click Load for the option you are interested in (e.g. Oracle Analytics Cloud Enterprise).

    For OAC, you can choose between OCPU per hour or User per Month pricing (if you enter the number of users, then set OCPU to 0, and viceversa). If you click on Edit next Utilization, you can also specify hours per day and days per month that you are going to use the service.

  • More than the total number of users, you should consider the concurrent users.

    With your 450 users, you will definitely not adopt a "per user" license but use a OCPU based license. Therefore what matters to define the ideal sizing of your infrastructure is the number of concurrent sessions and an idea of the workload you will put on that environment.

    Also keep in mind that you can fairly easily adapt the shape (number of OCPU), therefore estimate the costs at the best based on what you believe is the need, then also check the price for the size above and below and there you will probably have a fairly accurate range of what your cost will be, because you will be adjusting the capacity based on the observed usage.

  • Hi Gianni,

    Thank you for your reply.

    As I understand, you are suggesting to assess the number of concurrent users.

    Here, assuming that number is 250. How many OCPUs would be needed?

    Generally, how many concurrent or active user sessions can be handled effectively by 1 OCPU ?

    Thank you.

  • Sizing is specific to the Business as it depends on the complexity of reports and the number of reports per dashboard. Also the number of rows downloaded per report need to be evaluated. Most businesses perform stress tests with different iterations for concurrent users vs variable ocpu's to determine the ideal sizing. Also, you may be able to scale up or down depending on your usage to optimize efficiency and costs.

    It is best to connect with Oracle sales department to get a professional evaluation of understanding your requirements. Let us know if we can help you connect with Oracle Sales team.

  • Hi @User_FD52V ,

    There isn't an absolute rule of how many concurrent users can be handled by 1 OCPU.

    As @Shantaram-Oracle said, there are a lot of elements to consider. The key point is just to ignore the total number of users because you will definitely not going to by "per user" license (450 users costs a bit more than 22 OCPUs): an instance with 22 OCPU will handle more than 450 users.

    Have a look at https://docs.oracle.com/en/cloud/paas/analytics-cloud/acsom/create-services-oracle-analytics-cloud.html#GUID-164D8568-9AE3-4A74-9F1A-0D87B78713C9__TABLE3, it gives some limits by OCPU (as you can see most of them have the max limits at 16 OCPU already).

    No idea if it's still the valid resource, it's a old link I found around.

    I would also challenge your estimation of 250 concurrent users with a total of 450 : it's often a lot less than that, you will probably have mostly 50-100 concurrent users (historically there was a 10% of total users rule for concurrency that was used by default).

    In the past Oracle was publishing sizing documents based on very random criteria, and that's also why they did stop. Each environment is so different in almost every single parameter because it all depends on what you are doing with it.

    You can also just take the empirical approach: create an instance with 4 or 8 OCPU, use it and evaluate what happens.

    Just don't confuse slow response time because of the network connection between OAC and your database with a too small OAC. You definitely want to carefully evaluate the latency and performance of that connection between your cloud database and the Oracle region hosting your OAC, because it will maybe be the bottleneck of your usage and you can keep adding OCPU to OAC with little to no changes in performance (except if you plan in caching everything in OAC to hide the limits of the connection to the database, but here again your architects shouldn't really let you do that!).

  • Hi Gianni,

    Thank you for the detailed explanation.

    As I I can understand, I will have to look at all such factors in mind while decising the Infrastructure.

    The last point you have mentioned about location of services.

    In our case the customer has its own private cloud setup where they would be hosting database as well. Assuming that it is in Region ABC.

    If OAC can be hosted in the same region, would that give better performance results ?

  • @User_FD52V, is there a sales engineer you're working with, or a partner? They should be able to help guide you on sizing recommendations.

    Also @Bret Grinslade - Oracle Analytics-Oracle, @Gabby Rubin-Oracle, @Jagdish Pamnani do you want to add anything here re: pricing and sizing?

  • @Gianni Ceresa did a good job describing factors and an approach. And having OAC in the same region as your main data sources is typically beneficial.

  • Something to keep in mind (choose your terminology):

    1 OCPU = 1 Core = 2 vCPUs = 0.5 CPU = 2 threads

    It does not mean that 100 concurrent users need 100 threads, as the user's definition of concurrency is often "people logged in at the same time," while the system concurrency definition is "users executing a query at the same millisecond.". The first one might not mean much concerning sizing (other than the act and timing of the actual log-in operation), while the second highly impacts concurrent performance.

    Even in a system with 100 concurrently logged-in users, the typical statistical likelihood of multiple users issuing a single query at the exact second is low; however, the time that the query will process and the type of dashboards (i.e., dashboards that fire multiple queries based on a single user operation) can increase those chances dramatically. The next level down is going to be where that time is spent and what type of content users are allowed to create.

    Basically, the sizing of a platform analytics tool is never a one-size-fits-all and your need will also evolve as your content and users will. Based on your description, I agree with @Gianni Ceresa that 4 is the safe starting point. If you eventually get to 8, you probably have a relatively busy system (or long per-user executions). Cloud make is easier as this is not a 3 years HW buying decision, and if needed, you can also manage your cost by scaling down low usage hours/days or 'hibernate' the service on nights and weekends.

    Putting all services close to each other is always the best, but it should still be ok if it is not possible. Most will not even feel the extra latency, but this is another area where mileage might vary based on a specific implementation, as even small latencies can accumulate fast to become long delays. It is just one less thing to worry about if you can co-locate it.

  • Does analytics per user count as the maximum number of users that can be created or logged in at the same time?

  • It should be named users, not concurrent users.

  • @Gianni Ceresa is correct; user licensing is named. I also agree with the above comment that at 450, you should consider OCPU pricing as your preferred model.