BBlake's questions

Eu tenho um conjunto de horários de início e término que preciso armazenar em um banco de dados Oracle. Eu preciso armazená-los de uma maneira que os torne facilmente pesquisáveis ​​(ou seja, uma pesquisa típica é encontrar todas as linhas em que um valor de tempo, como 9h30, fica entre o horário de início e o horário de término). No SQL Server, eu usaria apenas um campo de tipo de dados TIME, mas o Oracle não parece ter um equivalente.

Já vi vários blogs e fóruns que recomendam apenas usar um campo DATE e fazer conversões com TO_CHAR e depois comparar ou armazenar os valores de tempo como campos varchar(4 / HHMM) ou varchar(6 / HHMMSS). Ambos parecem desnecessariamente ineficientes.

Existe uma maneira melhor ou mais eficiente de fazer isso no Oracle?

Tenho trabalhado no código em T-SQL para adicionar novos agendamentos a um trabalho do SQL Agent usando o proc sp_add_jobschedule no banco de dados msdb. Quando adiciono um novo agendamento (normalmente uma execução única em uma data/hora específica) e imediatamente vejo os valores em sysjobschedules e sysschedules, posso ver que o novo agendamento foi adicionado e está vinculado ao job_id para meu SQL Agent trabalho. No entanto, os valores para next_run_date e next_run_time têm 0 neles. Quando volto e olho para eles novamente em 2 ou 3 minutos, eles ainda mostram 0 neles. No entanto, quando volto 5 ou 10 minutos depois, ele agora mostra corretamente os valores de data e hora correspondentes à próxima execução agendada.

Então minhas perguntas são:

• Com que frequência esses valores são atualizados?
• Que processo é esse que atualiza esses valores?
• Se eu adicionasse um agendamento que fosse, digamos, 1 minuto no futuro, isso significa que o trabalho não será executado, pois next_run_date/time ainda não foi atualizado?

Exemplo do código que uso para adicionar um novo agendamento:

exec msdb.dbo.sp_add_jobschedule @job_id = @jobID
                    , @name = @JobName
                    , @enabled = 1
                    , @freq_type = 1
                    , @freq_interval = 0
                    , @freq_subday_type = 0
                    , @freq_subday_interval = 0
                    , @freq_relative_interval = 0
                    , @freq_recurrence_factor = 0
                    , @active_start_date = @ScheduleRunDate
                    , @active_end_date = 99991231
                    , @active_start_time = @ScheduleRunTime
                    , @active_end_time = 235959

onde @jobID é binary(16) que contém o job_id do trabalho em questão, @ScheduleRunDate e @ScheduleRunTime são INTs com a data e hora respectivamente.

Temos um código herdado que ainda usa chamadas xp_cmdshell. Quando migramos para o SQL Server 2008, criamos um procedimento armazenado que usava o código conforme o seguinte padrão:

EXECUTE AS 'DOMAIN\ID2'
EXEC master..xp_cmdshell @command
REVERT

Quando passo WHOAMI como comando, o que mostra não é o 'DOMAIN\ID2', mas sim o ID da conta de serviço sob a qual o SQL Server está sendo executado (ou seja, 'DOMAIN\ID1'). Não deveria estar retornando 'DOMAIN\ID2', pois supostamente está sendo executado em um contexto de segurança diferente? Em caso afirmativo, alguma ideia de por que não mudaria o contexto? Este processo foi criado por outro desenvolvedor que já se foi há muito tempo e não estou realmente familiarizado com segurança e representação como provavelmente deveria estar.