a_horse_with_no_name's questions

Percebi uma diferença na avaliação de uma expressão de caminho SQL/JSON entre Oracle e Postgres e me pergunto qual está correta.

Considere a seguinte estrutura JSON:

{
  "key1": {"id":1000, "price": 42},
  "key2": {"id":2000, "price": 3.14},
  "key3": {"id":3000, "price": 2.7}
}

Para obter o preço do produto com ID = 1000, o Postgres me permite usar a seguinte expressão de caminho JSON:

jsonb_path_query(doc, '$.* ? (@.id == 1000).price')

No entanto, ao usar o Oracle json_value()(ou json_query()- não importa)

json_value(doc, '$.* ? (@.id == 1000).price')

Eu recebo o seguinte erro (usando Oracle 18c):

 ORA-40597: JSON path expression syntax error ('$.* ? (@.id == 1000).price')
 JZN-00209: Unexpected characters after end of path
 at position 21

Há uma solução alternativa no Oracle 18c:

json_value(json_query(doc, '$.* ? (@.id == 1000)'), '$.price')

Então minha pergunta é:

O padrão SQL permite o acesso à propriedade como feito na implementação do Postgres?
Ou isso simplesmente não está especificado no padrão e marcado como "dependente da implementação"?

^{(Dado o histórico do Postgres em manter o padrão o máximo possível, suspeito que o Postgres esteja correto e a Oracle não esteja implementando o padrão completo)}

Estamos tentando descobrir por que uma instrução (bem complicada) tem uma variação extremamente alta em tempo de execução. Às vezes leva apenas "minutos" (cerca de 40-50) e às vezes não termina mesmo depois de 12 horas.

Minha abordagem usual para problemas como esse é verificar se a instrução é monitorada e, se for, obter a execução "em tempo real" dela usando dbms_sqltune.report_sql_monitor()para que eu possa identificar o gargalo na execução.

No entanto, essa instrução específica nunca é monitorada pela Oracle. De acordo com o manual da Oracle, uma instrução é monitorada, se:

Por padrão, o monitoramento SQL é iniciado automaticamente quando uma instrução SQL é executada em paralelo ou consumiu pelo menos 5 segundos de CPU e tempo de E/S combinados em uma única execução

Como essa instrução é executada por mais de 5 segundos e usa execução paralela, ela deve ser monitorada.

Até adicionamos as dicas gather_plan_statisticse monitorao SQL para forçar o monitoramento da instrução, mas ainda não é monitorado.

De acordo com "My Oracle Support" (DocID: 1613163.1) o monitoramento é limitado a instruções com um plano com menos de 300 linhas. Quando eu gero o plano, ele tem 282 linhas (= ID de linha mais alto do plano), então isso não deve impedir o monitoramento.

Existe um parâmetro oculto ( "_sqlmon_max_planlines") que controla isso, mas este é um servidor de banco de dados hospedado e alterar algo assim é bastante complicado.

Então minha pergunta é:

Existem outras restrições (talvez não documentadas) sobre por que a Oracle não monitoraria uma instrução?

Este é um Oracle 11.2.0.3 Enterprise Edition (a atualização para 11.2.0.4 está agendada, mas isso pode levar algum tempo).

Estou tentando encontrar a coluna (ou tabela) que pertence a um segmento LOB bastante grande:

select segment_name, segment_type, bytes 
from dba_segments 
where segment_name = 'SYS_LOB0000103936C00014$$';

retorna:

SEGMENT_NAME              | SEGMENT_TYPE | BYTES
--------------------------+--------------+-------------
SYS_LOB0000103936C00014$$ | LOBSEGMENT   | 422877069312

No entanto, quando tento encontrar a tabela correspondente:

select table_name, column_name, segment_name, tablespace_name, index_name 
from dba_lobs 
where segment_name = 'SYS_LOB0000103936C00014$$';

Nenhuma linha é retornada.

Existe algum outro local onde as informações sobre esse segmento LOB são armazenadas?

Este é um Oracle 11.2.0.4 (RAC) executando RHEL 6.8

Posso alterar (substituir) o nível atual de paralelismo em uma sessão do Oracle usando, por exemplo:

alter session force parallel query parallel 6;

