All perguntas(dba)

Recentemente terminei de ler o Plan Caching no SQL Server 2008 e fiquei confuso. Parece que, além de liberar totalmente o cache do plano ou exigir explicitamente a recompilação de um procedimento armazenado, as recompilações de procedimentos armazenados do SQL Server 2008 em diante são feitas no nível da instrução, e não no nível do procedimento armazenado.

Portanto, além de liberar explicitamente o cache ou exigir recompilações (por exemplo WITH RECOMPILE), o que recompila um procedimento armazenado completo no SQL Server 2019 em vez de apenas recompilar instruções individuais?

Para dar um exemplo de onde estou confuso, considere o procedimento a seguir.

CREATE PROCEDURE FOO AS
BEGIN
   SELECT * INTO #temp1 FROM table1
   INSERT BAR1 SELECT * FROM #temp1
   INSERT BAR2 SELECT * FROM #temp1
END

Posso pensar em muitas coisas que poderiam causar SELECT * INTO #temp1 FROM table1a recompilação, mas seria estranho recompilar sem que as próximas linhas também recompilassem. Isso me faz pensar que deve haver algumas coisas no SQL Server que farão com que procedimentos armazenados inteiros sejam recompilados.

Recentemente, tomei conhecimento dos procedimentos armazenados temporários e fiquei chocado por nunca tê-los visto usados ​​antes em minha carreira. Fiquei muito decepcionado quando lembrei que esse CREATE PROCEDUREdeveria ser o primeiro extrato do lote, o que certamente limita seu uso. Esta ideia foi apoiada quando vi quão raramente eles são mencionados neste site . Eles nem têm etiqueta!

Quais são os casos de uso idiomáticos para procedimentos armazenados temporários? Como eles evitam as limitações impostas pela necessidade de ser a primeira instrução em seus lotes?

Tentando criar um painel único para todos os nossos servidores quanto ao estado e integridade do grupo de disponibilidade. Quero fazer isso escrevendo um aplicativo e chamando instruções t-sql para coletar dados de cada uma das tabelas/visualizações mestres do servidor e exibi-las como um painel combinado.

Estou usando as visualizações do sistema, mas estou enfrentando o seguinte problema:

A execução select * from sys.dm_hadr_database_replica_statesa partir da réplica Primária exibe os estados das réplicas Primária e Secundária de cada banco de dados, mas a execução a partir da réplica Secundária exibe apenas os resultados da réplica Secundária.

Por exemplo, quando executado no Primário, recebo:

TAPSLog     ONLINE  FULL    SRVR-01-HA  TAPSLog_LN      Secondary   SYNCHRONIZED    HEALTHY NULL    NULL
TAPSLog     ONLINE  FULL    SRVR-01     TAPSLog_LN      Primary     SYNCHRONIZED    HEALTHY ONLINE  NULL

E do Secundário:

TAPSLog     ONLINE  FULL    SRVR-01-HA  TAPSLog_LN      Secondary   SYNCHRONIZED    HEALTHY NULL    NULL

Alguém sabe se é possível ler o status de todas as réplicas de todas as réplicas e estou usando apenas as tabelas erradas?

Tenho um procedimento armazenado que insere algumas linhas em uma tabela. Às vezes parece falhar (não consigo encontrar os novos registros), embora eu saiba que as instruções foram executadas. O código que uso está abaixo. Depois de executá-lo, posso encontrar as linhas relevantes na tabela tbl_DebugLog, mas não na tabela tbl_WebSiteNotifications. Estou usando o SQL Server 15.0.2. Além disso, esta tabela faz parte de uma replicação de mesclagem. O que pode causar isso?

    insert into tbl_WebSiteNotifications(NotificationType, FileID, UserID, SubscriptionID, InsertionDate)
    select RequestType, FileID, UserID, SubscriptionID, DateRequested
        from #TempNotifications
        where UserID is not null


insert into tbl_DebugLog (LogDate, LogMessage, ServerName)
    select getdate(), 'FileID ' + format(FileID,'D') + N' for SubscriptionID ' + format (SubscriptionID,'D') + N' Inserted into tbl_WebSiteNotifications' + 
        ', NotificationType=' + format(RequestType,'D') + 
        ', UserID=' + format(UserID,'D') +
        ', InsertionDate=' + format(DateRequested,'dd-MM-yyyy'), 
        @@SERVERNAME
        from #TempNotifications
        where UserID is not null

