This post is part of a series of blog posts on the Oracle Autonomous Database.

Service Limits

• A quota or allowance set on a resource
  
• Are set by the service you have subscribed to
  
• May change automatically based on your OCI resource usage or by changing your account type. e.g. Always-Free to Paid

Service Limits are quotas or allowances that are set on a specific resource. Service limits are defined and set by Oracle. They’re set by the service you have subscribed to and they can change automatically based on your OCI resource usage or by changing your account type.

The service limit is based on the service you’ve subscribe to. The service could be database service in which case you storage could be something that’s controlled for you. For example, you understand with the autonomous database, it could be anywhere from 1 to 128 terabytes. That’s the type of service that could be limited.

In addition to that, the service may change. So what is available for you may change based on your service. In the example of always free to paid, if you’re defining an autonomous database, that would be limited to one OCPU maximum in the always free account. If you were to convert that account to a paid account, that limit will be lifted from one to obviously 128 OCPUs that could be configured.

Compartment Quotas

• Similar to Service Limits. However, where as Service Limits are set by Oracle, Compartment Quotas are set by Customer Administrators. Please note, in dedicated Infrastructure, this is managed by the FLEET administrator
  
• Set using Policy Statements. A simple declarative language similar to IAM policy language

Compartment quotas are very similar to service limits, however, whereas a service limit is set by Oracle, compartment quotas are set by customer administrators (fleet administrators). In the dedicated infrastructure world, this is managed by the fleet administrator and be one of their roles and responsibilities. Compartment quotas are set using policy statements that are very simple, and very easy to follow, and similar to the IAMs.

So if we look at service limits and compartment quotas– keep in mind that tenancy limits, and quotas, and usage can be viewed using your cloud console. The console may not display the information for all of the OCI services or resources, but that’s because it’s only going to show what you subscribe to. Also keep in mind that the usage may be greater than the limit that’s available to you and that’s because the limit may have been reduced after the resource was initially created.

The other thing to keep in mind is that limits are sometimes displayed as zero. And if that is the case, then the account has been suspended. Now, that is not necessarily a bad thing. This is– the account could be suspended due to a lack of inactivity, which really just means you’re not being billed or charged for the resources that would potentially be consumed. This is apparent in the always free account when a database becomes idle for an extended period of time.

e.g. create quota policy stub. When you click on that, it will bring up a panel which we can then go in and enter in the fields there. In this case, we’re going to say set database quota, ADW total storage terabytes, or TB, to a number in our compartment team. So by doing that, we will then fix the limit in which anyone connecting to this compartment can actually create the storage of their database. So this is a way of controlling that resource.

Governance –> Limits, Quotas and Usage

set database quota adw-total-storage-tb to [number] in compartment Team