Existe alguma visão do sistema de função que me retorne o valor 6que solicitei?

Gostaria de verificar (em um procedimento armazenado) se minha sessão atual mudou isso (idealmente a configuração de um alter session force parallel dmltambém)

Estamos usando dbms_datapumppara copiar dados entre diferentes servidores ou para configurar novos esquemas rapidamente.

No entanto, a importação de estatísticas geralmente leva muito tempo e tem a desvantagem adicional de que as estatísticas do esquema são bloqueadas após a importação.

Então, estou tentando encontrar uma maneira de pular a importação das estatísticas.

De acordo com Metalink Doc ID 1392981.1, isso deve ser possível usando:

dbms_datapump.metadata_filter(handle => l_job_handle, 
      name => 'EXCLUDE_PATH_LIST', 
      value => '''STATISTICS''');

No entanto, quando tento isso, recebo um erro "ORA-39001: valor de argumento inválido".

Eu também tentei vários outros formatos encontrados em lugares diferentes:

dbms_datapump.metadata_filter(handle => l_job_handle, 
      name => 'EXCLUDE_PATH_LIST', 
      value => 'STATISTICS');

dbms_datapump.metadata_filter(handle => l_job_handle, 
       name => 'EXCLUDE_PATH_EXPR', 
       value => 'like ''%/TABLE/STATISTICS/TABLE_STATISTICS''');

dbms_datapump.metadata_filter(handle => l_job_handle, 
       name => 'EXCLUDE_PATH_EXPR', 
       value => 'like ''%STATISTICS%''');

Mas todos eles retornam com um ORA-39001.

A versão que estou usando é:

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - Produção de 64 bits

O sistema operacional é um Windows Server, mas isso também ocorre em uma instalação do Linux.

Alguma ideia de como posso pular as estatísticas durante a importação (ou exportação) por meio da DBMS_DATAPUMPAPI?

Estou tentando entender/aprender a rastrear os detalhes de uma sessão bloqueada.

Então criei a seguinte configuração:

create table foo (id integer not null primary key, some_data varchar(20));
insert into foo values (1, 'foo');
commit;

Agora eu me conecto ao banco de dados duas vezes de dois clientes diferentes.

As questões da primeira sessão:

begin transaction
update foo set some_data = 'update'
  where id = 1;

Eu explicitamente não me comprometo lá para manter os bloqueios.

Na segunda sessão eu emito a mesma declaração e claro que uma espera devido ao travamento. Agora estou tentando usar as diferentes consultas que circulam para ver que a sessão 2 está aguardando a footabela.

sp_who2mostra o seguinte (removi algumas colunas para mostrar apenas as informações importantes):

SPID | Situação | BlkBy | DBName | Comando | SPID | IDENTIFICAÇÃO DO PEDIDO
-----+--------------+-------+----------+---------- --------+------+----------
52 | dormindo | . | comidab | AGUARDANDO COMANDO | 52 | 0        
53 | dormindo | . | comidab | AGUARDANDO COMANDO | 53 | 0        
54 | SUSPENSO | 52 | comidab | ATUALIZAÇÃO | 54 | 0        
56 | EXECUTÁVEL | . | comidab | SELECIONE EM | 56 | 0        

Isso é esperado, a sessão 54 é bloqueada pelas alterações não confirmadas da sessão 52.

A consulta sys.dm_os_waiting_taskstambém mostra isso. A declaração:

select session_id, wait_type, resource_address, resource_description
from sys.dm_os_waiting_tasks
where blocking_session_id is not null;

retorna:

session_id | tipo_espera | endereço_recurso | descrição_recurso                                                            
-----------+-----------+--------------------+----- -------------------------------------------------- --------------------------
        54 | LCK_M_X | 0x000000002a35cd40 | keylock hobtid=72057594046054400 dbid=6 id=lock4ed1dd780 mode=X associadoObjectId=72057594046054400

Novamente, isso é esperado.

Meu problema é que não consigo descobrir como encontrar o nome real do objeto que a sessão 54 está esperando.

Eu encontrei várias consultas que estão se juntando sys.dm_tran_lockse sys.dm_os_waiting_tasksassim:

SELECT ....
FROM sys.dm_tran_locks AS l
  JOIN sys.dm_os_waiting_tasks AS wt ON wt.resource_address = l.lock_owner_address

Mas no meu cenário de teste acima, essa junção não retorna nada. Portanto, essa junção está errada ou dm_tran_locksnão contém as informações que estou procurando.

Então, o que estou procurando é uma consulta que retorne algo como:
" sessão 54 está aguardando um bloqueio na tabelafoo ".

Algumas informações de fundo:

O problema da vida real que estou tentando resolver é um pouco mais complicado, mas se resume à pergunta "em qual mesa a sessão 54 está esperando". O problema em questão envolve um procedimento armazenado grande que atualiza várias tabelas e um select de uma view que acessa algumas dessas tabelas. A selectinstrução é bloqueada mesmo que tenhamos o isolamento de instantâneo e o instantâneo confirmado de leitura habilitado. Descobrir por que o select está bloqueado (o que eu pensei que não seria possível se o isolamento de instantâneo estivesse habilitado) será o próximo passo.

Como primeiro passo, gostaria de saber o que essa sessão está esperando.

Estou usando a seguinte instrução para recuperar uma lista de gatilhos do banco de dados:

select tr.name
from sys.triggers tr
union all
select tr.name
from sys.server_triggers tr;

No entanto, na minha instalação local do SQL Server 2012 Express, isso falha com o erro:

Não é possível resolver o conflito de agrupamento entre "Latin1_General_CI_AS" e "Latin1_General_CI_AI" no operador UNION ALL que ocorre na coluna 1 da instrução SELECT

Posso "consertar" isso alterando a instrução para usar explicitamente um agrupamento diferente na segunda parte da união:

select tr.name
from sys.triggers tr
union all
select tr.name collate database_default as name
from sys.server_triggers tr;

No entanto, sinto que este é um hack feio e realmente não entendo por que há um conflito em primeiro lugar. Ambas as exibições finalmente recuperam o nome de sys.sysschobjs.namee, portanto, todos os valores devem ter o mesmo agrupamento.

Então minhas duas perguntas são:

1. por que há um conflito de agrupamento em primeiro lugar?
2. é seguro usar collate database_defaultapenas na segunda parte ou devo usá-lo melhor para ambas as consultas (desempenho não é um problema para isso).

Curiosamente, a mesma consulta não cria problemas ao usá-la em um SQL Server 2005 (edição padrão) com os mesmos gatilhos definidos.

Acabei de criar uma visão materializada no Oracle, mas percebi que usei o script errado, então queria descartar o MVIEW novamente.

O MVIEW foi criado com uma declaração como esta:

create materialized view foobar
  refresh start with trunc(sysdate) + 1/8  next sysdate + interval '8' hour
as
select ...
from ...;

A criação levou algum tempo.

Agora, depois de perceber que era o script errado, executei:

drop materialized view foobar;

Que estava funcionando por algum tempo também. Primeiro pensei que poderia ser devido a alguns bloqueios ou outras sessões bloqueando isso, mas não: quando perguntei v$session, vi que minha dropdeclaração realmente acionou uma atualização completa do mview:

NOME DE USUÁRIO | SID | Nº DE SÉRIE | PROGRAMA | ESTADO | SQL_ID | SQL_TEXT
----------+------+---------+---------------------- ----+--------+---------------+-------------------- -------------------------------------------------- ---
MEU_USER | 294 | 29131 | oracle@hostname (J002) | ATIVO | 6snjgrzbtynyc | INSERT /*+ BYPASS_RECURSIVE_CHECK */ INTO "MY_USER","FOOBAR" select .....

E, de fato, drop materialized viewfuncionou quase ao mesmo tempo que o create.

Então, minha pergunta: por que o Oracle acionaria uma atualização completa quando eu solto uma visualização materializada?

Ambiente: Oracle 11.2.0.3 64 bits

^{PS: Acho que o alias indexed-viewde materialized-viewestá errado. Embora ambos façam referência ao mesmo conceito subjacente, são nomes distintos usados ​​pela Microsoft e pela Oracle. Alguém interessado em visualizações materializadas no Oracle provavelmente não está interessado em visualizações indexadas no SQL Server. Mas não sei como esse alias pode ser removido}