Estou trabalhando em algo e encontrei esse SQL que não tenho certeza de como reescrever corretamente, ou seja, usando PHP PDO.

O SQL se parece com:

$sql = 'SELECT * FROM table WHERE column ' . isset($variable) ? . '=' . $variable : '>0'; 

Basicamente, o que a consulta está dizendo é: se $variableestiver definido (dentro do mundo PHP), use an =para a condição WHERE; se não estiver, use >0.

Posso limpar um pouco isso no PHP e fazer algo como:

$where = $variable ? 'column = ?' : column > ?'; // ternary operator to build the proper where condition
$sql = 'SELECT * FROM table WHERE $where';
$db->row($sql, [$variable ?? 0]); // bind parameters to the query, PDO way, and the operator will use the value of $variable if it is defined otherwise it will use 0 

e vai funcionar bem, eu acho. Agora, gostaria de saber se posso conseguir o mesmo usando SQL simples como uma condição dentro de WHERE igual a SELECT e, em caso afirmativo, é ideal? Ou programaticamente é melhor e mais rápido?

Eu tenho uma função lambda que recebe dados de usuários recém-inscritos de uma fila de mensagens e insere esses mesmos dados em dois bancos de dados diferentes.

Esses dois bancos de dados pertencem a dois microsserviços diferentes. Primeiro - serviço de usuários que usa RDS postgres e segundo - serviço de administração cujo banco de dados é basicamente uma única tabela DynamoDB.

Quero obter um comportamento "tudo ou nada" para inserções de dados nos dois bancos de dados - ou a inserção em ambos os bancos de dados é bem-sucedida ou as inserções não acontecem em nenhum deles.

• Como posso ter uma “transação atômica” para inserção nos dois bancos de dados, conseguindo um comportamento “tudo ou nada”?
• E se os dados forem inseridos na tabela DynamoDB do serviço administrativo, mas não forem inseridos na tabela postgres do serviço de usuários por algum motivo - como posso "reverter" a inserção no DyanamoDB?

Posso alcançar esse tipo de funcionalidade no nível do código, mas o código ficaria bastante confuso se digamos que eu tenha inserções "tudo ou nada" em 5 em vez de 2 bancos de dados diferentes.

Eu me pergunto se existe alguma maneira padrão de ter um comportamento semelhante ao de uma transação atômica quando se trata de interagir com diferentes bancos de dados.

Eu queria saber se é possível criar uma tabela que seja realmente rápida e temporária (basicamente uma que resida na memória RAM) no MS SQL Server 2005 ou posterior para fins de comunicação entre softwares? Todas as funcionalidades normais de bloqueio também funcionam com essas tabelas, se possível? Temos um software antigo que deseja receber mensagens através do banco de dados e atualmente está usando apenas uma tabela normal, embora realmente não precise preservar seu estado durante as reinicializações. Também gostaríamos de usar procedimentos TSQL armazenados nessa tabela.

Exporto dados como documentos do Office e sincronizo da seguinte forma:

cnosdb-imexport export --src <user>:<password>@<ip>:<port> --path ./backup

e executo o cmd da seguinte maneira:

./target/release/cnosdb-imexport export -s root:@127.0.0.1:8902 --path ./test

mas o registro:

# Input args: Cli { subcmd: Export(ExportArgs { src: "root:@127.0.0.1:8902", path: "./test", conn: None }) }
# Begin  export table(t001.db001.air)  [Now: 10:36:54]
# Export table(t001.db001.air) data: {"error_code":"010001","error_message":"Datafusion: IO error: No such file or directory (os error 2)"}

Eu verifico o diretório atual:

cnosdb-enterprise git:(main) ✗ ll | grep test
drwxr-xr-x   2 xxx  staff    0B 12 25 10:36 test

O diretório de teste existe, o que está acontecendo?

Por favor, ajude com a consulta. Os desenvolvedores vieram pedindo para melhorar o desempenho da consulta. Tentei usar CTEs em vez de junções laterais e EXISTS, testando índices de cobertura e filtragem adicional. Sem benefícios significativos de desempenho. Possíveis recomendações podem incluir:

1. Filtragem adicional
2. Maneiras de reescrever, posso ver buscas de heap lá, então executarei VACUUM em breve, então, exceto VACUUM, o que pode ser feito? Agradeço sua ajuda

https://explain.dalibo.com/plan/e6b0c5757962095a

Versão PG: PostgreSQL 14.7

A pergunta:

