Estou lendo a documentação para sp_create_plan_guide e acho difícil de entender. Minhas perguntas são:
O que estou perdendo aqui? Obrigado antecipadamente!
Versão curta: existe uma maneira de obter o esquema de partição para os dados FILESTREAM usados por um índice clusterizado criado em uma tabela particionada?
Versão mais longa: digamos que você queira particionar uma tabela que armazena dados FILESTREAM, então a documentação diz:
Se a tabela for particionada, a cláusula FILESTREAM_ON deve ser incluída e deve especificar um esquema de partição de grupos de arquivos FILESTREAM que use a mesma função de partição e colunas de partição que o esquema de partição para a tabela. Caso contrário, um erro será gerado.
Então você cria grupos de arquivos para linhas e dados de fluxo de arquivos, uma função de partição e dois esquemas de partição (novamente um para as linhas e dados de fluxo de arquivos, respectivamente), assim:
USE [master]
GO
CREATE DATABASE [FSPartitionTest]
ON PRIMARY
( NAME = N'FSPartitionTest', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\FSPartitionTest.mdf'),
FILEGROUP [DataPartitionA]
( NAME = N'Data_A', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\Data_A.ndf'),
FILEGROUP [DataPartitionB]
( NAME = N'Data_B', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\Data_B.ndf'),
FILEGROUP [FSPartitionA] CONTAINS FILESTREAM DEFAULT
( NAME = N'FS_A', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\FS_A'),
FILEGROUP [FSPartitionB] CONTAINS FILESTREAM
( NAME = N'FS_B', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\FS_B')
LOG ON
( NAME = N'FSPartitionTest_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\FSPartitionTest_log.ldf')
GO
USE [FSPartitionTest]
GO
CREATE PARTITION FUNCTION [APartitionFunction] (INT)
AS RANGE LEFT FOR VALUES (1);
GO
CREATE PARTITION SCHEME [DataPartitionScheme]
AS PARTITION [APartitionFunction]
TO ([DataPartitionA], [DataPartitionB]);
GO
CREATE PARTITION SCHEME [FSPartitionScheme]
AS PARTITION [APartitionFunction]
TO ([FSPartitionA], [FSPartitionB]);
GO
CREATE TABLE [FilestreamTable] (
[Partition] INT NOT NULL
, [Id] [uniqueidentifier] ROWGUIDCOL NOT NULL
CONSTRAINT [UX_FilestreamTable_Id] UNIQUE NONCLUSTERED ON [PRIMARY]
, [FilestreamData] VARBINARY(MAX) FILESTREAM NULL
, INDEX [UX_FilestreamTable_Partition_Id] UNIQUE CLUSTERED (
[Partition],
[Id]
) ON [DataPartitionScheme]([Partition]) FILESTREAM_ON [FSPartitionScheme]
) ON [DataPartitionScheme]([Partition]) FILESTREAM_ON [FSPartitionScheme]
GO
Então você pode consultar os esquemas de partição e os índices assim:
SELECT *
FROM sys.partition_schemes
SELECT T.[name], I.[name], I.[data_space_id]
FROM sys.tables AS T
JOIN sys.indexes AS I
ON T.[object_id] = I.[object_id]
Ambos os esquemas de partição aparecem, ambos usam a mesma função de partição e o índice clusterizado faz referência ao DataPartitionSchemein sys.indexes. No entanto, o esquema de partição usado para os dados FILESTREAM não é referenciado. Neste caso, há apenas um outro esquema de partição usando a mesma função de partição e tendo grupos de arquivos filestream como alvos. Para qualquer cenário prático, estaríamos prontos. Ninguém adicionaria outro esquema de partição, certo?
CREATE PARTITION SCHEME [FSPartitionSchemeB]
AS PARTITION [APartitionFunction]
TO ([FSPartitionB], [FSPartitionA]);
GO
CREATE TABLE [FilestreamTableB] (
[Partition] INT NOT NULL
, [Id] [uniqueidentifier] ROWGUIDCOL NOT NULL
CONSTRAINT [UX_FilestreamTableB_Id] UNIQUE NONCLUSTERED ON [PRIMARY]
, [FilestreamData] VARBINARY(MAX) FILESTREAM NULL
, INDEX [UX_FilestreamTableB_Partition_Id] UNIQUE CLUSTERED (
[Partition],
[Id]
) ON [DataPartitionScheme]([Partition]) FILESTREAM_ON [FSPartitionSchemeB]
) ON [DataPartitionScheme]([Partition]) FILESTREAM_ON [FSPartitionSchemeB]
GO
CREATE PARTITION SCHEME [FSPartitionSchemeC]
AS PARTITION [APartitionFunction]
ALL TO ([FSPartitionA]);
GO
CREATE TABLE [FilestreamTableC] (
[Partition] INT NOT NULL
, [Id] [uniqueidentifier] ROWGUIDCOL NOT NULL
CONSTRAINT [UX_FilestreamTableC_Id] UNIQUE NONCLUSTERED ON [PRIMARY]
, [FilestreamData] VARBINARY(MAX) FILESTREAM NULL
, INDEX [UX_FilestreamTableC_Partition_Id] UNIQUE CLUSTERED (
[Partition],
[Id]
) ON [DataPartitionScheme]([Partition]) FILESTREAM_ON [FSPartitionSchemeC]
) ON [DataPartitionScheme]([Partition]) FILESTREAM_ON [FSPartitionSchemeC]
GO
Como podemos determinar qual tabela usa qual esquema de partição? Há alguma view que faça referência direta ao data_space_idusado por um índice para dados FILESTREAM?
Solução alternativa:
Há uma coisa que notei, mas não tenho certeza se funciona 100% do tempo. A sys.partitionsvisualização tem uma filestream_filegroup_idcoluna:
SELECT T.[name]
, I.[name]
, I.[data_space_id]
, P.[partition_number]
, FG.[name]
FROM sys.tables AS T
JOIN sys.indexes AS I
ON T.[object_id] = I.[object_id]
JOIN sys.partitions AS P
ON I.[object_id] = P.[object_id]
AND I.[index_id] = P.[index_id]
JOIN sys.filegroups AS FG
ON P.[filestream_filegroup_id] = FG.[data_space_id]
A visualização destination_data_spacestambém tem uma coluna destination_id, que - suponho - corresponde a partition_number:
SELECT PS.[name]
, DDS.[destination_id]
, FG.[name]
FROM sys.partition_schemes AS PS
JOIN sys.destination_data_spaces AS DDS
ON PS.[data_space_id] = DDS.[partition_scheme_id]
JOIN sys.filegroups AS FG
ON DDS.[data_space_id] = FG.[data_space_id]
Então, acho que é possível verificar se os grupos de arquivos referenciados por destination_data_spacescorrespondem aos referenciados por partitionspara cada partição:
WITH A AS (
SELECT T.[name] AS [Table]
, I.[name] AS [Index]
, PS.[name] AS [PartitionScheme] -- for row data
, FSPS.[name] AS [FS_PartitionScheme] -- candidate
, FG.[name] AS [FS_DestinationFilegroup] -- referenced by partition scheme
, PFG.[name] AS [FS_PartitionFilegroup] -- referenced by partition
, CASE WHEN FG.[name] = PFG.[name] THEN 1 ELSE 0 END AS [FilegorupsMatch]
, COUNT(*) OVER (PARTITION BY T.[object_id], I.[index_id], FSPS.[data_space_id]) AS [NumPartitions]
, SUM(CASE WHEN FG.[name] = PFG.[name] THEN 1 ELSE 0 END) OVER (PARTITION BY T.[object_id], I.[index_id], FSPS.[data_space_id]) AS [SumMatches]
FROM sys.tables AS T
JOIN sys.indexes AS I
ON T.[object_id] = I.[object_id]
--partition scheme used for row data
JOIN sys.partition_schemes AS PS
ON I.[data_space_id] = PS.[data_space_id]
--look for candidate partition schemes, that are used for FILESTREAM data
--must use the same partition function
JOIN sys.partition_schemes AS FSPS
ON PS.[function_id] = FSPS.[function_id]
AND PS.[data_space_id] <> FSPS.[data_space_id]
--destination must be a FILESTREAM filegroup
JOIN sys.destination_data_spaces AS DDS
ON FSPS.[data_space_id] = DDS.[partition_scheme_id]
JOIN sys.filegroups AS FG
ON DDS.[data_space_id] = FG.[data_space_id]
AND FG.[type_desc] = 'FILESTREAM_DATA_FILEGROUP'
--get the partition where partition_number matches desination_id
JOIN sys.partitions AS P
ON I.[object_id] = P.[object_id]
AND I.[index_id] = P.[index_id]
AND P.[partition_number] = DDS.[destination_id]
--find the filegroup referenced by the partition
LEFT JOIN sys.filegroups AS PFG
ON P.[filestream_filegroup_id] = PFG.[data_space_id]
)
SELECT [Table], [Index], [PartitionScheme], [FS_PartitionScheme]
FROM A
WHERE [NumPartitions] = [SumMatches]
GROUP BY [Table], [Index], [PartitionScheme], [FS_PartitionScheme]
Deve haver uma linha por Índice, a menos que algum palhaço faça isso:
CREATE PARTITION SCHEME [FSPartitionSchemeB2]
AS PARTITION [APartitionFunction]
TO ([FSPartitionB], [FSPartitionA]);
GO
Então, se alguém puder confirmar que de fato o partition_numbersempre corresponde ao destination_id, podemos pelo menos identificar o esquema de partição até uma definição única (excluindo NEXT USED), mas ainda não um . definitivo data_space_id.
você está curioso para saber se o padrão ANSI SQL tem uma maneira portátil de criar um objeto de sequência e obter valores dele?
Não consigo encontrar uma maneira portátil, mas os mecanismos de busca parecem confundir ANSI SQL com MS SQL Server, então talvez eu esteja apenas ignorando...
Existe uma maneira de manter o histórico de conexão para uma determinada tabela no SQL-server? Não apenas o banco de dados, porque é fácil usar o DMV, mas apenas uma tabela em particular.
O processo mysql parece não ter limite de ram. Eu tentei um tamanho de buffer pool de 9gb e ele travou (eu tenho 13 gb de ram), agora são 7gb e o problema continua. O perfil de ram usando preformance_schema diz que ele não deve usar mais do que 9,6 gb de ram, nenhuma variável em performance_schema parece consumir muita memória. Mas o processo mysqld consome quase 12 gb e cresce
A configuração do mysql se parece com isso:
[client]
port = 3306
socket = /var/lib/mysql/mysql.sock
[mysqld]
user = mysql
port = 3306
socket = /var/lib/mysql/mysql.sock
mysql_native_password=ON
# Basic Settings
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
pid-file = /var/run/mysqld/mysqld.pid
# log_error = /var/log/mysql/error.log
# Server Performance
skip-name-resolve
max_connections = 3000
table_open_cache = 4000
table_open_cache_instances = 8
thread_cache_size = 50
# Memory Settings
innodb_buffer_pool_size = 9G
innodb_buffer_pool_instances = 9
innodb_log_file_size = 2G # Adjust this based on your transaction log needs
innodb_log_buffer_size = 64M
innodb_file_per_table = 1
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 1
innodb_thread_concurrency = 16
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_io_capacity = 250
innodb_io_capacity_max = 500
innodb_purge_threads = 4
# Caching and I/O
# query_cache_type = 0
# query_cache_size = 0
tmp_table_size = 256M
max_heap_table_size = 256M
# join_buffer_size = 16M
# sort_buffer_size = 4M
# read_buffer_size = 4M
# read_rnd_buffer_size = 8M
# Character Set and Collation
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci
# Binary Logging - Recommended for Replication and Point-in-Time Recovery
# log_bin = /var/log/mysql/mysql-bin.log
# expire_logs_days = 7
# sync_binlog = 1
# binlog_format = ROW
# Error Log Settings
# log_error_verbosity = 3
# Security
max_allowed_packet = 64M
sql_mode = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
innodb_strict_mode = 1
# Additional Settings
performance_schema = ON
event_scheduler = ON
default_storage_engine = InnoDB
# Adjusting InnoDB Autoinc Lock Mode
innodb_autoinc_lock_mode = 2
[mysqldump]
quick
quote-names
[mysql]
no-auto-rehash
Não quero dizer que ele não deva consumir mais memória do que o buffer_pool_size. Usando esta consulta, calculo o uso total de ram:
SELECT
@@innodb_buffer_pool_size AS innodb_buffer_pool_size,
@@innodb_log_buffer_size AS innodb_log_buffer_size,
@@key_buffer_size AS key_buffer_size,
@@tmp_table_size AS tmp_table_size,
@@max_connections * (
@@read_buffer_size +
@@read_rnd_buffer_size +
@@sort_buffer_size +
@@join_buffer_size +
@@binlog_cache_size +
@@thread_stack
) AS max_connections_memory,
(@@innodb_buffer_pool_size +
@@innodb_log_buffer_size +
@@key_buffer_size +
@@tmp_table_size +
@@max_connections * (
@@read_buffer_size +
@@read_rnd_buffer_size +
@@sort_buffer_size +
@@join_buffer_size +
@@binlog_cache_size +
@@thread_stack
)) AS total_memory_usage
\G
E a saída:
innodb_buffer_pool_size: 6039797760
innodb_log_buffer_size: 67108864
key_buffer_size: 8388608
tmp_table_size: 1000000
max_connections_memory: 99942400
total_memory_usage: 6216237632
A saída não é a mesma do mysqlconfig porque eu fiz buffer_pool_size menor e reduzi o max_connections para que ele não consuma toda a memória disponível. Se a consulta estiver correta, ela deve usar no máximo cerca de 6,5 gb, mas usa 10, 11 e cresce
A versão do MySQL é 8.4.0
O seguinte é ilegal.
SELECT
schema_id + 2 AS evil_column
FROM
sys.tables
ORDER BY
evil_column + 3;
Se você remover o + 3, então é legal.
Supondo que eu queira fazer aritmética com evil_columne ORDER BYo resultado, mas não queira repetir a definição de evil_columnem lugar nenhum, quais são minhas opções?
Tenho um usuário muito antigo chamado "ADMINX" que tem controle em quase todos os tablespaces em um banco de dados Oracle 19c. Ele recebeu a função "DBA" e também uma função personalizada chamada "APP_ADMIN_ROLE" que tem a função DBA dentro.
Se eu revogar a função DBA do próprio ADMINX, mas deixar o APP_ADMIN_ROLE como está, as cotas do tablespace seriam redefinidas? Suponho que ele deva manter cotas ilimitadas, já que o APP_ADMIN_ROLE ainda tem a função DBA dentro, mas nunca tenho certeza de como o Oracle se comporta nesses casos. Infelizmente, o DBA_TS_QUOTAS não mostra cotas ilimitadas tomadas pelas funções DBA.
Tenho uma tabela de usuários imutável que armazena dados de usuários, dependendo da função (uma conexão 1-M com a tabela de funções), o usuário pode ser um trabalhador do estabelecimento ou um proprietário do estabelecimento. Preciso adicionar o estabelecimento, onde o estabelecimento pode ter um único proprietário, mas muitos trabalhadores. Qual é a solução ideal para esse problema?
Existe alguma vantagem funcional ou perda de desempenho ao usar RLS na tabela em vez de usar uma condição em uma exibição dessa tabela (enquanto oculta a tabela)?
Parece-me que, em vez de usar RLS em uma tabela, o que é necessário posteriormente em algumas visualizações, as visualizações podem ser limitadas em sua condição where, sem conceder nenhum acesso direto à tabela.
Existe alguma recomendação geral sobre onde escolher RLS e onde NÃO escolher RLS em favor da condição tradicional?
Tenho um usuário oracle personalizado (digamos monitor_user) que tem muitos procedimentos e trabalhos que enviam e-mails com resultados de consulta. Mas, por motivos de segurança, quero desabilitar seu login no banco de dados de um cliente externo. Como faço isso? Acho que remover "CREATE SESSION" não vai me ajudar.