Quando mostro a utilização da CPU no Enterprise Manager (na aba Desempenho), há uma grande discrepância entre o gráfico que mostra a utilização e a tabela que mostra os processos do sistema operacional e quanto consomem da CPU.

O gráfico mostra algo em torno de 15% de utilização (o que seria um núcleo a 100%, já que este é um servidor de 8 núcleos), mas a lista de processos mostra 100%. O que, por sua vez, significaria que o processo usa todos os núcleos, o que não é o caso. O ProcessExplorer realmente mostra apenas ~ 10% de uso da CPU para o processo oracle.exe.

Portanto, a pergunta é: o que a coluna "CPU Utilization (%)" na lista de processos reflete?

O gerente corporativo da Oracle tem uma métrica chamada "Tempo de logon do usuário" e mostrará um alerta se exceder um determinado limite.

Gostaria de recuperar os números armazenados para essas métricas diretamente usando uma consulta SQL.

No entanto, não consigo encontrar nenhuma exibição em que isso esteja armazenado. Posso encontrar "Logons por segundo", "Logons por Txn", "Contagem de logons atuais" na DBA_HIST_SYSMETRIC_SUMMARYexibição e "logons cumulativos" e "logons atuais" na DBA_HIST_SYSSTAT exibição.

A visualização DBA_HIST_METRIC_NAMEtambém não lista nenhuma métrica com esse nome.

Então, de onde o Enterprise Manager obtém essas informações?

Estou falando deste alerta:

Estou tentando alterar o nome do serviço de uma instalação do Oracle 11.2.0.3 em um servidor Windows 2003.

Durante a instalação, o nome do serviço foi definido com o domínio padrão, mas gostaríamos de nos livrar disso.

O que fiz até agora (e o que funcionou antes) para alterar o nome do serviço mydb.foo.barpara mydbapenas:

alter system set service_names = 'mydb' scope = both;
alter database rename global_name to mydb;

O que parece ter funcionado:

SQL> mostra o nome do parâmetro

NOME TIPO VALOR
------------------------------------ ----------- --- ---------------------------
db_name string mydb
db_unique_name string mydb
global_names boolean FALSE
instance_name string mydb
service_names string mydb
SQL>

^{(Removi algumas propriedades da saída acima que não são relevantes)}

Em seguida, use alter system registerpara registrar novamente com o ouvinte.

Isso não mostrou nenhum efeito, então reiniciei o banco de dados e o ouvinte, ainda sem sorte.

A situação atual é a seguinte:

select name from v$active_servicesretorna:

SERVICE_ID | NOME | NOME DA REDE       
-----------+-----------------+--------------------
1 | SYS$BACKGROUND |                    
2 | SYS$USERS |                    
3 | mydb | mydb           
5 | mydbXDB | mydbXDB        
6 | mydb.foo.bar | mydb.foo.bar

Então, por algum motivo, o antigo nome do serviço ainda está lá e em execução.

Ao tentar parar o serviço usando

SQL> exec dbms_service.stop_service('mydb.foo.bar');
Procedimento PL/SQL concluído com sucesso.

nenhum erro é relatado, mas ao tentar excluir o serviço, o Oracle não me deixa:

SQL> exec dbms_service.delete_service('mydb.foo.bar');
BEGIN dbms_service.delete_service('mydb.foo.bar'); FIM;

*
ERRO na linha 1:
ORA-44305: o serviço mydb.foo.bar está em execução
ORA-06512: em "SYS.DBMS_SYS_ERROR", linha 86
ORA-06512: em "SYS.DBMS_SERVICE", linha 454
ORA-06512: em "SYS.DBMS_SERVICE", linha 343
ORA-06512: na linha 1

Verifiquei que não tenho conexões abertas usando esse serviço:

select count(*)
FROM v$session
where service_name = 'mydb.foo.bar';

devolvido 0(zero)

Eu também recriei o serviço do Windows usando oradim, mas sem sucesso.

Em um momento eu corri

alter system set service_names = 'mydb,mydb.foo.bar' scope = both;

poderia ser essa a razão de eu ter os dois agora?

Mas depois de alterar service_names para apenas um único nome, o segundo deveria ter desaparecido, não deveria?

