Eu gostaria de definir uma variável de sessão dentro de uma função, usando os valores passados para a função.
Exemplo:
CREATE FUNCTION my_function(my_param INT)
RETURNS VOID AS $$
BEGIN
SET SESSION "myapp.myvar" = my_param;
END
$$
LANGUAGE plpgsql;
SELECT * FROM my_function(100);
SELECT current_setting('myapp.myvar');
O que eu ganho:
my_param
O que eu quero:
100
Estamos usando um procedimento armazenado SQLCLR para ativação do agente de serviços e desejo monitorar a memória usada pelo código CLR. Olhando para sys.dm_os_memory_clerks, vejo que apenas o nó NUMA 1 tem páginas associadas ao MEMORYCLERK_SQLCLRtipo. O servidor tem duas CPUs de 8 núcleos e está executando o SQL 2014 CU6.
Isso é esperado? Ou devo ver a memória usada em ambos os nós, como faço com MEMORYCLERK_SQLBUFFERPOOL?
Consulta:
SELECT DOMC.memory_node_id
, DOMC.pages_kb
, DOMC.virtual_memory_reserved_kb
, DOMC.virtual_memory_committed_kb
FROM sys.dm_os_memory_clerks DOMC where type = 'MEMORYCLERK_SQLCLR'
Resultados:
memory_node_id pages_kb virtual_memory_reserved_kb virtual_memory_committed_kb
-------------- -------------------- -------------------------- ---------------------------
0 88232 12607744 1408652
1 0 0 0
64 0 0 0
Eu tenho um procedimento armazenado CLR que (entre outras coisas) chama um procedimento armazenado TSQL. O procedimento armazenado TSQL executa algum SQL dinâmico e imprime o SQL antes de ser executado para fins de depuração. Nada das PRINTdeclarações aparece no cliente. Qual é uma boa maneira de nos permitir ver esses comandos quando precisamos solucionar problemas?
Código de amostra:
Código C# em dll
public static void Print_CLR()
{
using (SqlConnection conn = new SqlConnection("context connection=true"))
{
conn.Open();
using (SqlCommand c = new SqlCommand("exec dbo.Print_TSQL", conn))
{
c.ExecuteNonQuery();
}
}
}
Processo chamado por CLR
CREATE PROC DBO.Print_TSQL AS
PRINT 'WTF'
GO
--Exposing proc to SQL
CREATE PROC dbo.Print_CLR AS
EXTERNAL NAME
[CLRUtility].[CLRUtility.CLRUtility].Print_CLR
GO
--Executing, nothing is PRINTed for the client
EXEC dbo.Print_CLR
Estou chamando um procedimento armazenado T-SQL de um procedimento armazenado CLR. e a THROWinstrução em T-SQL interrompe a execução do CLR sem entrar no catchbloco. Existe algo que eu possa mudar no meu código para fazer com que o procedimento CLR execute o catchbloco?
T-SQL:
CREATE TABLE t1 (ID INT PRIMARY KEY clustered);
CREATE TABLE t2 (ID INT CONSTRAINT fk_1 FOREIGN KEY REFERENCES t1(ID))
GO
CREATE PROC dbo.TestThrow
AS
BEGIN
BEGIN TRY
INSERT INTO t2 VALUES (1)
END TRY
BEGIN CATCH
THROW
END CATCH
END
GO
CLR:
public static void TestThrow()
{
String query = "EXEC DBO.TESTTHROW";
using (SqlConnection connection = new SqlConnection("context connection=true"))
{
connection.Open();
try
{
using (SqlCommand command = new SqlCommand(query, connection))
{
using (SqlDataReader reader = command.ExecuteReader())
{
SqlContext.Pipe.Send("no error");
}
}
}
catch (SqlException e)
{
SqlContext.Pipe.Send("sqlexception");
SqlContext.Pipe.Send(e.Message);
}
catch (Exception e)
{
SqlContext.Pipe.Send("exception");
SqlContext.Pipe.Send(e.Message);
}
}
}
Estou transferindo um conjunto de procedimentos armazenados T-SQL para C#/CLR. No T-SQL, usamos XACT_STATE() para determinar se um erro requer a reversão para um ponto de salvamento ou a reversão total da transação.
Não consigo encontrar uma verificação equivalente da transação usando os objetos System.Data.SqlClient.SqlTransactionou .System.Transactions.TransactionScope
Alguém sabe como verificar o estado da transação em C#/CLR?
Recentemente, alterei as configurações de Autogrow para alguns dos bancos de dados em nosso servidor SQL Server 2008 R2. Eles estão envolvidos em uma configuração de espelhamento de banco de dados, com o principal em SERVER1 e o espelho em SERVER2 .
Esta semana, falhei em três bancos de dados - agora o SERVER1 é o espelho e o SERVER2 é o principal para esses bancos de dados. Parece que as configurações de crescimento automático não foram transferidas para o SERVER2 corretamente, pois os bancos de dados agora mostram que elas crescem em uma porcentagem (duas são definidas para 32768%, a outra para 131072%).
Isso é diferente das configurações que costumavam estar lá (acredito que era o padrão - 10%) e também diferente dos 256 MB que configurei no SERVER1 .
Para tornar as coisas mais confusas, isso está acontecendo apenas no arquivo principal - os arquivos secundários e o arquivo de log mantiveram as configurações definidas em SERVER1 .
Minha suspeita é que isso seja um bug - eu corrigi o SQL depois de alterar as configurações de crescimento automático. Minha pergunta é: alguém já viu esse cenário antes? Existe um método para garantir que todas as configurações estejam corretas em ambos os servidores sem falhar todos os bancos de dados?
ATUALIZAÇÃO: Usando um quarto banco de dados que chamarei de DB1 , defino o crescimento automático no SERVER1 para 512 MB (depois de fazer o failover do banco de dados, testemunhar o mesmo problema e fazer o failback). Quando fiz o failover para o SERVER2 depois disso, ele mostrou um crescimento de 65536%. A conclusão é que o is_autogrow_percentvalor em sys.master_filesnão está se movendo para SERVER2 , mas sim growth.
ATUALIZAÇÃO2: Com DB1 em SERVER1 , alterei o crescimento automático para 10% e falhei para SERVER2 . O valor de 10% permaneceu. Em seguida, repeti isso, definindo o crescimento automático de volta para 256 MB desta vez. Novamente, o growthvalor mudou, mas is_autogrow_percentnão.
Eu tive duas instâncias na última semana em que um DROPcomando para uma sessão de Eventos Estendidos levou mais de um dia para ser concluído, esperando com a espera: PREEMPTIVE_XE_CALLBACKEXECUTE.
Alguém pode explicar o que significa esse tipo de espera?
Mais informações básicas:
Na primeira instância, executei um comando T-SQL para encerrar a sessão e ela foi concluída um dia depois. Usando sp_whoisactive, vi que a query estava esperando PREEMPTIVE_XE_CALLBACKEXECUTE.
Durante esse tempo, as consultas do Object Explorer para coletar metadados estavam sendo bloqueadas e recebendo bloqueios de tempo limite, mas não houve outras reclamações (ou assim pensei na época).
Tentei cancelar outra sessão na sexta-feira e ocorreu o mesmo comportamento, exceto que não desapareceu após um dia como no primeiro evento. Em vez disso, descobri esta manhã que o aplicativo cliente não pôde se conectar. Estava sendo bloqueado pela DROP EVENT SESSIONconsulta.
Uma reinicialização do serviço SQL limpou a consulta de bloqueio.
Não consigo encontrar nada que ajude a diagnosticar o que é esse tipo de espera ... e por que minhas sessões de evento não caem como deveriam. Você pode ajudar?
Informações do servidor: SQL 2008 R2 Enterprise com SP2
Eu tenho uma instrução delete que está usando um plano ruim quando executado dentro de um procedimento armazenado, mas está escolhendo um plano muito melhor quando executado ad-hoc.
Reconstruí todos os índices das tabelas usadas pela consulta e eliminei todos os caches. O otimizador ainda escolhe o plano errado para o procedimento armazenado.
Gostaria de saber por que o otimizador está usando um plano de execução diferente para o procedimento armazenado versus o SQL ad-hoc.
Estou tentando criar um arquivo .ini para instalações autônomas do SQL Server 2008 R2. Segui esta postagem do blog para criar um arquivo .ini inicial: http://blogesh.wordpress.com/2008/09/23/silent-install-of-sql-server-2008/
Depois de cancelar a instalação e tentar instalar a partir da linha de comando (\server\store\SQL\setup.exe /ConfigurationFile="\server\store\SQL\Config.ini"), recebo este erro - "Caracteres ilegais no caminho ."
Recebo esse erro depois de resolver vários erros mais simples (como caminhos aparecendo sem "\") porque o arquivo .ini criado tinha alguns bugs (como listar o caminho como "R:" no .ini)
Gostaria de saber se alguém conseguiu instalar um cluster usando um arquivo ini. Qualquer ajuda é apreciada.
Atualização: tentei instalar o cluster usando o ini criado a partir do script powershell do sirsql.net. O SQL é instalado agora, mas não consegue colocar o nome da rede online (no Failover Cluster Manager). Todas as configurações parecem idênticas aos nossos clusters (funcionais) existentes, mas uma captura do Wireshark mostra que o novo cluster está usando o "reino" do domínio pai em vez do domínio filho (o domínio do servidor e o domínio de todas as contas de serviço , incluindo a conta que estou usando para instalar). Nossos clusters funcionais mostram o "reino" como o domínio filho. O pacote que volta do controlador de domínio mostra este erro de Kerberos: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.
Eu realmente gostaria de obter uma configuração de cluster de failover sem ter que passar pelo gui, pois construímos alguns novos clusters a cada semana. Alguma idéia sobre o que poderia estar causando isso ou como corrigi-lo?