SELECT
    oh.order_header_id AS SfmId,
    oh.status AS Status,
    oh.case_type AS CaseType,
    oh.partner_id AS CompanyId,
    oh.date_created AS DateCreated,
    oh.update_date_utc AS DateUpdated,
    oh.contact_id AS DoctorId,
    scan_detail.due_date AS DueDate,
    lab_link.partner_id AS LabId,
    COALESCE(milling_site_link.partner_id, -1) AS MillingSiteId,
    COALESCE(int_site_link.partner_id, -1) AS InterpretationSiteId,
    oh.order_tags AS OrderTags,
    oh.patient_guid AS PatientGuid,
    oh.rx_id AS RxId,
    FALSE AS IsConventional,
    COALESCE(prev_wo.work_type, -1) AS PreviousBowId,
    -1 AS LastDetailsId,
    oh.last_work_order_id AS LastWorkOrderSfmId,
    wo.date_created AS LastWorkOrderDateCreated,
    wo.date_updated AS LastWorkOrderDateUpdated,
    oh.direct_to_lab_status AS IsDirectToLab,
    wo.resource_id AS LastResourceId,
    wo.resource_type AS LastResourceTypeId,
    oh.scan_info AS ScanInfo,
    oh.extended_info AS ExtendedInfo,
    oh.file_upload_report AS FileUploadReport,
    wo.status AS LastWorkOrderStatus,
    wo.work_type AS LastBowId,
    wo.order_detail_id AS LastDetailsSfmId,
    od.due_date AS LastDetailsDueDate,
    -1 AS LastWorkOrderId,
    wo.status AS LastWorkOrderStatus,
    oh.order_code AS OrderCode,
    od.date_created AS LastDetailsDateCreated
FROM
    tab1 cpl
    LEFT JOIN tab2 oh ON oh.order_header_id = cpl.order_header_id
    LEFT JOIN LATERAL (
        SELECT
            due_date
        FROM
            tab3 scan_detail
        WHERE
            scan_detail.order_header_id = oh.order_header_id
            AND EXISTS (
                SELECT
                    1
                FROM
                    tab4 ctdc2
                WHERE
                    ctdc2.detail_type = scan_detail.item
                    AND ctdc2.detail_category = 1
            )
        LIMIT 1
    ) AS scan_detail ON TRUE
    LEFT JOIN LATERAL (
        SELECT
            partner_id
        FROM
            tab1 lab_link
        WHERE
            lab_link.order_header_id = oh.order_header_id
            AND lab_link.partner_type = 300
        LIMIT 1
    ) AS lab_link ON TRUE
    LEFT JOIN LATERAL (
        SELECT
            partner_id
        FROM
            tab1 milling_site_link
        WHERE
            milling_site_link.order_header_id = oh.order_header_id
            AND milling_site_link.partner_type = 500
        LIMIT 1
    ) AS milling_site_link ON TRUE
    LEFT JOIN LATERAL (
        SELECT
            partner_id
        FROM
            tab1 int_site_link
        WHERE
            int_site_link.order_header_id = oh.order_header_id
            AND int_site_link.partner_type = 1100
        LIMIT 1
    ) AS int_site_link ON TRUE
    INNER JOIN tab5 wo ON oh.last_work_order_id = wo.work_order_id
    INNER JOIN tab3 od ON oh.order_header_id = od.order_header_id AND wo.order_detail_id = od.order_detail_id
    LEFT JOIN LATERAL (
        SELECT
            *
        FROM
            tab5 prev_wo
        WHERE
            prev_wo.work_order_id = wo.created_by_work_order
        LIMIT 1
    ) AS prev_wo ON TRUE
WHERE
    cpl.partner_id = 8133
    AND cpl.partner_type = ANY (VALUES (200), (500), (1900), (2700))
    AND wo.partner_id != 8133
    AND (
        EXISTS (
            SELECT
                1
            FROM
                tab2 oh2
                INNER JOIN tab3 od2 ON oh2.order_header_id = od2.order_header_id
                INNER JOIN tab5 wo2 ON wo2.order_detail_id = od2.order_detail_id
            WHERE
                oh2.order_header_id = oh.order_header_id
                AND wo2.work_order_id != oh2.last_work_order_id
                AND wo2.partner_id = 8133
                AND wo2.date_updated > (NOW() AT TIME ZONE 'UTC' + INTERVAL '-90 days')
                AND wo2.work_type <> 131
            LIMIT 1
        )
        OR (
            101 = ANY (VALUES (102))
            AND lab_link.partner_id = 8133
        )
    )
    AND (
        wo.work_type > 0
        OR (
            (
                wo.work_type = -1
                OR wo.status <> 1
            )
            AND wo.date_updated > (NOW() AT TIME ZONE 'UTC' + INTERVAL '-7 days')
        )
    )