Se eu não conseguir fazer com que o segundo serviço desapareça, bastaria fazer a instância registrar com o listener usando o nome do serviço curto, ao invés do longo.

Tenho certeza de que estou perdendo algo bastante óbvio, mas não consigo descobrir o que é.

habilitamos o "READ_COMMITTED_SNAPSHOT" para alguns de nossos bancos de dados SQL Server 2005.

Agora, de tempos em tempos, vemos que nosso TempDB está enchendo o disco rígido e suspeitamos que o armazenamento de versão seja o culpado.

Monitoramos o uso do TempDB sys.dm_db_file_space_usagee, quando vemos que o armazenamento de versão está aumentando (conforme relatado por version_store_reserved_page_count), gostaríamos de identificar as transações que estão usando ativamente o armazenamento de versão.

Estou usando a seguinte declaração para encontrar transações que estão usando o armazenamento de versão:

SELECT db_name(spu.database_id) as database_name,
       at.transaction_begin_time as begin_time,
       case 
         when at.transaction_state in (0,1) then 'init'
         when at.transaction_state = 2 then 'active'
         when at.transaction_state = 3 then 'ended'
         when at.transaction_state = 4 then 'committing'
         when at.transaction_state = 6 then 'comitted'
         when at.transaction_state = 7 then 'rolling back'
         when at.transaction_state = 6 then 'rolled back'
         else 'other'
       end as transaction_state,
       ast.elapsed_time_seconds as elapsed_seconds,
       ses.program_name, 
       ses.row_count,
       (spu.user_objects_alloc_page_count * 8) AS user_objects_kb,
       (spu.user_objects_dealloc_page_count * 8) AS user_objects_deallocated_kb,
       (spu.internal_objects_alloc_page_count * 8) AS internal_objects_kb,
       (spu.internal_objects_dealloc_page_count * 8) AS internal_objects_deallocated_kb
FROM sys.dm_tran_active_snapshot_database_transactions ast
  JOIN sys.dm_tran_active_transactions at on at.transaction_id = ast.transaction_id
  JOIN sys.dm_exec_sessions ses ON ses.session_id = ast.session_id
  JOIN sys.dm_db_session_space_usage spu ON spu.session_id = ses.session_id
ORDER BY elapsed_time_seconds DESC
;

Mas isso não me ajuda a identificar quanto espaço cada transação está realmente usando no armazenamento de versão.

Existe uma maneira de obter as informações sobre o uso de espaço no armazenamento de versão por transação (ou melhor ainda: por instrução)?

Editar: A "duplicata potencial" ( Como identificar qual consulta está preenchendo o log de transações do tempdb? ) não leva em consideração o armazenamento de versão (apenas tabelas temporárias, variáveis ​​de tabela e espaço usado para operações de classificação e hash).

Na verdade, a solução aceita não mostrará nada para transações que usam apenas o armazenamento de versão (pelo menos não para mim)

Tenho experiência em Oracle/PostgreSQL e tenho dificuldade em lidar com os limites da implementação de trigger do SQL Server.

Desejo atualizar duas datetimecolunas diferentes se o valor de uma coluna diferente for alterado. Isso é para registrar duas alterações de status específicas da linha.

Agora o SQL Server não possui gatilhos de nível de linha nem before updategatilhos. Portanto, meu entendimento é que preciso ingressar em inserir e excluir para descobrir se e qual alteração de status ocorreu e, em seguida, executar uma atualização "regular" na tabela que está sendo atualizada.

Meu gatilho atualmente se parece com isso:

create trigger ord_status_history_trigger
  on jobs
AFTER UPDATE
AS
  IF ( UPDATE(order_status) )
  BEGIN
    update jobs
      set  transfercomplete = case
                                when o.order_status = 'initial' and n.order_status = 'sent' then current_timestamp
                                else n.transfercomplete
                              end,
           installcomplete = case
                               when o.order_status = 'delivered' n.order_status = 'installed' then current_timestamp
                               else n.installcomplete
                            end
      from inserted n
        join deleted o on o.jobid = n.jobid
        join jobs aj on aj.jobid = n.jobid;
  END

