ALTER DATABASE (Transact-SQL)
Modifica determinadas opções de configuração de um banco de dados.
Este artigo fornece a sintaxe, os argumentos, os comentários, as permissões e os exemplos de qualquer produto SQL que você escolher.
Para obter mais informações sobre as convenções de sintaxe, confira Convenções de sintaxe Transact-SQL.
Selecionar um produto
Na linha a seguir, selecione o nome do produto em que você tem interesse e somente as informações do produto serão exibidas.
* SQL Server *
Visão geral: SQL Server
No SQL Server, essa instrução modifica um banco de dados ou os arquivos e grupos de arquivos associados ao banco de dados. ALTER DATABASE adiciona ou remove arquivos e grupos de arquivos de um banco de dados, altera os atributos de um banco de dados ou seus arquivos e grupos de arquivos, altera a ordenação de banco de dados e define opções de banco de dados. Os instantâneos de banco de dados não podem ser modificados. Para modificar opções de banco de dados associadas à replicação, use sp_replicationdboption.
Devido à extensão da sintaxe ALTER DATABASE
, ela foi dividida em vários artigos.
Artigo | Descrição |
---|---|
ALTER DATABASE |
O artigo atual fornece a sintaxe e as informações relacionadas para alterar o nome e a ordenação de um banco de dados. |
Opções de arquivo e grupo de arquivos de ALTER DATABASE | Fornece a sintaxe e informações relacionadas para adicionar e remover arquivos e grupos de arquivos de um banco de dados e para alterar os atributos dos arquivos e grupos de arquivos. |
Opções de ALTER DATABASE SET | Fornece a sintaxe para alterar os atributos de um banco de dados usando as opções SET de ALTER DATABASE. |
Espelhamento de banco de dados de ALTER DATABASE | Fornece a sintaxe e informações relacionadas para as opções SET de ALTER DATABASE relacionadas ao espelhamento de banco de dados. |
ALTER DATABASE SET HADR | Fornece a sintaxe e informações relacionadas para as opções Grupos de disponibilidade AlwaysOn de ALTER DATABASE para configurar um banco de dados secundário em uma réplica secundária de um Grupo de Disponibilidade AlwaysOn. |
Nível de compatibilidade ALTER DATABASE | Fornece a sintaxe e informações relacionadas para as opções SET de ALTER DATABASE relacionadas aos níveis de compatibilidade do banco de dados. |
ALTER DATABASE SCOPED CONFIGURATION | Fornece a sintaxe relacionada às configurações no escopo do banco de dados usadas para configurações de nível de banco de dados individuais, como comportamentos relacionados a otimização de consulta e execução de consulta. |
Sintaxe
-- SQL Server Syntax
ALTER DATABASE { database_name | CURRENT }
{
MODIFY NAME = new_database_name
| COLLATE collation_name
| <file_and_filegroup_options>
| SET <option_spec> [ ,...n ] [ WITH <termination> ]
}
[;]
<file_and_filegroup_options>::=
<add_or_modify_files>::=
<filespec>::=
<add_or_modify_filegroups>::=
<filegroup_updatability_option>::=
<option_spec>::=
{
| <auto_option>
| <change_tracking_option>
| <cursor_option>
| <database_mirroring_option>
| <date_correlation_optimization_option>
| <db_encryption_option>
| <db_state_option>
| <db_update_option>
| <db_user_access_option>
| <delayed_durability_option>
| <external_access_option>
| <FILESTREAM_options>
| <HADR_options>
| <parameterization_option>
| <query_store_options>
| <recovery_option>
| <service_broker_option>
| <snapshot_option>
| <sql_option>
| <termination>
| <temporal_history_retention>
| <data_retention_policy>
| <compatibility_level>
{ 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 }
}
Argumentos
database_name
É o nome do banco de dados a ser modificado.
Observação
Essa opção não está disponível em um Banco de Dados Independente.
CURRENT
Aplica-se a: SQL Server 2012 (11.x) e posterior.
Designa que o banco de dados em uso deve ser alterado.
MODIFY NAME = new_database_name
Renomeia o banco de dados com o nome especificado como novo_nome_do_banco_de_dados.
COLLATE collation_name
Especifica a ordenação do banco de dados. collation_name pode ser um nome de ordenação do Windows ou um nome de ordenação SQL. Se não especificado, ao banco de dados será atribuída a ordenação da instância do SQL Server.
Observação
A ordenação não pode ser alterada depois que o banco de dados for criado no Banco de Dados SQL do Azure.
Durante a criação de bancos de dados com itens diferentes da ordenação padrão, os dados no banco de dados sempre respeitam a ordenação especificada. Para SQL Server, ao criar um banco de dados independente, as informações do catálogo interno serão mantidas por meio da ordenação padrão de SQL Server, Latin1_General_100_CI_AS_WS_KS_SC.
Para saber mais sobre nomes de ordenações Windows e SQL, confira COLLATE.
<delayed_durability_option> ::=
Aplica-se a: SQL Server 2014 (12.x) e posterior.
Para obter mais informações, consulte Opções de ALTER DATABASE SET e Controlar a durabilidade da transação.
<file_and_filegroup_options>::=
Para saber mais, confira Opções de arquivo e grupo de arquivos de ALTER DATABASE.
Comentários
Para remover um banco de dados, use DROP DATABASE.
Para diminuir o tamanho de um banco de dados, use DBCC SHRINKDATABASE.
A ALTER DATABASE
instrução deve ser executada no modo de confirmação automática (o modo de gerenciamento de transações padrão) e não é permitida em uma transação explícita ou implícita.
O estado de um arquivo de banco de dados (por exemplo, online ou offline) é mantido independentemente do estado do banco de dados. Para obter mais informações, consulte Estados de arquivo. O estado dos arquivos dentro de um grupo de arquivos determina a disponibilidade de todo o grupo. Para que um grupo de arquivos fique disponível, todos os seus arquivos devem estar online. Se um grupo de arquivos estiver offline, qualquer tentativa de acessar o grupo de arquivos por uma instrução SQL falhará com um erro. Quando você cria planos de consulta para instruções SELECT, o otimizador de consultas evita índices não clusterizados e exibições indexadas que residam em grupos de arquivos offline. Isso permite que essas instruções tenham êxito. Porém, se o grupo de arquivos offline contiver o heap ou índice clusterizado da tabela de destino, as instruções SELECT falharão. Além disso, qualquer INSERT
instrução , UPDATE
, ou DELETE
que modifique uma tabela com qualquer índice em um grupo de arquivos offline falhará.
Quando um banco de dados está no estado RESTOREING, a maioria das ALTER DATABASE
instruções falha. A exceção está definindo opções de espelhamento de banco de dados. Um banco de dados pode estar no estado RESTORING durante uma operação de restauração ativa ou quando uma operação de restauração de um banco de dados ou arquivo de log falha devido a um arquivo de backup corrompido.
O cache do plano para a instância do SQL Server é limpo pela configuração de uma das seguintes opções.
- COLLATE
- MODIFY FILEGROUP DEFAULT
- MODIFY FILEGROUP READ_ONLY
- MODIFY FILEGROUP READ_WRITE
- MODIFY_NAME
- OFFLINE
- ONLINE
- PAGE_VERIFY
- READ_ONLY
- READ_WRITE
A limpeza do cache de planos gera uma recompilação de todos os planos de execução subsequentes e pode provocar uma redução repentina e temporária do desempenho de consultas. Para cada armazenamento em cache limpo no cache de planos, o log de erros do SQL Server contém a seguinte mensagem informativa: SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to some database maintenance or reconfigure operations
. Essa mensagem é registrada a cada cinco minutos, contanto que o cache seja liberado dentro desse intervalo de tempo.
O cache de planos também é liberado nos seguintes cenários:
- Um banco de dados tem a opção de banco de dados
AUTO_CLOSE
definida como ON. Quando nenhuma conexão de usuário fizer referência ou usar o banco de dados, a tarefa de banco de dados tentará fechar e encerrar o banco de dados automaticamente. - Execute diversas consultas em um banco de dados que tem opções padrão. O banco de dados é removido.
- Um instantâneo de banco de dados para um banco de dados de origem é removido.
- Você recria com sucesso o log de transação para um banco de dados.
- Você restaura um backup de banco de dados.
- Você desanexa um banco de dados.
Alterar a ordenação do banco de dados
Antes de aplicar uma ordenação diferente a um banco de dados, certifique-se de que existam as seguintes condições:
- Você é o único usuário que está utilizando o banco de dados no momento.
- Nenhum objeto associado ao esquema depende da ordenação do banco de dados.
Se os objetos a seguir, que dependem da ordenação do banco de dados, existirem no banco de dados, a ALTER DATABASE database_name COLLATE
instrução falhará. O SQL Server retorna uma mensagem de erro para cada objeto que bloqueia a ALTER
ação:
- Funções definidas pelo usuário e exibições criadas com SCHEMABINDING
- Colunas computadas
- Restrições CHECK
- Funções com valor de tabela que retornam tabelas com colunas de caracteres com ordenações herdadas da ordenação de banco de dados padrão
Informações de dependência de entidades não associadas a esquema são automaticamente atualizadas quando a ordenação de banco de dados é alterada.
Alterar a ordenação de banco de dados não cria duplicatas entre nenhum nome de sistema para os objetos de banco de dados. Se nomes duplicados resultarem da ordenação alterada, os seguintes namespaces poderão causar a falha de uma alteração de ordenação de banco de dados:
- Nomes de objeto, como procedimentos, tabelas, gatilhos ou exibições
- Nomes de esquema
- Entidades, como grupos, funções ou usuários
- Nomes escalares, como tipos de sistema e tipos definidos pelo usuário
- Nomes de catálogo de texto completo
- Nomes de coluna ou parâmetro dentro de um objeto
- Nomes de índice dentro de uma tabela
Nomes duplicados resultantes da nova ordenação fazem com que a ação de alteração falhe e o SQL Server retorna uma mensagem de erro especificando o namespace em que a duplicata foi encontrada.
Exibir informações do banco de dados
É possível usar exibições do catálogo, funções do sistema e procedimentos armazenados do sistema para retornar informações sobre bancos de dados, arquivos e grupos de arquivos.
Permissões
Requer a permissão ALTER
no banco de dados.
Exemplos
a. Alterar o nome de um banco de dados
O exemplo a seguir altera o nome do banco de dados AdventureWorks2022
para Northwind
.
USE master;
GO
ALTER DATABASE AdventureWorks2022
Modify Name = Northwind ;
GO
B. Alterar a ordenação de um banco de dados
O exemplo a seguir cria um banco de dados chamado testdb
com a ordenação SQL_Latin1_General_CP1_CI_AS
e, em seguida, altera a ordenação do banco de dados testdb
para COLLATE French_CI_AI
.
Aplica-se a: SQL Server 2008 (10.0.x) e posterior.
USE master;
GO
CREATE DATABASE testdb
COLLATE SQL_Latin1_General_CP1_CI_AS ;
GO
ALTER DATABASE testDB
COLLATE French_CI_AI ;
GO
Conteúdo relacionado
* Banco de Dados SQL *
Visão geral: Banco de Dados SQL
No Banco de Dados SQL do Azure, use esta instrução para modificar um banco de dados. Use esta instrução para alterar o nome de um banco de dados, alterar o objetivo de serviço e a edição do banco de dados, ingressar ou remover o banco de dados para ou de um pool elástico, definir as opções de banco de dados, adicionar ou remover o banco de dados como um secundário em uma relação de replicação geográfica e definir o nível de compatibilidade do banco de dados.
Devido à extensão da sintaxe ALTER DATABASE
, ela foi dividida em vários artigos.
ALTER DATABASE
O artigo atual fornece a sintaxe e as informações relacionadas para alterar o nome e outras configurações de um banco de dados.
Opções de ALTER DATABASE SET
Fornece a sintaxe para alterar os atributos de um banco de dados usando as opções SET de ALTER DATABASE.
Nível de compatibilidade de ALTER DATABASE
Fornece a sintaxe e informações relacionadas para as opções SET de ALTER DATABASE relacionadas aos níveis de compatibilidade do banco de dados.
Sintaxe
-- Azure SQL Database Syntax
ALTER DATABASE { database_name | CURRENT }
{
MODIFY NAME = new_database_name
| MODIFY ( <edition_options> [, ... n] )
| MODIFY BACKUP_STORAGE_REDUNDANCY = { 'LOCAL' | 'ZONE' | 'GEO' }
| SET { <option_spec> [ ,... n ] WITH <termination>}
| ADD SECONDARY ON SERVER <partner_server_name>
[WITH ( <add-secondary-option>::=[, ... n] ) ]
| REMOVE SECONDARY ON SERVER <partner_server_name>
| FAILOVER
| FORCE_FAILOVER_ALLOW_DATA_LOSS
}
[;]
<edition_options> ::=
{
MAXSIZE = { 100 MB | 250 MB | 500 MB | 1 ... 1024 ... 4096 GB }
| EDITION = { 'Basic' | 'Standard' | 'Premium' | 'GeneralPurpose' | 'BusinessCritical' | 'Hyperscale'}
| SERVICE_OBJECTIVE =
{ <service-objective>
| { ELASTIC_POOL (name = <elastic_pool_name>) }
}
}
<add-secondary-option> ::=
{
ALLOW_CONNECTIONS = { ALL | NO }
| BACKUP_STORAGE_REDUNDANCY = { 'LOCAL' | 'ZONE' | 'GEO' }
| SERVICE_OBJECTIVE =
{ <service-objective>
| { ELASTIC_POOL ( name = <elastic_pool_name>) }
| DATABASE_NAME = <target_database_name>
| SECONDARY_TYPE = { GEO | NAMED }
}
}
<service-objective> ::={ 'Basic' |'S0' | 'S1' | 'S2' | 'S3'| 'S4'| 'S6'| 'S7'| 'S9'| 'S12'
| 'P1' | 'P2' | 'P4'| 'P6' | 'P11' | 'P15'
| 'BC_DC_n'
| 'BC_Gen5_n'
| 'BC_M_n'
| 'GP_DC_n'
| 'GP_Fsv2_n'
| 'GP_Gen5_n'
| 'GP_S_Gen5_n'
| 'HS_DC_n'
| 'HS_Gen5_n'
| 'HS_S_Gen5_n'
| 'HS_MOPRMS_n'
| 'HS_PRMS_n'
| { ELASTIC_POOL(name = <elastic_pool_name>) }
}
<option_spec> ::=
{
<auto_option>
| <change_tracking_option>
| <cursor_option>
| <db_encryption_option>
| <db_update_option>
| <db_user_access_option>
| <delayed_durability_option>
| <parameterization_option>
| <query_store_options>
| <snapshot_option>
| <sql_option>
| <target_recovery_time_option>
| <termination>
| <temporal_history_retention>
| <compatibility_level>
{ 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 }
}
Argumentos
database_name
É o nome do banco de dados a ser modificado.
CURRENT
Designa que o banco de dados em uso deve ser alterado.
MODIFY NAME = new_database_name
Renomeia o banco de dados com o nome especificado como novo_nome_do_banco_de_dados. O exemplo a seguir altera o nome de um banco de dados db1
para db2
:
ALTER DATABASE db1
MODIFY Name = db2 ;
MODIFY (EDITION = ['Basic' | 'Standard' | 'Premium' |'GeneralPurpose' | 'BusinessCritical' | 'Hyperscale'])
Altera a camada de serviço do banco de dados.
O exemplo a seguir altera a edição para Premium
:
ALTER DATABASE current
MODIFY (EDITION = 'Premium');
Importante
A alteração da edição falhará se a propriedade MAXSIZE do banco de dados estiver definida como um valor fora do intervalo válido compatível com essa edição.
MODIFICAR BACKUP_STORAGE_REDUNDANCY = ['LOCAL' | 'ZONA' | 'GEO']
As alterações na redundância de armazenamento dos backups de restauração pontual e de retenção de longo prazo (se configurados) do banco de dados. As alterações são aplicadas a todos os backups futuros realizados. Os backups existentes continuam a usar a configuração anterior.
Para impor a residência de dados ao criar um banco de dados usando T-SQL, use LOCAL
ou ZONE
como entrada para o parâmetro BACKUP_STORAGE_REDUNDANCY.
MODIFY (MAXSIZE = [100 MB | 500 MB | 1 | 1024...4096] GB)
Especifica o tamanho máximo do banco de dados. O tamanho máximo deve estar em conformidade com o conjunto válido de valores da propriedade EDITION do banco de dados. Alterar o tamanho máximo do banco de dados pode fazer com que o banco de dados EDITION seja alterado.
Observação
O argumento MAXSIZE não é aplicável a bancos de dados individuais na camada de serviço em hiperescala. Os bancos de dados de camada de serviço de Hiperescala única crescem conforme necessário, até 128 TB. O serviço de Banco de Dados SQL adiciona armazenamento automaticamente – não é necessário definir um tamanho máximo.
Modelo da DTU
MAXSIZE | Basic | S0-S2 | S3-S12 | P1-P6 | P11-P15 |
---|---|---|---|---|---|
100 MB | Sim | Sim | Sim | Sim | Sim |
250 MB | Sim | Sim | Sim | Sim | Sim |
500 MB | Sim | Sim | Sim | Sim | Sim |
1 GB | Sim | Sim | Sim | Sim | Sim |
2 GB | Sim (D) | Sim | Sim | Sim | Sim |
5 GB | N/D | Sim | Sim | Sim | Sim |
10 GB | N/D | Sim | Sim | Sim | Sim |
20 GB | N/D | Sim | Sim | Sim | Sim |
30 GB | N/D | Sim | Sim | Sim | Sim |
40 GB | N/D | Sim | Sim | Sim | Sim |
50 GB | N/D | Sim | Sim | Sim | Sim |
100 GB | N/D | Sim | Sim | Sim | Sim |
150 GB | N/D | Sim | Sim | Sim | Sim |
200 GB | N/D | Sim | Sim | Sim | Sim |
250 GB | N/D | Sim (D) | Sim (D) | Sim | Sim |
300 GB | N/D | Sim | Sim | Sim | Sim |
400 GB | N/D | Sim | Sim | Sim | Sim |
500 GB | N/D | Sim | Sim | Sim (D) | Sim |
750 GB | N/D | Sim | Sim | Sim | Sim |
1024 GB | N/D | Sim | Sim | Sim | Sim (D) |
De 1024 GB até 4096 GB em incrementos de 256 GB 1 | N/D | N/D | N/D | N/D | Sim |
1 P11 e P15 permitem MAXSIZE de até 4 TB, sendo 1024 GB o tamanho padrão. P11 e P15 podem usar até 4 TB de armazenamento incluído sem custos adicionais. Na camada Premium, um MAXSIZE maior que 1 TB está atualmente disponível nas seguintes regiões: Leste dos EUA 2, Oeste dos EUA, US Gov – Virgínia, Europa Ocidental, Região Central da Alemanha, Sudeste da Ásia, Leste do Japão, Leste da Austrália, Região Central do Canadá e Leste do Canadá. Para obter mais detalhes sobre limitações de recursos para o modelo de DTU, confira Limites de recurso de DTU.
O valor MAXSIZE do modelo de DTU, se especificado, deve ser um valor válido exibido na tabela anterior para a camada de serviço especificada.
Para limites como tamanho máximo de dados e tamanho de tempdb
no modelo de compra do vCore, consulte os artigos sobre limites de recursos para bancos de dados individuais ou limites de recursos para pools elásticos.
Se nenhum MAXSIZE
valor for definido ao usar o modelo vCore, o padrão será de 32 GB. Para obter detalhes adicionais sobre limitações de recursos para o modelo de vCore, confira Limites de recurso de vCore.
As regras a seguir se aplicam aos argumentos MAXSIZE e EDITION:
- Se EDITION for especificado, mas MAXSIZE não for especificado, o valor padrão da edição será usado. Por exemplo, se o EDITION estiver definido como Padrão e o MAXSIZE não for especificado, o MAXSIZE será definido automaticamente como 250 MB.
- Se nem MAXSIZE nem EDITION forem especificados, EDITION será definido como Uso Geral e MAXSIZE será definido como 32 GB.
MODIFY (SERVICE_OBJECTIVE = <service-objective>)
Especifica o tamanho da computação e o objetivo do serviço.
SERVICE_OBJECTIVE
Especifica o tamanho da computação (também conhecido como objetivo de nível de serviço ou SLO).
- Para o modelo de compra do DTU:
S0
,S1
,S2
,S3
,S4
,S6
,S7
,S9
,S12
,P1
,P2
,P4
,P6
,P11
,P15
. Consulte os limites de recursos para bancos de dados individuais de DTU ou limites de recursos para pools elásticos de DTU para localizar o número de DTU atribuído a cada tamanho da computação. - Para o modelo de compra vCore, escolha a camada e forneça o número de vCores de uma lista predefinida de valores, em que o número de vCores é
n
. Consulte os limites de recursos para bancos de dados individuais vCore ou limites de recursos para pools elásticos vCore.- Por exemplo:
-
GP_Gen5_8
para Uso Geral, computação provisionada, Série Standard (Gen5), 8 vCores. -
GP_S_Gen5_8
para Uso Geral, computação sem servidor, Série Standard (Gen5), 8 vCores. -
HS_Gen5_8
para Hiperescala, computação provisionada, Série Standard (Gen5), 8 vCores. -
HS_S_Gen5_8
para Hiperescala, computação sem servidor, Série Standard (Gen5), 8 vCores.
Por exemplo, a amostra a seguir altera o objetivo de serviço de um banco de dados de camada Premium no modelo de compra de DTU para P6
:
ALTER DATABASE <database_name>
MODIFY (SERVICE_OBJECTIVE = 'P6');
Por exemplo, a amostra a seguir altera o objetivo de serviço de um banco de dados de computação provisionada no modelo de compra de vCore para GP_Gen5_8
:
ALTER DATABASE <database_name>
MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
Database_Name
Somente para Hiperescala do Banco de Dados SQL do Azure. O nome do banco de dados que será criado. Usado apenas pelas réplicas nomeadas de Hiperescala do Banco de Dados SQL do Azure, quando SECONDARY_TYPE
= NAMED. Para obter mais informações, consulte Réplicas secundárias de hiperescala.
SECONDARY_TYPE
Somente para Hiperescala do Banco de Dados SQL do Azure. GEO especifica uma réplica geográfica, NAMED especifica uma réplica nomeada. O padrão é GEO. Para obter mais informações, consulte Réplicas secundárias de hiperescala.
Para obter descrições de objetivos de serviço e mais informações sobre o tamanho, as edições e as combinações de objetivos de serviço, consulte Comparar modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure, limites de recursos de DTU e limites de recursos de vCore. O suporte para objetivos de serviço PRS foi removido.
Quando SERVICE_OBJECTIVE não é especificado, o banco de dados secundário é criado no mesmo nível de serviço que o banco de dados primário. Quando SERVICE_OBJECTIVE for especificado, o banco de dados secundário será criado no nível especificado. O SERVICE_OBJECTIVE especificado precisa estar na mesma edição que a origem. Por exemplo, você não poderá especificar S0 se a edição for premium.
MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL (name = <elastic_pool_name>)
Para adicionar um banco de dados existente a um pool elástico, defina o SERVICE_OBJECTIVE do banco de dados como ELASTIC_POOL e forneça o nome do pool elástico. Você também pode usar esta opção para alterar o banco de dados para um pool elástico diferente no mesmo servidor. Para obter mais informações, consulte Pools elásticos ajudam a gerenciar e dimensionar vários bancos de dados no Banco de Dados SQL do Azure. Para remover um banco de dados de um pool elástico, use ALTER DATABASE para definir o SERVICE_OBJECTIVE como um tamanho da computação (objetivo do serviço) de banco de dados individual.
Observação
Os bancos de dados na camada de serviço de Hiperescala não podem ser adicionados a um pool elástico.
ADD SECONDARY ON SERVER <partner_server_name>
Cria um banco de dados de replicação geográfica secundário com o mesmo nome em um servidor parceiro, tornando o banco de dados local o primário da replicação geográfica e começa a replicação de dados assíncrona do primário para o novo secundário. Se um banco de dados com o mesmo nome já existir no secundário, o comando falhará. O comando é executado no banco de dados master
no servidor que hospeda o banco de dados local que se torna o primário.
Importante
Por padrão, o banco de dados secundário é criado com a mesma redundância de armazenamento de backup que o banco de dados de origem ou primário. Não há suporte para alterar a redundância de armazenamento de backup durante a criação do secundário por meio do T-SQL.
WITH ALLOW_CONNECTIONS { ALL | NO }
Quando ALLOW_CONNECTIONS não é especificado, ele é definido como ALL por padrão. Se estiver definido como ALL, ele será um banco de dados somente leitura que permite que todos os logons com as permissões apropriadas se conectem.
ELASTIC_POOL (name = <elastic_pool_name>)
Quando ELASTIC_POOL não é especificado, o banco de dados secundário não é criado em um pool elástico. Quando ELASTIC_POOL for especificado, o banco de dados secundário será criado no pool especificado.
Importante
O usuário que executa o comando ADD SECONDARY precisa ser DBManager no servidor primário, ter associação a db_owner no banco de dados local e DBManager no servidor secundário. O endereço IP do cliente deve ser adicionado à lista de permissões nas regras de firewall para os servidores primário e secundário. No caso de diferentes endereços IP de cliente, o mesmo endereço IP de cliente adicionado no servidor primário também deve ser adicionado ao secundário. Essa é uma etapa que precisa ser executada antes da execução do comando ADD SECONDARY para iniciar a replicação geográfica.
REMOVE SECONDARY ON SERVER <nome_do_servidor_parceiro>
Remove o banco de dados secundário replicado geograficamente especificado no servidor indicado. O comando é executado no banco de dados master
no servidor que hospeda o banco de dados primário.
Importante
O usuário que executa o comando REMOVE SECONDARY
precisa ser DBManager no servidor primário.
FAILOVER
Promove o banco de dados secundário na parceria de replicação geográfica na qual o comando é executado para tornar-se o primário e rebaixa o primário atual para tornar-se o novo secundário. Como parte desse processo, o modo de replicação geográfica é temporariamente alternado de modo assíncrono para modo síncrono. Durante o processo de failover:
- O primário deixa de assumir novas transações.
- Todas as transações pendentes são liberadas para o secundário.
- O secundário torna-se o primário e inicia a replicação geográfica assíncrona com o antigo primário que agora é o novo secundário.
Esta sequência garante que não haja nenhuma perda de dados. O período durante o qual os dois bancos de dados não estão disponíveis é de 0 a 25 segundos, enquanto as funções são trocadas. A operação total não deve durar mais que cerca de um minuto. Se o banco de dados primário não estiver disponível quando esse comando for emitido, o comando falhará com uma mensagem de erro indicando que o banco de dados primário não está disponível. Se o processo de failover não for concluído e parecer paralisado, você poderá usar o comando para forçar o failover e aceitar a perda de dados. Em seguida, se for necessário recuperar os dados perdidos, chame DevOps (CSS).
Importante
O usuário que executa o comando FAILOVER precisa ser DBManager no servidor primário e no servidor secundário.
FORCE_FAILOVER_ALLOW_DATA_LOSS
Promove o banco de dados secundário na parceria de replicação geográfica na qual o comando é executado para tornar-se o primário e rebaixa o primário atual para tornar-se o novo secundário. Use este comando somente quando o primário atual não estiver mais disponível. Ele foi projetado somente para recuperação de desastre, quando a restauração da disponibilidade é crítica e a perda de alguns dados é aceitável.
Durante um failover forçado:
- O banco de dados secundário especificado torna-se imediatamente o banco de dados primário e começa a aceitar novas transações.
- Quando o primário original pode se reconectar com o novo primário, um backup incremental é realizado no primário original e ele se torna o novo secundário.
- Para recuperar dados desse backup incremental no antigo primário, o usuário emprega DevOps/CSS.
- Se houver outros secundários, eles serão reconfigurados automaticamente para tornarem-se secundários do novo primário. Esse processo é assíncrono e pode haver um atraso até que esse processo seja concluído. Até que a reconfiguração seja concluída, os secundários continuarão como secundários do antigo primário.
Importante
O usuário que executa o comando FORCE_FAILOVER_ALLOW_DATA_LOSS
precisa ser dbmanager
no servidor primário e no servidor secundário.
Comentários
Para remover um banco de dados, use DROP DATABASE. Para diminuir o tamanho de um banco de dados, use DBCC SHRINKDATABASE.
A ALTER DATABASE
instrução deve ser executada no modo de confirmação automática (o modo de gerenciamento de transações padrão) e não é permitida em uma transação explícita ou implícita.
A limpeza do cache de planos gera uma recompilação de todos os planos de execução subsequentes e pode provocar uma redução repentina e temporária do desempenho de consultas. Para cada armazenamento em cache limpo no cache de planos, o log de erros do SQL Server contém a seguinte mensagem informativa: SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to some database maintenance or reconfigure operations
. Essa mensagem é registrada a cada cinco minutos, contanto que o cache seja liberado dentro desse intervalo de tempo.
O cache de procedimento também é liberado no seguinte cenário: Execute diversas consultas em um banco de dados que tem opções padrão. O banco de dados é removido.
Exibir informações do banco de dados
É possível usar exibições do catálogo, funções do sistema e procedimentos armazenados do sistema para retornar informações sobre bancos de dados, arquivos e grupos de arquivos.
Permissões
Para alterar um banco de dados, um logon deve ser o logon de administrador do servidor (criado quando o servidor lógico do Banco de Dados SQL do Azure foi provisionado), o administrador do Microsoft Entra do servidor, um membro da função de banco de dados dbmanager em master
, um membro da função de banco de dados db_owner no banco de dados atual ou dbo
do banco de dados. A ID do Microsoft Entra é (anteriormente Azure Active Directory).
Para dimensionar bancos de dados por meio do T-SQL, são necessárias permissões ALTER DATABASE. Para dimensionar bancos de dados por meio do portal do Azure, PowerShell, CLI do Azure ou API REST, são necessárias permissões RBAC do Azure, especificamente as funções do Azure RBAC Colaborador, Colaborador do BD SQL ou Colaborador do SQL Server. Para obter mais informações, visite Funções internas do Azure.
Exemplos
a. Verifique as opções de edição e altere-as
Define uma edição e um tamanho máximo para o banco de dados db1
:
SELECT Edition = DATABASEPROPERTYEX('db1', 'EDITION'),
ServiceObjective = DATABASEPROPERTYEX('db1', 'ServiceObjective'),
MaxSizeInBytes = DATABASEPROPERTYEX('db1', 'MaxSizeInBytes');
ALTER DATABASE [db1] MODIFY (EDITION = 'Premium', MAXSIZE = 1024 GB, SERVICE_OBJECTIVE = 'P15');
B. Mover um banco de dados para um pool elástico diferente
Move um banco de dados existente para um pool chamado pool1
:
ALTER DATABASE db1
MODIFY ( SERVICE_OBJECTIVE = ELASTIC_POOL ( name = pool1 ) ) ;
C. Adicionar um secundário de replicação geográfica
Cria o banco de dados secundário legível db1
no servidor secondaryserver
do db1
no servidor local.
ALTER DATABASE db1
ADD SECONDARY ON SERVER secondaryserver
WITH ( ALLOW_CONNECTIONS = ALL );
D. Remover um secundário de replicação geográfica
Remove o banco de dados secundário db1
do servidor secondaryserver
.
ALTER DATABASE db1
REMOVE SECONDARY ON SERVER testsecondaryserver;
E. Failover para um secundário de replicação geográfica
Promove o banco de dados secundário db1
no servidor secondaryserver
para tornar-se o novo banco de dados primário quando executado no servidor secondaryserver
.
ALTER DATABASE db1 FAILOVER;
Observação
Para obter mais informações, consulte Diretrizes de recuperação de desastre – Banco de Dados SQL do Azure e a lista de verificação de alta disponibilidade e recuperação de desastre do Banco de Dados SQL do Azure.
F. Forçar o failover para um secundário de replicação geográfica com perda de dados
Força um banco de dados secundário db1
no servidor secondaryserver
a se tornar o novo banco de dados primário quando executado no servidor secondaryserver
, caso o servidor primário se torne não disponível. Esta opção pode incorrer em perda de dados.
ALTER DATABASE db1 FORCE_FAILOVER_ALLOW_DATA_LOSS;
G. Atualizar um banco de dados individual para a camada de serviço S0 (Edição Standard, nível de desempenho 0)
Atualiza um banco de dados individual para a Edição Standard (camada de serviço) com um tamanho da computação (objetivo do serviço) do S0 e um tamanho máximo de 250 GB.
ALTER DATABASE [db1] MODIFY (EDITION = 'Standard', MAXSIZE = 250 GB, SERVICE_OBJECTIVE = 'S0');
H. Atualizar a redundância de armazenamento de backup de um banco de dados
Atualiza a redundância de armazenamento de backup de um banco de dados para com redundância de zona. Todos os backups futuros desse banco de dados usam a nova configuração. Isso inclui backups de restauração pontual e backups de retenção de longo prazo (se configurados).
ALTER DATABASE db1 MODIFY BACKUP_STORAGE_REDUNDANCY = 'ZONE';
Conteúdo relacionado
- CREATE DATABASE – Banco de Dados SQL do Azure
- DATABASEPROPERTYEX
- DROP DATABASE
- SET TRANSACTION ISOLATION LEVEL
- EVENTDATA
- sp_spaceused
- sys.databases
- sys.database_files
- sys.filegroups
- sys.master_files
- Bancos de dados do sistema
- Orientação de recuperação de desastres - Banco de Dados SQL do Azure
- Lista de verificação de alta disponibilidade e recuperação de desastre do Banco de Dados SQL do Azure
- Limites de recurso da DTU
- Limites de recursos vCore para bancos de dados individuais
- Limites de recursos vCore para pools elásticos
* Instância Gerenciada de SQL *
Visão geral: Instância Gerenciada do Azure SQL
Em Instância Gerenciada do Azure SQL, use essa instrução para definir opções de banco de dados.
Devido à extensão da sintaxe ALTER DATABASE
, ela foi dividida em vários artigos.
Artigo | Descrição |
---|---|
ALTER DATABASE |
|
O artigo atual fornece a sintaxe e as informações relacionadas para definir opções de arquivo e grupo de arquivos, para definir opções de banco de dados e para definir o nível de compatibilidade do banco de dados. | |
Opções de arquivo e grupo de arquivos de ALTER DATABASE | |
Fornece a sintaxe e informações relacionadas para adicionar e remover arquivos e grupos de arquivos de um banco de dados e para alterar os atributos dos arquivos e grupos de arquivos. | |
Opções de ALTER DATABASE SET | |
Fornece a sintaxe para alterar os atributos de um banco de dados usando as opções SET de ALTER DATABASE. | |
Nível de compatibilidade de ALTER DATABASE | |
Fornece a sintaxe e informações relacionadas para as opções SET de ALTER DATABASE relacionadas aos níveis de compatibilidade do banco de dados. |
Sintaxe
-- Azure SQL Managed Instance syntax
ALTER DATABASE { database_name | CURRENT }
{
MODIFY NAME = new_database_name
| COLLATE collation_name
| <file_and_filegroup_options>
| SET <option_spec> [ ,...n ]
}
[;]
<file_and_filegroup_options>::=
<add_or_modify_files>::=
<filespec>::=
<add_or_modify_filegroups>::=
<filegroup_updatability_option>::=
<option_spec> ::=
{
<auto_option>
| <change_tracking_option>
| <cursor_option>
| <db_encryption_option>
| <db_update_option>
| <db_user_access_option>
| <delayed_durability_option>
| <parameterization_option>
| <query_store_options>
| <snapshot_option>
| <sql_option>
| <target_recovery_time_option>
| <temporal_history_retention>
| <compatibility_level>
{ 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 }
}
Argumentos
database_name
É o nome do banco de dados a ser modificado.
CURRENT
Designa que o banco de dados em uso deve ser alterado.
Comentários
Para remover um banco de dados, use DROP DATABASE.
Para diminuir o tamanho de um banco de dados, use DBCC SHRINKDATABASE.
A
ALTER DATABASE
instrução deve ser executada no modo de confirmação automática (o modo de gerenciamento de transações padrão) e não é permitida em uma transação explícita ou implícita.O cache do plano para a Instância Gerenciada de SQL do Azure é limpo pela configuração de uma das opções a seguir.
COLLATE
MODIFY FILEGROUP DEFAULT
MODIFY FILEGROUP READ_ONLY
MODIFY FILEGROUP READ_WRITE
MODIFY NAME
A limpeza do cache de planos gera uma recompilação de todos os planos de execução subsequentes e pode provocar uma redução repentina e temporária do desempenho de consultas. Para cada armazenamento em cache limpo no cache de planos, o log de erros do SQL Server contém a seguinte mensagem informativa:
SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to some database maintenance or reconfigure operations
. Essa mensagem é registrada a cada cinco minutos, contanto que o cache seja liberado dentro desse intervalo de tempo. O cache de planos também é liberado quando várias consultas são executadas em um banco de dados que possui opções padrão. O banco de dados é removido.
Algumas instruções
ALTER DATABASE
exigem bloqueio exclusivo em um banco de dados a ser executado. É por isso que eles podem falhar quando outro processo ativo está mantendo um bloqueio no banco de dados. O erro relatado em um caso como esse éMsg 5061, Level 16, State 1, Line 38
com a mensagemALTER DATABASE failed because a lock could not be placed on database '<database name>'. Try again later
. Normalmente, essa é uma falha transitória. Para resolvê-la, depois que todos os bloqueios no banco de dados forem liberados, repita a instruçãoALTER DATABASE
que falhou. A exibição do sistemasys.dm_tran_locks
contém informações sobre bloqueios ativos. Para verificar se há bloqueios compartilhados ou exclusivos em um banco de dados, use a consulta a seguir.SELECT resource_type, resource_database_id, request_mode, request_type, request_status, request_session_id FROM sys.dm_tran_locks WHERE resource_database_id = DB_ID('testdb');
Exibir informações do banco de dados
É possível usar exibições do catálogo, funções do sistema e procedimentos armazenados do sistema para retornar informações sobre bancos de dados, arquivos e grupos de arquivos.
Permissões
Somente o logon de entidade de segurança no nível do servidor (criado pelo processo de provisionamento) ou os membros da função de banco de dados dbcreator
podem alterar um banco de dados.
Importante
O proprietário do banco de dados não pode alterar o banco de dados, a menos que seja membro da dbcreator
função.
Exemplos
Os exemplos a seguir mostram como definir o ajuste automático e como adicionar um arquivo em uma Instância Gerenciada de SQL do Azure.
ALTER DATABASE WideWorldImporters
SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON);
ALTER DATABASE WideWorldImporters
ADD FILE (NAME = 'data_17');
Conteúdo relacionado
* Azure Synapse
Analytics *
Visão geral: Azure Synapse Analytics
No Azure Synapse, ALTER DATABASE
modifica determinadas opções de configuração de um pool de SQL dedicado.
Devido à extensão da sintaxe ALTER DATABASE
, ela foi dividida em vários artigos.
As opções ALTER DATABASE SET fornecem a sintaxe e as informações relacionadas para alterar os atributos de um banco de dados usando as opções SET do ALTER DATABASE
.
Sintaxe
ALTER DATABASE { database_name | CURRENT }
{
MODIFY NAME = new_database_name
| MODIFY ( <edition_option> [, ... n] )
| SET <option_spec> [ ,...n ] [ WITH <termination> ]
}
[;]
<edition_option> ::=
MAXSIZE = {
250 | 500 | 750 | 1024 | 5120 | 10240 | 20480
| 30720 | 40960 | 51200 | 61440 | 71680 | 81920
| 92160 | 102400 | 153600 | 204800 | 245760
} GB
| SERVICE_OBJECTIVE = {
'DW100' | 'DW200' | 'DW300' | 'DW400' | 'DW500'
| 'DW600' | 'DW1000' | 'DW1200' | 'DW1500' | 'DW2000'
| 'DW3000' | 'DW6000' | 'DW500c' | 'DW1000c' | 'DW1500c'
| 'DW2000c' | 'DW2500c' | 'DW3000c' | 'DW5000c' | 'DW6000c'
| 'DW7500c' | 'DW10000c' | 'DW15000c' | 'DW30000c'
}
Argumentos
database_name
Especifica o nome do banco de dados a ser modificado.
MODIFY NAME = new_database_name
Renomeia o banco de dados com o nome especificado como novo_nome_do_banco_de_dados.
A opção 'MODIFY NAME' tem algumas limitações de suporte no Azure Synapse:
- Sem suporte com pools sem servidor do Azure Synapse
- Sem suporte com pools de SQL dedicados criados em seu espaço de trabalho do Azure Synapse
- Com suporte com pools de SQL dedicados (anteriormente SQL DW) criados por meio do portal do Azure, incluindo aqueles com espaço de trabalho conectado
MAXSIZE
O padrão é 245.760 GB (240 TB).
Aplica-se a: Otimizado para Computação Gen1
O tamanho máximo permitido para o banco de dados. O banco de dados não pode crescer além de MAXSIZE.
Aplica-se a: Otimizado para Computação Gen2
O tamanho máximo permitido para dados de rowstore no banco de dados. Os dados armazenados em tabelas rowstore, deltastore de um índice columnstore ou um índice não clusterizado em um índice columnstore clusterizado não podem crescer além de MAXSIZE. Os dados compactados no formato columnstore não têm um limite de tamanho e não são restritos por MAXSIZE.
SERVICE_OBJECTIVE
Especifica o tamanho da computação (objetivo do serviço). Para saber mais sobre os objetivos de serviço para o Azure Synapse, confira Unidades de Data Warehouse (DWUs).
Permissões
Requer estas permissões:
- Logon da entidade de segurança no nível do servidor (aquele criado pelo processo de provisionamento), ou
- Membro da função de banco de dados
dbmanager
.
O proprietário do banco de dados não pode alterar o banco de dados, a menos que o proprietário seja membro da dbmanager
função.
Comentários
O banco de dados atual deve ser um banco de dados diferente daquele que você está alterando, portanto, ALTER deve ser executado enquanto você está conectado ao banco de dados master
.
COMPATIBILITY_LEVEL na Análise de SQL é definido como 130 por padrão e não pode ser alterado. Para saber mais, confira ALTER DATABASE Compatibility Level.
Observação
O COMPATIBILITY_LEVEL aplica-se somente a recursos provisionados (pools).
Limitações
Para executar ALTER DATABASE
o , o banco de dados deve estar online e não pode estar em um estado pausado.
A instrução ALTER DATABASE
precisa ser executada no modo de confirmação automática, que é o modo padrão de gerenciamento de transações. Isso é definido nas configurações de conexão.
A ALTER DATABASE
instrução não pode fazer parte de uma transação definida pelo usuário.
Não é possível alterar a ordenação do banco de dados.
Exemplos
Antes de executar esses exemplos, verifique se o banco de dados que você está alterando não é o banco de dados atual. O banco de dados atual deve ser um banco de dados diferente daquele que você está alterando, portanto, ALTER deve ser executado enquanto você está conectado ao banco de dados master
.
a. Alterar o nome do banco de dados
ALTER DATABASE AdventureWorks2022
MODIFY NAME = Northwind;
B. Alterar o tamanho máximo do banco de dados
ALTER DATABASE dw1 MODIFY ( MAXSIZE=10240 GB );
C. Alterar o tamanho da computação (objetivo do serviço)
ALTER DATABASE dw1 MODIFY ( SERVICE_OBJECTIVE= 'DW1200' );
D. Alterar o tamanho máximo e o tamanho da computação (objetivo do serviço)
ALTER DATABASE dw1 MODIFY ( MAXSIZE=10240 GB, SERVICE_OBJECTIVE= 'DW1200' );
Conteúdo relacionado
* Analytics
Platform System (PDW) *
Visão geral: Sistema de plataforma de análise
No PDW (Analytics Platform System), ALTER DATABASE modifica as opções de tamanho máximo do banco de dados para tabelas replicadas, tabelas distribuídas e para o log de transações. Use esta instrução para gerenciar as alocações de espaço em disco para um banco de dados à medida que ele aumenta ou diminui de tamanho. Esse artigo também descreve a sintaxe relacionada à configuração das opções de banco de dados no PDW (Analytics Plataform System).
Sintaxe
-- Analytics Platform System
ALTER DATABASE database_name
SET ( <set_database_options> | <db_encryption_option> )
[;]
<set_database_options> ::=
{
AUTOGROW = { ON | OFF }
| REPLICATED_SIZE = size [GB]
| DISTRIBUTED_SIZE = size [GB]
| LOG_SIZE = size [GB]
| SET AUTO_CREATE_STATISTICS { ON | OFF }
| SET AUTO_UPDATE_STATISTICS { ON | OFF }
| SET AUTO_UPDATE_STATISTICS_ASYNC { ON | OFF }
}
<db_encryption_option> ::=
ENCRYPTION { ON | OFF }
Argumentos
database_name
O nome do banco de dados a ser modificado. Para exibir uma lista de bancos de dados no dispositivo, use sys.databases.
AUTOGROW = { ON | OFF }
Atualiza a opção AUTOGROW. Quando AUTOGROW for ON, o PDW (Analytics Platform System) aumentará automaticamente o espaço alocado para tabelas replicadas, tabelas distribuídas e log de transações, conforme o necessário, para acomodar o crescimento dos requisitos de armazenamento. Quando o crescimento automático for OFF, o PDW (Analytics Platform System) retornará um erro se as tabelas, replicadas, as tabelas distribuída ou o log de transações exceder o tamanho máximo.
REPLICATED_SIZE = size [GB]
Especifica o novo máximo de gigabytes por nó de computação para armazenar todas as tabelas replicadas no banco de dados que está sendo alterado. Se você estiver planejando o espaço de armazenamento do dispositivo, precisará multiplicar REPLICATED_SIZE pelo número de nós de computação no dispositivo.
DISTRIBUTED_SIZE = size [GB]
Especifica o novo máximo de gigabytes por banco de dados para armazenar todas as tabelas distribuídas no banco de dados que está sendo alterado. O tamanho é distribuído entre todos os nós de computação no dispositivo.
LOG_SIZE = size [GB]
Especifica o novo máximo de gigabytes por banco de dados para armazenar todos os logs de transações no banco de dados que está sendo alterado. O tamanho é distribuído entre todos os nós de computação no dispositivo.
ENCRYPTION { ON | OFF }
Define o banco de dados a ser criptografado (ON) ou não criptografado (OFF). A criptografia poderá ser configurada para o PDW (Analytics Platform System) somente quando sp_pdw_database_encryption tiver sido definido como 1. Uma chave de criptografia do banco de dados precisa ser criada para que a Transparent Data Encryption possa ser configurada. Para obter mais informações sobre criptografia de banco de dados, consulte TDE (Transparent Data Encryption).
SET AUTO_CREATE_STATISTICS { ON | OFF }
Quando a opção de criação automática de estatísticas, AUTO_CREATE_STATISTICS, está ativada, o otimizador de consulta cria estatísticas em colunas individuais no predicado da consulta, conforme necessário, a fim de melhorar as estimativas de cardinalidade do plano de consulta. Essas estatísticas de coluna única são criadas em colunas que ainda não têm um histograma em um objeto de estatísticas existente.
O padrão é ATIVADO para novos bancos de dados criados após a atualização para o AU7. O padrão é DESATIVADO para bancos de dados criados antes da atualização.
Para obter mais informações sobre estatísticas, consulte Estatísticas
SET AUTO_UPDATE_STATISTICS { ON | OFF }
Quando a opção de atualização automática de estatísticas, AUTO_UPDATE_STATISTICS, está ativada, o otimizador de consulta determina quando as estatísticas podem estar desatualizadas e as atualiza quando são usadas por uma consulta. As estatísticas ficam desatualizadas depois que operações de inserção, atualização, exclusão ou mesclagem alteram a distribuição dos dados na tabela ou na exibição indexada. O otimizador de consulta determina quando estatísticas podem estar desatualizadas contando o número de modificações de dados desde a última atualização das estatísticas e comparando o número de modificações a um limite. O limite se baseia no número de linhas na tabela ou na exibição indexada.
O padrão é ATIVADO para novos bancos de dados criados após a atualização para o AU7. O padrão é DESATIVADO para bancos de dados criados antes da atualização.
Para obter mais informações sobre estatísticas, consulte Estatísticas.
SET AUTO_UPDATE_STATISTICS_ASYNC { ON | OFF }
A opção de atualização de estatísticas assíncrona, AUTO_UPDATE_STATISTICS_ASYNC, determina se o otimizador de consulta usa atualizações de estatísticas síncronas ou assíncronas. A opção AUTO_UPDATE_STATISTICS_ASYNC se aplica a objetos de estatísticas criados para índices, colunas únicas em predicados de consulta e estatísticas criadas com a instrução CREATE STATISTICS
.
O padrão é ATIVADO para novos bancos de dados criados após a atualização para o AU7. O padrão é DESATIVADO para bancos de dados criados antes da atualização.
Para obter mais informações sobre estatísticas, consulte Estatísticas.
Permissões
Requer a permissão ALTER
no banco de dados.
Mensagens de erro
Se as estatísticas automáticas estiverem habilitadas e você tentar alterar as configurações delas, o PDW apresentará o erro This option isn't supported in PDW
. O administrador do sistema pode habilitar estatísticas automáticas, permitindo a opção de recurso AutoStatsEnabled.
Comentários
Os valores de REPLICATED_SIZE
,DISTRIBUTED_SIZE
e LOG_SIZE
podem ser maiores, iguais ou menores que os valores atuais do banco de dados.
Limitações
As operações de crescimento e redução são aproximadas. Os tamanhos reais resultantes podem variar em relação aos parâmetros de tamanho.
O PDW (Analytics Platform System) não executa a instrução ALTER DATABASE
como uma operação atômica. Se a instrução for anulada durante a execução, as alterações já feitas permanecerão.
As configurações de estatísticas só funcionarão se o administrador habilitar estatísticas automáticas. Se você for administrador, use a opção de recurso AutoStatsEnabled para habilitar ou desabilitar estatísticas automáticas.
Comportamento de bloqueio
Usa um bloqueio compartilhado no objeto DATABASE. Você não pode alterar um banco de dados que está sendo usado por outro usuário para leitura ou gravação. Isso inclui as sessões que emitiram uma instrução USE no banco de dados.
Desempenho
A redução de um banco de dados pode demorar bastante e usar uma grande quantidade de recursos do sistema, dependendo do tamanho dos dados reais no banco de dados e da quantidade de fragmentação no disco. Por exemplo, a redução de um banco de dados pode levar várias horas ou mais.
Determinar o progresso da criptografia
Use a consulta a seguir para determinar o andamento da Transparent Data Encryption do banco de dados como um percentual:
WITH
database_dek AS (
SELECT ISNULL(db_map.database_id, dek.database_id) AS database_id,
dek.encryption_state, dek.percent_complete,
dek.key_algorithm, dek.key_length, dek.encryptor_thumbprint,
type
FROM sys.dm_pdw_nodes_database_encryption_keys AS dek
INNER JOIN sys.pdw_nodes_pdw_physical_databases AS node_db_map
ON dek.database_id = node_db_map.database_id
AND dek.pdw_node_id = node_db_map.pdw_node_id
LEFT JOIN sys.pdw_database_mappings AS db_map
ON node_db_map .physical_name = db_map.physical_name
INNER JOIN sys.dm_pdw_nodes nodes
ON nodes.pdw_node_id = dek.pdw_node_id
WHERE dek.encryptor_thumbprint <> 0x
),
dek_percent_complete AS (
SELECT database_dek.database_id, AVG(database_dek.percent_complete) AS percent_complete
FROM database_dek
WHERE type = 'COMPUTE'
GROUP BY database_dek.database_id
)
SELECT DB_NAME( database_dek.database_id ) AS name,
database_dek.database_id,
ISNULL(
(SELECT TOP 1 dek_encryption_state.encryption_state
FROM database_dek AS dek_encryption_state
WHERE dek_encryption_state.database_id = database_dek.database_id
ORDER BY (CASE encryption_state
WHEN 3 THEN -1
ELSE encryption_state
END) DESC), 0)
AS encryption_state,
dek_percent_complete.percent_complete,
database_dek.key_algorithm, database_dek.key_length, database_dek.encryptor_thumbprint
FROM database_dek
INNER JOIN dek_percent_complete
ON dek_percent_complete.database_id = database_dek.database_id
WHERE type = 'CONTROL';
Para obter um exemplo abrangente que demonstra todas as etapas na implementação da TDE, consulte TDE (Transparent Data Encryption).
Exemplos: PDW (Analytics Platform System)
a. Alterar a configuração de AUTOGROW
Defina AUTOGROW como ON para o banco de dados CustomerSales
.
ALTER DATABASE CustomerSales
SET ( AUTOGROW = ON );
B. Alterar o armazenamento máximo para tabelas replicadas
O exemplo a seguir define o limite de armazenamento de tabela replicada em 1 GB para o banco de dados CustomerSales
. Este é o limite de armazenamento por nó de computação.
ALTER DATABASE CustomerSales
SET ( REPLICATED_SIZE = 1 GB );
C. Alterar o armazenamento máximo para tabelas distribuídas
O exemplo a seguir define o limite de armazenamento de tabela distribuída para 1000 GB (um terabyte) para o banco de dados CustomerSales
. Este é o limite de armazenamento combinado no dispositivo para todos os nós de computação, não o limite de armazenamento por nó de computação.
ALTER DATABASE CustomerSales
SET ( DISTRIBUTED_SIZE = 1000 GB );
D. Alterar o armazenamento máximo para o log de transações
O exemplo a seguir atualiza o banco de dados CustomerSales
para que o tamanho máximo do log de transações do SQL Server seja de 10 GB para o dispositivo.
ALTER DATABASE CustomerSales
SET ( LOG_SIZE = 10 GB );
E. Verificar valores atuais de estatísticas
A consulta a seguir retorna os valores atuais de estatísticas para todos os bancos de dados. O valor 1
significa que o recurso está ativado, e 0
significa o recurso está desativado.
SELECT NAME,
is_auto_create_stats_on,
is_auto_update_stats_on,
is_auto_update_stats_async_on
FROM sys.databases;
F. Habilitar criação automática e atualização automática de estatísticas para um banco de dados
Use a instrução a seguir para habilitar a criação e atualização de estatísticas automaticamente e de maneira assíncrona para o banco de dados, CustomerSales. Isso cria e atualiza estatísticas de coluna única conforme necessário para criar planos de consulta de alta qualidade.
ALTER DATABASE CustomerSales
SET AUTO_CREATE_STATISTICS ON;
ALTER DATABASE CustomerSales
SET AUTO_UPDATE_STATISTICS ON;
ALTER DATABASE
SET AUTO_UPDATE_STATISTICS_ASYNC ON;
Conteúdo relacionado
Visão geral: Microsoft Fabric
Microsoft Fabric
No Microsoft Fabric Warehouse, essa instrução modifica um warehouse.
Devido à extensão da sintaxe ALTER DATABASE
, ela foi dividida em vários artigos.
Artigo | Descrição |
---|---|
ALTER DATABASE |
O artigo atual fornece a sintaxe e as informações relacionadas para alterar o nome e a ordenação de um banco de dados. |
Opções de ALTER DATABASE SET | Fornece a sintaxe para alterar os atributos de um banco de dados usando as opções SET de ALTER DATABASE. |
Comentários
Atualmente, pausar a publicação de logs do Delta Lake e desabilitar o comportamento de V-Order em um warehouse são os únicos usos do ALTER DATABASE ... SET
no Microsoft Fabric. Confira opções ALTER DATABASE SET.