The documentation currently discusses how one can set the database throughput on creation of the database itself. Is there a way (either throught the portal or programatically) to set a database level throughput for all containers for a database that was originally setup for container throughput?
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@wahyuen Thank you for the detailed feedback. We are actively investigating and will get back to you soon.
@wahyuen You may check similar issue discussed here: #19850
@CHEEKATLAPRADEEP-MSFT According to that issue, there is a 'Scale' setting at the Database level. Because my database was never created with database level throughput, there does not seem to be that setting for me in the portal.
@wahyuen Navigate to Data Explorer => Database => Collection => Scale & Settings
Please let us know if you have any additional questions.
That is for container level throughput, I want to be able to set this at the database level
If i create a new database from scratch, with provisioned throughput, you can then go Data Explorer => Database => Scale & Settings, however, my question pertains to how, (if possible) does someone set this value if the original database was created at the container level throughput
@wahyuen During the service API creation process, there are a couple checkboxes that need to be selected which allow for database level and container level R/U changes to be made.
Creating database without provision throughput where you cannot modify database level after creation.
Creating database with [tick mark] provision throughput where you can modify database level after creation.
If you have created database with [tick mark] provision throughput; you can see the scale tab which allow for database level.
To understand this concept:
Go through the process of creating a service API (SQL Core for example) and create one database with two collections. One collection has the 'Provision Throughput' checkbox selected and the second should not. You will see what scale settings are configurable after the service is created and which is not.
Hope this helps.
I also face same problem, but I want get the in time RUs of cosmos db and set it throughput by API,
is there any way to do that?
@CHEEKATLAPRADEEP-MSFT Yes thanks for that. I do understand which parts can be updated if we were to be creating the databases from afresh.
My question still remains, is there a way to setup database level throughput for an existing database, that was originally created using container level throughput.
We have a number of existing customers with current databases and live data within them. We are attempting to assess what needs to be done should we move them to database level throughput. We are hoping to not have to create a brand new database and manually migrate data from 1 database to another just to achieve this.
@wahyuen @summerkiss Container and database level throughput provisioning are separate offerings and switching between either of these require migrating data from source to destination. Which means you need to create a new database or a new collection and then migrate data by using bulk executor library or Azure Data Factory. Please see the following FAQ doc, it's documented there:
https://docs.microsoft.com/en-us/azure/cosmos-db/faq#is-it-possible-to-switch-from-container-level-throughput-provisioning-to-database-level-throughput-provisioning-or-vice-versa
@SnehaGunda thanks....the link answers my question
Dear @SnehaGundam, our use case is not migrate data but insert million records in short time , so we want increase the throughput during that time dynamically on the existed database or collection by API. Do you have any solution on this?
Is it possible to update the throughput of Cosmos databse from 400 to 800, using the powershell or any Cosmos REST-API
Regarding the impossibility of having database and collection throughput in the same time I beg to differ.
I ran "az cosmosdb database create ... --throughput 500"
then I ran "az cosmosdb collection create ... --throughput 800".
In the end I got this.
What is happening here?
@rgherta , You absolutely can have throughput shared among many containers in a database, with one or more of them with their own dedicated throughput. The original question was around switching between shared at the database level, and dedicated to a container.
thanks.
The problem here is not just the Database Provisioning being unavailable after deploy but also the "Provision dedicated throughput for this container" setting being unavailable to change after deploy -and a whole host of combinations of those settings. I have just run into this problem and have emailed MS directly to try and get it looked at, because it is wrong imho. I do not agree with the responses from MS on this thread unfortunately and cannot understand why this was closed.
Hello Mark.
A resource that is provisioned with throughput can be updated at any time. Additionally, new containers can be provisioned with their own dedicated throughput within a database with shared throughput.
We do not currently support provisioning a database or container without throughput and then setting throughput on the resource. If this is what you are asking. there is a user voice item for this feature, please feel free to vote up here.
https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/36360358-move-ru-throughput-allocation-from-collections-to
Thanks.
Most helpful comment
@CHEEKATLAPRADEEP-MSFT Yes thanks for that. I do understand which parts can be updated if we were to be creating the databases from afresh.
My question still remains, is there a way to setup database level throughput for an existing database, that was originally created using container level throughput.
We have a number of existing customers with current databases and live data within them. We are attempting to assess what needs to be done should we move them to database level throughput. We are hoping to not have to create a brand new database and manually migrate data from 1 database to another just to achieve this.