Minha dúvida é: essa trigger resulta efetivamente em duas atualizações na tabela?

A primeira sendo a atualização do acionador e a segunda sendo aquela executada pelo acionador?

Ou o SQL Server é inteligente o suficiente para mesclar isso em uma única atualização na tabela base (essencialmente da maneira como acontece com, por exemplo, um BEFORE UPDATEgatilho no PostgreSQL)

Eu crio um potencial gargalo de desempenho aqui?

Poderíamos definir esses carimbos de data/hora de dentro do aplicativo também, mas seria melhor se pudéssemos delegar isso ao banco de dados, para que possamos ter certeza de que isso nunca será esquecido.

Instalei o DB2 Express 10.1 em meu notebook com Windows 7 (64 bits). Agora, após a conclusão da instalação, não consigo me conectar ao banco de dados. Durante a instalação, especifiquei "C:\Daten\db\db2" como o diretório a ser usado para o DB2.

Ao tentar conectar, recebo o seguinte erro:

SQL1031N O diretório do banco de dados não pode ser localizado no sistema de arquivos indicado.

No entanto, o banco de dados parece estar lá:

db2 => connect to db2inst
SQL1031N  The database directory cannot be found on the indicated file system.
SQLSTATE=58031

db2 => list database directory

 System Database Directory

 Number of entries in the directory = 1

Database 1 entry:

 Database alias                       = DB2INST
 Database name                        = DB2INST
 Local database directory             = C:\Daten\db\db2\IBM\DB2\DB2INST
 Database release level               = f.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = -1
 Alternate server hostname            =
 Alternate server port number         =

Verifiquei se os privilégios do sistema de arquivos estão corretos para o diretório (o usuário que executa o serviço DB2 tem controle total sobre esse diretório e também o tornei o proprietário).

O conteúdo de C:\Daten\db\db2\se parece com isso:

\---IBM
    \---DB2
        \---DB2INST
            +---cfg
            +---cfgcache
            +---DB2
            | +---ctrl
            | +---hmonCache
            | | \---DB2
            | | \---0
            | | \---ossipcres
            | +---log
            | +---segurança
            | | \---auditdata
            | +---spmlog
            | | \---SPMLOGSD
            | +---SQLDBDIR
            | +---TMP
            | \---UIF
            +---DB2DAS00
            | +---cfg
            | +---despejar
            | +---log
            | +---metadados
            | \---tmp
            | +---dastmp
            | \---schedtmp
            +---db2dump
            +---função
            | \---não protegido
            \---licença

Eu então tentei re-catalogar o banco de dados:

db2 => banco de dados não catalogado db2inst
DB20000I O comando UNCATALOG DATABASE foi concluído com êxito.
DB21056W As mudanças no diretório podem não ser efetivas até que o cache do diretório seja
atualizado.
db2 => banco de dados do catálogo db2inst em "c:\Daten\db\db2\IBM\DB2\DB2INST\"
DB20000I O comando CATALOG DATABASE foi concluído com êxito.
DB21056W As mudanças no diretório podem não ser efetivas até que o cache do diretório seja
atualizado.

Mas isso também não ajudou.

Por algum motivo, parece que o DB2 não pode acessar o diretório (existente):

db2 => liste o diretório db em "c:\Daten\db\db2\IBM\DB2\DB2INST\"
SQL1031N O diretório do banco de dados não pode ser localizado no sistema de arquivos indicado.
SQLSTATE=58031
db2 => listar o diretório do banco de dados

Não tenho experiência com DB2 e da última vez que instalei o Express tudo correu bem, então estou um pouco perdido agora.

Não sou muito experiente com SQL Server, então talvez esteja faltando alguma coisa

A minha situação é a seguinte:

• A sessão 1 executa um CREATE TABLE (ou outras instruções CREATE) com autocommit desativado e o CREATE não está sendo confirmado.
• A sessão 2 executa uma sp_tableinstrução, mas trava enquanto a sessão 1 não está confirmando o DDL

O cenário em que isso acontece são os desenvolvedores trabalhando no banco de dados. Alguns deles navegando nas tabelas, alguns deles fazendo DDL. Se um usuário esquecer de confirmar o DDL, todas as outras sessões que desejam listar as tabelas serão bloqueadas. Observe que o sp_tablesé emitido, por exemplo, pelo cliente SQL (através da API do driver JDBC), portanto, não é algo que possa ser alterado.