LIMIT 1500;

Aqui está o plano de consulta com

(ANALISAR, BUFFERS, CONFIGURAÇÕES, FORMATAR TEXTO)

Também em explica.depesz.com https://explain.depesz.com/s/j73P#html

Limit  (cost=1771.30..248159.49 rows=1 width=1206) (actual time=47.173..548.541 rows=1500 loops=1)
  Buffers: shared hit=776970
  ->  Nested Loop Semi Join  (cost=1771.30..248159.49 rows=1 width=1206) (actual time=47.172..548.291 rows=1500 loops=1)
        Join Filter: (cpl.partner_type = "*VALUES*".column1)
        Rows Removed by Join Filter: 7412
        Buffers: shared hit=776970
        ->  Nested Loop Left Join  (cost=1771.30..248159.39 rows=1 width=1197) (actual time=46.221..543.890 rows=2978 loops=1)
              Buffers: shared hit=776970
              ->  Nested Loop Left Join  (cost=1770.74..248150.79 rows=1 width=1209) (actual time=46.206..518.898 rows=2978 loops=1)
                    Buffers: shared hit=762079
                    ->  Nested Loop Left Join  (cost=1770.31..248142.30 rows=1 width=1205) (actual time=46.194..506.935 rows=2978 loops=1)
                          Buffers: shared hit=752105
                          ->  Nested Loop Left Join  (cost=1769.88..248133.80 rows=1 width=1201) (actual time=46.179..492.135 rows=2978 loops=1)
                                Filter: ((SubPlan 1) OR ((hashed SubPlan 3) AND (lab_link.partner_id = 8133)))
                                Rows Removed by Filter: 2649
                                Buffers: shared hit=740174
                                ->  Nested Loop Left Join  (cost=1769.43..247893.45 rows=1 width=1197) (actual time=13.117..282.515 rows=5627 loops=1)
                                      Buffers: shared hit=596990
                                      ->  Gather  (cost=1769.00..247875.58 rows=1 width=1189) (actual time=13.069..214.075 rows=5627 loops=1)
                                            Workers Planned: 2
                                            Workers Launched: 2
                                            Buffers: shared hit=570677
                                            ->  Nested Loop  (cost=769.00..246875.48 rows=1 width=1189) (actual time=9.170..289.074 rows=1905 loops=3)
                                                  Join Filter: (oh.tab2_id = od.tab2_id)
                                                  Buffers: shared hit=570677
                                                  ->  Nested Loop  (cost=768.57..236676.59 rows=20408 width=1189) (actual time=9.146..276.915 rows=1905 loops=3)
                                                        Buffers: shared hit=547781
                                                        ->  Nested Loop  (cost=768.00..209231.31 rows=25330 width=1127) (actual time=9.017..152.212 rows=19269 loops=3)
                                                              Buffers: shared hit=258744
                                                              ->  Parallel Bitmap Heap Scan on tab1 cpl  (cost=767.57..66251.14 rows=25330 width=20) (actual time=8.989..41.637 rows=19269 loops=3)
                                                                    Recheck Cond: (partner_id = 8133)
                                                                    Heap Blocks: exact=5996
                                                                    Buffers: shared hit=27514
                                                                    ->  Bitmap Index Scan on ix_tab1_partner_id_partner_type  (cost=0.00..752.37 rows=60792 width=0) (actual time=7.558..7.558 rows=60795 loops=1)
                                                                          Index Cond: (partner_id = 8133)
                                                                          Buffers: shared hit=83
                                                              ->  Index Scan using "PK_tab2" on tab2 oh  (cost=0.43..5.64 rows=1 width=1107) (actual time=0.005..0.005 rows=1 loops=57807)
                                                                    Index Cond: (tab2_id = cpl.tab2_id)
                                                                    Buffers: shared hit=231230
                                                        ->  Index Scan using "PK_tab5" on tab5 wo  (cost=0.56..1.08 rows=1 width=78) (actual time=0.006..0.006 rows=0 loops=57807)
                                                              Index Cond: (tab5_id = oh.last_tab5_id)
                                                              Filter: ((partner_id <> 8133) AND ((work_type > 0) OR (((work_type = '-1'::integer) OR (status <> 1)) AND (date_updated > ((now() AT TIME ZONE 'UTC'::text) + '-7 days'::interval)))))
                                                              Rows Removed by Filter: 1
                                                              Buffers: shared hit=289037
                                                  ->  Index Scan using "PK_tab3" on tab3 od  (cost=0.43..0.49 rows=1 width=48) (actual time=0.005..0.005 rows=1 loops=5715)
                                                        Index Cond: (tab3_id = wo.tab3_id)
                                                        Buffers: shared hit=22879
                                      ->  Limit  (cost=0.43..17.84 rows=1 width=8) (actual time=0.011..0.011 rows=1 loops=5627)
                                            Buffers: shared hit=26313
                                            ->  Nested Loop Semi Join  (cost=0.43..17.84 rows=1 width=8) (actual time=0.011..0.011 rows=1 loops=5627)
                                                  Join Filter: (scan_detail.item = ctdc2.detail_type)
                                                  Rows Removed by Join Filter: 19
                                                  Buffers: shared hit=26313
                                                  ->  Index Scan using "IX_tab3_tab2_id" on tab3 scan_detail  (cost=0.43..16.48 rows=3 width=12) (actual time=0.005..0.006 rows=2 loops=5627)
                                                        Index Cond: (tab2_id = oh.tab2_id)
                                                        Buffers: shared hit=25878
                                                  ->  Materialize  (cost=0.00..1.32 rows=1 width=4) (actual time=0.000..0.001 rows=9 loops=12647)
                                                        Buffers: shared hit=1
                                                        ->  Seq Scan on tab4 ctdc2  (cost=0.00..1.31 rows=1 width=4) (actual time=0.006..0.010 rows=14 loops=1)
                                                              Filter: (detail_category = 1)
                                                              Rows Removed by Filter: 11
                                                              Buffers: shared hit=1
                                ->  Limit  (cost=0.43..8.47 rows=1 width=4) (actual time=0.007..0.007 rows=1 loops=5627)
                                      Buffers: shared hit=22214
                                      ->  Index Only Scan using ix_tab2_id_partner_id_partner_type on tab1 lab_link  (cost=0.43..8.47 rows=1 width=4) (actual time=0.006..0.006 rows=1 loops=5627)
                                            Index Cond: ((tab2_id = oh.tab2_id) AND (partner_type = 300))
                                            Heap Fetches: 5199
                                            Buffers: shared hit=22214
                                SubPlan 1
                                  ->  Nested Loop  (cost=1.30..231.85 rows=1 width=0) (actual time=0.030..0.030 rows=1 loops=5627)
                                        Join Filter: (wo2.tab5_id <> oh2.last_tab5_id)
                                        Buffers: shared hit=120970
                                        ->  Nested Loop  (cost=0.87..223.38 rows=1 width=32) (actual time=0.027..0.027 rows=1 loops=5627)
                                              Buffers: shared hit=109058
                                              ->  Index Scan using "IX_tab3_tab2_id" on tab3 od2  (cost=0.43..16.48 rows=3 width=32) (actual time=0.003..0.004 rows=3 loops=5627)
                                                    Index Cond: (tab2_id = oh.tab2_id)
                                                    Buffers: shared hit=28948
                                              ->  Index Scan using "IX_tab5_tab3_id" on tab5 wo2  (cost=0.44..68.96 rows=1 width=32) (actual time=0.006..0.006 rows=0 loops=18155)
                                                    Index Cond: (tab3_id = od2.tab3_id)
                                                    Filter: ((work_type <> 131) AND (partner_id = 8133) AND (date_updated > ((now() AT TIME ZONE 'UTC'::text) + '-90 days'::interval)))
                                                    Rows Removed by Filter: 2
                                                    Buffers: shared hit=79660
                                        ->  Index Scan using "PK_tab2" on tab2 oh2  (cost=0.43..8.45 rows=1 width=32) (actual time=0.005..0.005 rows=1 loops=2978)
                                              Index Cond: (tab2_id = oh.tab2_id)
                                              Buffers: shared hit=11912
                                SubPlan 3
                                  ->  Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.001..0.001 rows=1 loops=1)
                          ->  Limit  (cost=0.43..8.47 rows=1 width=4) (actual time=0.004..0.004 rows=1 loops=2978)
                                Buffers: shared hit=11931
                                ->  Index Only Scan using ix_tab2_id_partner_id_partner_type on tab1 milling_site_link  (cost=0.43..8.47 rows=1 width=4) (actual time=0.003..0.003 rows=1 loops=2978)
                                      Index Cond: ((tab2_id = oh.tab2_id) AND (partner_type = 500))
                                      Heap Fetches: 2993
                                      Buffers: shared hit=11931
                    ->  Limit  (cost=0.43..8.47 rows=1 width=4) (actual time=0.003..0.003 rows=0 loops=2978)
                          Buffers: shared hit=9974
                          ->  Index Only Scan using ix_tab2_id_partner_id_partner_type on tab1 int_site_link  (cost=0.43..8.47 rows=1 width=4) (actual time=0.003..0.003 rows=0 loops=2978)
                                Index Cond: ((tab2_id = oh.tab2_id) AND (partner_type = 1100))
                                Heap Fetches: 1056
                                Buffers: shared hit=9974
              ->  Limit  (cost=0.56..8.58 rows=1 width=134) (actual time=0.008..0.008 rows=1 loops=2978)
                    Buffers: shared hit=14891
                    ->  Index Scan using "PK_tab5" on tab5 prev_wo  (cost=0.56..8.58 rows=1 width=134) (actual time=0.007..0.007 rows=1 loops=2978)
                          Index Cond: (tab5_id = wo.created_by_tab5)
                          Buffers: shared hit=14890
        ->  Values Scan on "*VALUES*"  (cost=0.00..0.05 rows=4 width=4) (actual time=0.000..0.001 rows=3 loops=2978)
