Always Encrypted - Exceção de memória insuficiente ao tentar criptografar uma coluna em uma tabela

Para tabelas grandes, eu definitivamente trabalharia com T-SQL ou Powershell em vez do assistente - UIs desajeitadas que executam todos os tipos de coisas em segundo plano e usam bloqueios superprotetores não têm um ótimo histórico. Por exemplo, este assistente oferece uma opção para gerar Powershell:

Eu faria isso. Aqui está o que ele produz:

# Generated by SQL Server Management Studio at 9:10 PM on 2/22/17

Import-Module SqlServer
# Load reflected assemblies

[reflection.assembly]::LoadwithPartialName('System.Data.SqlClient') | Out-Null
[reflection.assembly]::LoadwithPartialName('Microsoft.SQLServer.SMO') | Out-Null
[reflection.assembly]::LoadwithPartialName('Microsoft.SQLServer.ConnectionInfo') | Out-Null

# Set up connection and database SMO objects

$sqlConnectionString = 'Data Source=SERVER\INSTANCE;Integrated Security=True;MultipleActiveResultSets=False;Encrypt=False;TrustServerCertificate=True;Packet Size=4096;Application Name="Microsoft SQL Server Management Studio"'
$sqlConnection = New-Object 'System.Data.SqlClient.SqlConnection' $sqlConnectionString
$serverConnection = New-Object 'Microsoft.SqlServer.Management.Common.ServerConnection' $sqlConnection
$smoServer = New-Object 'Microsoft.SqlServer.Management.Smo.Server' $serverConnection
$smoDatabase = $smoServer.Databases['DatabaseName']

# If your encryption changes involve keys in Azure Key Vault, uncomment one of the lines below in order to authenticate:
#   * Prompt for a username and password:
#Add-SqlAzureAuthenticationContext -Interactive

#   * Enter a Client ID, Secret, and Tenant ID:
#Add-SqlAzureAuthenticationContext -ClientID '<Client ID>' -Secret '<Secret>' -Tenant '<Tenant ID>'

# Change encryption schema

$encryptionChanges = @()

# Add changes for table [dbo].[TableName]
$encryptionChanges += New-SqlColumnEncryptionSettings -ColumnName dbo.TableName.ColumnName -EncryptionType Deterministic -EncryptionKey ColumnKey

Set-SqlColumnEncryption -ColumnEncryptionSettings $encryptionChanges -InputObject $smoDatabase

Agora, isso ainda pode levar muito tempo; Eu não fiz benchmarks completos sobre a criptografia de dados existentes. Mas você não ficará sem memória (esse erro foi devido às limitações do SSMS, não do SQL Server).

Olhei rapidamente e, embora seja fácil gerar scripts T-SQL para criar chaves mestras e de coluna, não conheço uma maneira de executar ALTER TABLE. Isso passa nas verificações de sintaxe:

ALTER TABLE dbo.TableName
ALTER COLUMN ColumnName varchar(11)   
        COLLATE  Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = ColumnKey,  
        ENCRYPTION_TYPE = DETERMINISTIC ,  
        ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256');

No entanto, ele falha em tempo de execução com:

Msg 206, Level 16, State 2
Operand type clash: varchar é incompatível com varchar(11) criptografado com (encryption_type = 'DETERMINISTIC', encryption_algorithm_name = 'AEAD_AES_256_CBC_HMAC_SHA_256', column_encryption_key_name = 'ColumnKey', column_encryption_key_database_name = 'DatabaseName') collation Latin1_General_BIN2'

Sua tabela tem uma chave primária ou um índice clusterizado? Há um problema conhecido no assistente/PowerShell que pode fazer com que fique sem memória, se a tabela não tiver um índice primário ou clusterizado, portanto, uma solução alternativa pode ser criar uma chave primária/índice clusterizado, se você não já não tem.

Você também pode tentar usar o PowerShell de 64 bits. Usar o PowerShell de 32 bits em vez do SSMS provavelmente não ajudará, pois o SSMS e o PowerShell usam a mesma biblioteca (DacFx) para dar suporte à maioria dos cenários Always Encrypted.