O banco de dados com o qual estou trabalhando tem snapshot_isolation ativado e o nível de isolamento está definido como leitura confirmada ( SET ALLOW_SNAPSHOT_ISOLATION ONe SET READ_COMMITTED_SNAPSHOT ON)

Minha suposição era que essas configurações deveriam fazer com que o SQL Server se comportasse melhor em relação ao bloqueio em sessões simultâneas (por exemplo, como PostgreSQL e Oracle, onde SELECTs nunca são bloqueados por nenhum gravador) - mas aparentemente esse não é o caso.

Então, existe alguma maneira de tornar o SQL Server mais amigável em situações de leitura/gravação simultâneas em relação ao DDL? (além de enviar DDL apenas no modo de confirmação automática).

Hoje pensei em dar uma chance ao Firebird 3.0, mas por algum motivo não consigo instalá-lo - pelo menos não de uma maneira que eu possa conectar a partir de um aplicativo JDBC.

O que fiz foi seguir este artigo . Isso é o que aconteceu:

c:\etc\Firebird30>gsec -add sysdba -pass masterkey

c:\etc\Firebird30>iniciar firebird.exe -a -m

c:\etc\Firebird30>isql
Use CONNECT ou CREATE DATABASE para especificar um banco de dados
SQL> criar banco de dados "localhost:c:\temp\mydbfb3.fdb" usuário "sysdba" senha "masterkey";
Falha na instrução, SQLSTATE = 08006
Erro ao ler os dados da conexão.
SQL>

Agora, criar o banco de dados "localmente" funciona:

SQL> criar banco de dados "c:\temp\mydbfb3.fdb" usuário "sysdba" senha "masterkey";
SQL> confirmar;
SQL>

Mas, nesse caso, quando me conecto de um aplicativo JDBC (ainda tudo "localhost"), recebo a mensagem de erro (usando sysdba/masterkey para efetuar login)

Exceção GDS. 335544472. Seu nome de usuário e senha não estão definidos. Peça ao seu administrador de banco de dados para configurar um login Firebird.
Razão: Seu nome de usuário e senha não estão definidos. Peça ao seu administrador de banco de dados para configurar um login Firebird.

Verifiquei duas vezes (mais de uma vez) se o nome de usuário e a senha no aplicativo JDBC são sysdba/masterkey.

Na linha de comando, posso acessar o banco de dados recém-criado:

SQL> connect 'c:\temp\mydbfb3.fdb';
Banco de dados: 'c:\temp\mydbfb3.fdb'
SQL> criar tabela foo (inteiro da barra);
SQL> inserir em valores foo (1);
SQL> selecione * de foo;

         BAR
============
           1

SQL> confirmar;
SQL>

Tenho certeza de que estou perdendo algo óbvio, mas o quê?

temos uma tabela bastante pequena (~ 25k linhas) que está sendo fortemente gravada e a maioria das linhas desaparece rapidamente (é parte de um aplicativo de agendamento que armazena informações sobre os trabalhos nessa tabela).

É um aplicativo de terceiros que faz uma grande quantidade de pequenas transações que resultam em uma alta contenção nessa tabela.

Tudo isso está sendo executado em um cluster RAC de dois nós usando o Oracle 11gR1

Podemos ver nos relatórios do AWR que a maior parte do tempo é gasto aguardando a sincronização do cluster.

Gostaríamos de particionar (com hash) essa tabela para distribuir a contenção nos blocos que estão sendo modificados.

No entanto, a tabela também contém uma BLOBcoluna que é usada pelo aplicativo para armazenar o estado do trabalho. Também vemos um alto volume de leituras e gravações no segmento LOB dessa coluna.

Minha pergunta é: quando particionamos a tabela, existe uma maneira de criar vários segmentos de LOB também? Para que haja uma relação um-para-um entre partições de tabela (ou seja, segmentos) e segmentos LOB?

Não encontrei nada no manual, mas como a documentação de CREATE TABLE é muuuuito grande, não ficaria surpreso se tivesse esquecido alguma coisa.