Settings: effective_cache_size = '88445488kB', maintenance_io_concurrency = '1'
Planning:
  Buffers: shared hit=5660
Planning Time: 5.158 ms
Execution Time: 549.025 ms

Ambiente Atual:

• Banco de dados de produção 12cR1 RAC -> digamos PROD

• 12cR1 Standby físico de instância única (Active Data Guard) -> Digamos DR1

Ambiente Planejado:

• Banco de dados de produção 12cR1 RAC -> PROD (do ambiente atual)

• 12cR1 Standby físico de instância única (Active Data Guard) -> DR1 (do ambiente atual)

• 12cR1 RAC Physical Standby -> Digamos DR2 (Novo ambiente)

• 12cR1 Standby físico de instância única -> Digamos DR3 (standby em cascata para DR2) (Novo ambiente)

Nota importante: o data guard broker não será usado. O processo será feito manualmente.

Cenário:

Queremos mudar para uma nova máquina física.

As instalações da máquina física e do sistema operacional (OEL 8.7) foram concluídas. (Novo ambiente)

As instalações do software de grade Oracle 19c e do software de banco de dados Oracle 12cR1 foram concluídas. (Novo ambiente)

O objetivo aqui é migrar para uma nova máquina física e migrar para uma versão mais recente do sistema operacional. Após a mudança para o novo ambiente, será planejada a atualização do 12cR1 para o 19c.

