CaM's questions

Em Javascript, Excel, Python e uma calculadora científica, a operação de módulo

-34086.1576962834 % 360.0      <-- python
=MOD(-34086.1576962834, 360.0) <-- Excel function

dá um valor de 113.84230371659942. (Ou algo muito próximo disso, dependendo do número de casas decimais e arredondamento.)

Mas no T-SQL,

Select -34086.1576962834 % 360.0

retorna um valor de -246.1576962834.

eu tentei usar

Select cast(-34086.1576962834 as numeric(30,15)) % cast(360.0 as numeric(30,15))

Como eu estava pensando, talvez este fosse um exemplo de flutuação versus matemática decimal fixa que não correspondia, mas isso não resolve.

Por que o SQL Server não executa esta operação de maneira consistente com as calculadoras/resultados esperados? E mais importante, existe uma maneira de fazer o T-SQL fazer aritmética da mesma forma que minha calculadora faz?

Estou usando principalmente o SQL Server 2019, mas confirmei que o SQL Server 2012 e 2014 também fornecem os mesmos -246... resultados.

A função Oracle mod(x,y)e o python math.fmod(x,y)fornecem o mesmo resultado -246.nnn.

Tenho uma função no SQL Server 2019 que copia dados de uma tabela local para uma tabela Oracle 11.2.0.4 via Linked Server, utilizando cliente Oracle 19.3. Recentemente, uma nova coluna foi adicionada à tabela Oracle, então atualizei a função insert para incluir essa nova coluna.

Agora, sempre que eu modificar a função, ela será executada com sucesso uma vez e apenas uma vez. Se eu limpar o cache de consulta, ele também será executado uma vez e começará a gerar o erro a partir de então. TODAS as tentativas de execução após a primeira vez lançam este erro:

Msg 7353, nível 16, estado 1, procedimento COD.Interface_Upload, linha 29 [Batch Start Line 20] O provedor OLE DB "OraOLEDB.Oracle" para o servidor vinculado "ORADEV-LINK" forneceu metadados inconsistentes. Uma coluna extra foi fornecida durante a execução que não foi encontrada em tempo de compilação.

A única alteração neste procedimento da versão anterior, de trabalho, é adicionar o campo DATE_SUBMITTED e a parte "select min([Sample_date]) ..." para fornecer essa coluna.

Tudo o que posso encontrar diz que, se você estiver recebendo erros de metadados, vá para a sintaxe OPENQUERY, que é o que estou usando.

A função é:

ALTER Procedure [COD].[Interface_Upload]
  As
    SET NOCOUNT ON;
 
    INSERT OPENQUERY([ORADEV-LINK], 'SELECT ACCOUNT_NUMBER, FROM_DATE, TO_DATE, 
            COD_TO_BOD_FACTOR, CONSUMPTION, SAMPLE_DATE, COD_CONTENT, SS_CONTENT,
            DATE_SUBMITTED from cbd.WS_CBD_PACS')
        Select [Account_Number]
            ,[From_Date]        ,[To_Date]
            ,[Factor]           ,[Consumption]
            ,[Sample_date]      ,[COD]
            ,[SS]
            , ( select min([Sample_date]) 
                from dbo.ORA_Interface 
                where Account_Number = p.Account_Number )
        from dbo.ORA_Interface p ;

    Return @@rowcount;
GO

A definição da tabela de destino do Oracle é:

                         Null?    Type
 ----------------------- -------- -------
 ACCOUNT_NUMBER          NOT NULL NUMBER(13)
 FROM_DATE               NOT NULL DATE
 TO_DATE                 NOT NULL DATE
 COD_TO_BOD_FACTOR       NOT NULL NUMBER(6,2)
 CONSUMPTION             NOT NULL NUMBER(15)
 SAMPLE_DATE             NOT NULL DATE
 COD_CONTENT             NOT NULL NUMBER(10)
 SS_CONTENT              NOT NULL NUMBER(10)
 DATE_SUBMITTED                   DATE

A definição da tabela de origem do SQL Server é:

[Account_Number] [varchar](30) NULL,
[From_Date] [datetime] NULL,
[To_Date] [datetime] NULL,
[Factor] [numeric](15, 2) NULL,
[Consumption] [numeric](15, 2) NULL,
[Sample_date] [datetime] NULL,
[COD] [numeric](15, 2) NULL,
[SS] [numeric](15, 2) NULL 

Eu tenho um procedimento armazenado complexo que consulta pastas de rede específicas, coleta os nomes dos arquivos de backup do SQL Server que encontra lá e processa cada arquivo para obter detalhes. Se eu executar o procedimento do SSMS versão 18.4, ele dará os resultados errados. Mas se eu executá-lo no SSMS versão 17.9, o procedimento me fornecerá os dados que espero ver.

Eu posso recriar o problema com um exemplo mais simples:

CREATE OR ALTER PROCEDURE TestOutput (
    @HostName nvarchar(255),
    @DbName nvarchar(255)
    )
AS
BEGIN
    Declare @cmd nvarchar(500);
    Declare @basePath nvarchar(500) = '\\Server1\DB_Backups\SQL\' + @HostName + '\' + @DbName + '\';

    Create table #FullFileList (backupPath nvarchar(255), backupFile NVARCHAR(255)) ;

    SET @cmd = 'DIR /b "' + @basePath + 'Full\"';
    INSERT INTO  #FullFileList (backupFile) EXEC master.sys.xp_cmdshell @cmd;
    update #FullFileList set backupPath = @basePath + 'Full\';

    SET @cmd = 'DIR /b "' + @basePath + 'Diff\"';
    INSERT INTO  #FullFileList (backupFile) EXEC master.sys.xp_cmdshell @cmd 
    update #FullFileList set backupPath = @basePath + 'Diff\' where backupPath is null;     

    SET @cmd = 'DIR /b "' + @basePath + 'Log\"'
    INSERT INTO  #FullFileList (backupFile) EXEC master.sys.xp_cmdshell @cmd;
    update #FullFileList set backupPath = @basePath + 'Log\' where backupPath is null;

    select * from #FullFileList;
    select count(*) from #FullFileList;
END
GO

Se eu executar este procedimento do SSMS versão 17.9 em uma pasta pai (caminho base) que contém 1.950 arquivos nas três subpastas, a saída será 1.953 linhas (três linhas com nomes de arquivo nulos estão na lista, uma para cada pasta). E a saída da contagem é 1.953.

\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Full\    Host_Name_DB_Name_FULL_20191230_040407.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Full\    Host_Name_DB_Name_FULL_20200106_040407.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Full\    Host_Name_DB_Name_FULL_20200113_040407.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Full\    NULL
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200103_050507.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200104_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200105_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200107_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200108_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200109_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200110_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200111_050507.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200112_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200114_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200115_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    Host_Name_DB_Name_DIFF_20200116_050506.bak
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Diff\    NULL
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200112_104703.trn
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200112_105003.trn
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200112_105302.trn
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200112_105602.trn
[... Snip ...]
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200116_144402.trn
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ Host_Name_DB_Name_LOG_20200116_144703.trn
\\Server1\DB_Backups\SQL\Host_Name\DB_Name\Log\ NULL

 1953

No entanto, se eu executar esse mesmo código no SSMS versão 18.4, o procedimento produzirá 9 linhas de saída. Ele também me diz que a contagem é de 22 linhas, o que também é falso: a saída acabou de ser fornecida; havia apenas nove linhas retornadas.

\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Full\ WTR320MSDNCM_DBMonitoring_FULL_20191230_040407.bak
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Full\ WTR320MSDNCM_DBMonitoring_FULL_20200106_040407.bak
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Full\ WTR320MSDNCM_DBMonitoring_FULL_20200113_040407.bak
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Full\ NULL
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Log\  WTR320MSDNCM_DBMonitoring_LOG_20200112_104703.trn
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Log\  WTR320MSDNCM_DBMonitoring_LOG_20200112_105003.trn
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Log\  WTR320MSDNCM_DBMonitoring_LOG_20200112_105302.trn
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Log\  WTR320MSDNCM_DBMonitoring_LOG_20200112_105602.trn
\\wtrnas\DB_Backups\SQL\wtr320msdncm\DBMonitoring\Log\  WTR320MSDNCM_DBMonitoring_LOG_20200112_105902.trn

22

(são todas as linhas retornadas quando executadas a partir de 18.4)

Novamente, exatamente o mesmo código, mesmo mecanismo de banco de dados no back-end (Microsoft SQL Server 2017 CU18 Enterprise Edition no Windows Server 2012 R2 Standard), apontado para a mesma estrutura de pastas no Server1. A única diferença é a versão do SSMS que executa o comando create procedure.

Observe que o SQLCMD também fornece a saída correta.

Eu tentei desinstalar e reinstalar o SSMS 18.4. Eu também tentei mudar isso para uma tabela não temporária. A versão do SSMS 18.4 cria 9 linhas de dados, não 1953 linhas, que posso visualizar de fora do procedimento. Eu tentei mudar a ordem em que as pastas são processadas; isso não altera o resultado.

O SQL Server tem todas as permissões necessárias para navegar nas três pastas em questão; ele realmente escreveu esses arquivos.

Mas por que a versão do SSMS é um fator? Isso tudo deve ser executado a partir do servidor, que não está mudando aqui. Como posso fazer este procedimento funcionar corretamente em 18.4, ou por que NÃO está funcionando corretamente?

Estou tentando entender a saída de um SQL Trace de um banco de dados Oracle 12.2 no Windows. Eu usei TKPROF para interpretar os arquivos de rastreamento resultantes. Este utilitário gera uma saída de arquivo de texto e uma saída de arquivo SQL. Mas os dados não coincidem entre os dois arquivos.

Os dados foram gerados usando sintaxe comotkprof Trace.trc trace.trc.txt insert=trace.trc.sql

Para uma consulta específica, a saída TKPROF via arquivo de texto é:

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     13      0.04       0.03          0          0          1           0
Fetch       13      0.00       0.07          6         26          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       27      0.04       0.11          6         26          1           0

Mas a saída SQL do TKPROF gera dados para essa consulta que não tem os mesmos números da coluna Elapsed.

Aqui está a instrução Insert:

INSERT INTO tkprof_table (
    date_of_insert, cursor_num, depth, user_id,
    parse_cnt,   parse_cpu, parse_elap, parse_disk, parse_query, parse_current, parse_miss,
    exe_count,   exe_cpu,   exe_elap,   exe_disk,   exe_query,   exe_current,   exe_miss,  exe_rows,
    fetch_count, fetch_cpu, fetch_elap, fetch_disk, fetch_query, fetch_current, fetch_rows,
    ticks, sql_statement
    )
VALUES
(
  SYSDATE, 4, 0, 9, 
  1, 0, 86, 0, 0, 0, 0, 
  13,46875, 31424, 0, 0, 1, 2, 0,
  13, 0, 79075, 6, 26, 0, 0, 152918 
, 'SELECT [...]')

E, em seguida, converter essas colunas SQL para corresponder ao layout da tabela do arquivo de texto que se torna:

call     count       cpu    elapsed    disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0       86          0          0          0           0
Execute     13      46875   31424       0          0          1           0
Fetch       13      0       79075       6         26          0           0

A documentação da Oracle diz que os valores de TKPROF Elapsed são

"tempo total decorrido em segundos para todas as chamadas de análise, execução ou busca para a instrução."

E acredito que seja preciso para a saída do arquivo de texto. Mas os dados SQL devem ser alguma outra medida. Não consigo encontrar nenhuma documentação que defina uma unidade de medida para os dados incompatíveis.

Há uma coluna "ticks", que parece corresponder aos ticks da CPU. Mas não sei se é isso que os valores incompatíveis são também. Em caso afirmativo, como faço para converter esses dados em segundos?

Ou parece que esses valores podem ser microssegundos. Isso é correto? Existe algum lugar que defina definitivamente essa unidade de medida?

Estamos migrando uma aplicação de Oracle para SQL Server. O fornecedor é responsável pela maioria dos esforços de migração, mas há uma parte desenvolvida internamente com a qual estou tendo problemas.

A aplicação antiga no Oracle tem um procedimento que coleta dados específicos e, em seguida, outro procedimento insere esses dados em uma tabela de teste em nosso sistema de receita (um servidor Oracle diferente). Este é um procedimento Oracle por meio de um Oracle Public Database Link.

No SQL Server, estou tentando reescrever esse processo usando os servidores vinculados do SQL Server. Criei a conexão do Linked Server com o sistema de receita e ele pode se conectar por meio desse link.

No SQL*Plus, posso emitir esta instrução como esse usuário:

select * from rs.rs_myapp;

E obtenho resultados. (rs é o usuário do sistema de receita, não o usuário com o qual me conecto. A tabela rs_MyApp é a tabela de teste para nossos dados em seu sistema.)

Mas se eu tentar fazer isso no SQL Server:

select * from [rstest-Link]..rs.rs_myapp

Recebo esta mensagem:

Msg 7314, nível 16, estado 1, linha 50 O provedor OLE DB "OraOLEDB.Oracle" para o servidor vinculado "rstest-Link" não contém a tabela ""rs".."rs_myapp"". A tabela não existe ou o usuário atual não tem permissões nessa tabela.

Eu posso fazer isso, no entanto:

select * from openquery([rstest-Link], 'select count(*) from rs.rs_myapp')

E isso traz resultados de volta, mostrando que o link funciona.

No entanto, não consigo concluir o procedimento do SQL Server, devido a esse erro 7314. O procedimento é bem básico, tem exatamente uma linha de código:

Insert Into [rstest-Link]..rs.rs_myapp (ACCOUNT_NUMBER, FROM_DATE, TO_DATE, 
        Data1, Data2, SAMPLE_DATE, Content1, Content2) 
    select ACCOUNT_NUMBER, FROM_DATE, TO_DATE, MyData1, MyData2, SAMPLE_DATE, MyContent1, MyContent2 
    FROM dbo.RS_INTERFACE;

Mas sem resolver o erro 7314, não há como criar o procedimento.

Então, como eu faço isso? Vou ter que usar um cursor e emitir algum tipo de código para cada linha, como:

INSERT OPENQUERY ([rstest-Link], 'SELECT ... FROM ...')  
VALUES ('...');