This page describes how to configure database flags for Cloud SQL, and
lists the flags that you can set for your instance. You use database flags
for many operations, including adjusting SQL Server parameters, adjusting
options, and configuring and tuning an instance.
When you set, remove, or modify a flag for a database instance, the database
might be restarted. The flag value is then persisted for the instance until you
remove it. If the instance is the source of a replica, and the instance is
restarted, the replica is also restarted to align with the current configuration
of the instance.
Configure database flags
The following sections cover common flag management tasks.
Set a database flag
Console
In the Google Cloud console,
select the project that contains the Cloud SQL instance for which you want to set a database flag.
Open the instance and click Edit.
Go to the Flags section.
To set a flag that has not been set on the instance before, click
Add item, choose the flag from the drop-down menu, and set its value.
Click Save to save your changes.
Confirm your changes under Flags on the Overview page.
This command will overwrite all database flags
previously set. To keep those and add new ones, include the values for all
flags you want set on the instance; any flag not specifically included is
set to its default value. For flags that don't take a value, specify the
flag name followed by an equals sign ("=").
For example, to set the 1204,
remote access, and remote query timeout (s) flags, you
can use the following command:
resource "google_sql_database_instance" "instance" {
name = "sqlserver-instance-flags"
region = "us-central1"
database_version = "SQLSERVER_2019_STANDARD"
root_password = "INSERT-PASSWORD-HERE"
settings {
database_flags {
name = "1204"
value = "on"
}
database_flags {
name = "remote access"
value = "on"
}
database_flags {
name = "remote query timeout (s)"
value = "300"
}
tier = "db-custom-2-7680"
}
# set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
# use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
deletion_protection = false
}
Apply the changes
To apply your Terraform configuration in a Google Cloud project, complete the steps in the
following sections.
Set the default Google Cloud project
where you want to apply your Terraform configurations.
You only need to run this command once per project, and you can run it in any directory.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Environment variables are overridden if you set explicit values in the Terraform
configuration file.
Prepare the directory
Each Terraform configuration file must have its own directory (also
called a root module).
In Cloud Shell, create a directory and a new
file within that directory. The filename must have the
.tf extension—for example main.tf. In this
tutorial, the file is referred to as main.tf.
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
If you are following a tutorial, you can copy the sample code in each section or step.
Copy the sample code into the newly created main.tf.
Optionally, copy the code from GitHub. This is recommended
when the Terraform snippet is part of an end-to-end solution.
Review and modify the sample parameters to apply to your environment.
Save your changes.
Initialize Terraform. You only need to do this once per directory.
terraform init
Optionally, to use the latest Google provider version, include the -upgrade
option:
terraform init -upgrade
Apply the changes
Review the configuration and verify that the resources that Terraform is going to create or
update match your expectations:
terraform plan
Make corrections to the configuration as necessary.
Apply the Terraform configuration by running the following command and entering yes
at the prompt:
terraform apply
Wait until Terraform displays the "Apply complete!" message.
Open your Google Cloud project to view
the results. In the Google Cloud console, navigate to your resources in the UI to make sure
that Terraform has created or updated them.
Delete the changes
To delete your changes, do the following:
To disable deletion protection, in your Terraform configuration file set the
deletion_protection argument to false.
deletion_protection = "false"
Apply the updated Terraform configuration by running the following command and
entering yes at the prompt:
terraform apply
Remove resources previously applied with your Terraform configuration by running the following
command and entering yes at the prompt:
terraform destroy
REST v1
To set a flag for an existing database:
Before using any of the request data,
make the following replacements:
If there are existing flags configured for the database, modify the previous
command to include them. The PATCH command overwrites the existing
flags with the ones specified in the request.
REST v1beta4
To set a flag for an existing database:
Before using any of the request data,
make the following replacements:
If there are existing flags configured for the database, modify the previous
command to include them. The PATCH command overwrites the existing
flags with the ones specified in the request.
Clear all flags to their default values
Console
In the Google Cloud console,
select the project that contains the Cloud SQL instance for which you want to clear all flags.
Open the instance and click Edit.
Open the Database flags section.
Click the X next to all of the flags shown.
Click Save to save your changes.
gcloud
Clear all flags to their default values on an instance:
Determine which database flags have been set for an instance
To see which flags have been set for a Cloud SQL instance:
Console
In the Google Cloud console,
select the project that contains the Cloud SQL instance for which you want to see the database flags that have been set.
Select the instance to open its Instance Overview page.
The database flags that have been set are listed under the
Database flags section.
gcloud
Get the instance state:
gcloudsqlinstancesdescribeINSTANCE_NAME
In the output, database flags are listed under the settings as
the collection databaseFlags. For more information
about the representation of the flags in the output, see
Instances Resource Representation.
REST v1
To list flags configured for an instance:
Before using any of the request data,
make the following replacements:
project-id: The project ID
instance-id: The instance ID
HTTP method and URL:
GET https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
To send your request, expand one of these options:
This section contains additional information about Cloud SQL for SQL Server flags.
max degree of parallelism (MAXDOP)
Max degree of parallelism (MAXDOP) is a Microsoft database flag
available for use in Cloud SQL for SQL Server. This flag lets you limit the maximum
number of threads used when running a single query in a parallel plan.
If left to the default value of 0, then the database instance uses
all available processors. However, this might not always be efficient or even
practical if managing instances with hundreds of databases.
We recommend following Microsoft documentation recommendations when setting the
flag's value, which can vary based on the number of numa nodes and the
number of available logical processors.
You can check the numa node configuration using the
dynamic management view (DMV)
from
sys.dm_os_sys_info.
To check the numa node configuration, use a code snippet similar to the following:
SELECT socket_count,cores_per_socket,numa_node_count
FROM sys.dm_os_sys_info
While you can use MAXDOP to limit the maximum number of processors you want to
allow for parallel plan execution, you can also use the
cost threshold for parallelism
feature to indicate the minimum cost you want to set for a single processor
before expanding parallel operations to another processor. These features let
you better control the efficiency and cost of parallel plan execution.
Recommended values for these features vary on a case-by-case basis, and will
be influenced by your server and application workload needs.
For help determining the best MAXDOP and cost threshold for parallelism values
for your servers, see the following resources:
Changing the default value helps address the following potential issues:
If the max degree of parallelism (MAXDOP)
flag is set to 0, then instances or client applications that
require SharePoint downloads fail. The SharePoint download runs a pre-check that
requires a numeric value for the flag and won't accept a value less than 1.
Leaving the MAXDOP flag to the default of 0,
effectively indicates that there is no limit and that all available
processors can be used for parallel operations. While this value might be fine
for servers routinely running small queries, it might pose a cost issue if you
also need to periodically run very large queries.
Using the max degree of parallelism (MAXDOP) flag, you can control
the number of threads at three levels:
Instance level, using database flags
Database scope, using TSQL
Query level, using query hints
Note that if the instance is resized, then the flag value remains unchanged.
max server memory (mb)
The max server memory (mb) flag limits the amount of memory that
Cloud SQL can allocate for its internal pools.
We recommend you not configure a value for this flag and that you let Cloud SQL
manage the value for you. If you must manually manage this value, as a general
recommendation, set the max server memory (mb) value to roughly 80%
of available memory to help prevent SQL Server from consuming all memory.
Conversely, for instances with large amounts of memory, 80% of available memory
might be too low of a value and might lead to wasted memory usage.
If you don't set a value for this flag, then Cloud SQL manages the
value automatically, based on the size of the RAM for your instance. Also, if
you resize your instance, then Cloud SQL adjusts the value of the flag
automatically to meet our recommendations for the new instance size. This resize
operation also removes any manually set value for this flag. This helps your
database utilize resources more effectively by helping prevent overallocation,
reducing the likelihood of a crash due to out-of-memory issues, and helping to
avoid performance degradation for your instance.
You want to modify the time zone for a Cloud SQL instance.
To see how to update an instance's time zone, see Instance settings.
In Cloud SQL for SQL Server, you can use the AT TIME ZONE
function for time conversions and more. For more information about this function,
see
AT TIME ZONE (Transact-SQL).
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-03-27 UTC."],[],[]]