Poucos dias antes da migração, a instalação do data guard no novo ambiente será concluída. (Nomeado DR2)

Ao mesmo tempo, a instalação do data guard DR3 em cascata com o DR2 será concluída alguns dias antes da migração. (DR3)

Assim, no momento da migração, o PROD terá 2 guardas de dados diferentes (DR1 e DR2). Ao mesmo tempo, o DR3 está em cascata com o DR2.

Nosso objetivo ao fazer isso é concluir a migração com o mínimo de tempo de inatividade. Após a mudança de PROD para DR2, converteremos o DR3 de standby em cascata para standby físico (proteção de dados ativa).

Questões:

Eu tenho 2 perguntas diferentes.

1-) O cenário é possível? Embora existam dois protetores de dados diferentes (DR1 e DR2) pertencentes ao PROD, como posso determinar com comandos se a alternância será executada especificamente para o DR2 (sem corromper o DR1)? Na verdade, o DR1 não importa durante a migração ou devo remover o DR1 da configuração do data guard antes da transição? (excluindo DR1 de parâmetros como dg_config, fal_server, fal_client, log_archive_dest etc.)

2-) Existe alguma ação que precisa ser tomada no DR3 antes de realizar a mudança para DR2? Porque funcionará em standby em cascata até o momento da transição. Ou devo remover a configuração de espera em cascata do DR3 antes de realizar a mudança de PROD para DR2 e configurá-la como espera física para o novo PROD (antigo DR2) após a mudança? Após a transição, o DR2 se tornará o novo PROD e o DR3 se tornará o novo DR2 (proteção de dados ativa)?