Jóia ? Então, eu mesmo graças a todos os deuses da TI nunca tive que fazer
isso, mas colegas que tiveram que o fazer me disseram que os principais efeitos
colaterais foram queda de performance e aumento da dificuldade de
administração, AMBAS causadas pelas features/recursos do banco que são LIMADAS
na Standard Edition... De performance, as principais que vc perde são os
recursos TODOS para DW (como STAR TRANSFORMATION), o PARTICIONAMENTO,
PARALELISMO, IOTs (Index-Organized Tables), BITMAP Indexes/Bitmap JOINs,
rewrite de views materializadas, Query Rewrite Cache/Cache de Resultados, e de
facilidade/conveniência administrativa vc perde o DATAGUARD, as reorganizações
ONLINE (de índices, de segmento, de IOTs, etc), perde diversas opções de
FLASHBACK, perde a segurança de poder fazer um BLOCK RECOVER via RMAN em caso
de corrupção/lost block, perde no RMAN algumas opções de compactação e de fast
incremental backup, perde algumas opções de Auditoria e Segurança de acesso aos
dadoshttp://www.oracle.com/technetwork/community/database-11g-product-family-technic-133664.pdf
tem a lista completa pro 11g... Sendo assim, se vc pensa em fazer esse tipo
de downgrade, fique Ciente dessas coisas que vc perde e VERIFIQUE se vc as está
usando ou não : se estiver, vc ** vai ** ter que reservar algum tempo pra vc
poder desenvolver alguma rotina sua, algum procedimento que substitua as
facilidades que vc perderá (sabendo que algumas coisas vc não conseguirá
substituir completamente), E com isso desenvolvido vc vai ter que implementar e
testar para poder mensurar o quanto vc perde no tocante à
performance/facilidade administrativa...
Sobre Paralelismo é basicamente vc consultar o Plano de Execução real (não o
estimado via EXPLAIN PLAN, mas o real que fica nas views derivadas da V$SQL) e
ver se usou algum step paralelo ou não :
http://www.oracle.com/technetwork/articles/database-performance/geist-parallel-execution-1-1872400.html,
http://oracledoug.com/px2.html,
http://www.oracle.com/technetwork/articles/datawarehouse/twp-parallel-execution-fundamentals-133639.pdf
tem boa introduções, e
http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-explain-the-explain-plan-052011-393674.pdf
e https://blogs.oracle.com/optimizer/entry/how_do_i_know_if falam sobre
obtenção e análise de planos de execução, vc sabe que está sendo usado Parallel
SQL se vc ver operações PX-qquercoisa... Para vc ver o Paralelismo em ação no
momento em que o SQL está sendo executado, além de consultar a V$SESSION_LONGPS
WHERE TIME_REMAINING 0 vc pode também executar o script abaixo :
accept sid_list DEFAULT QC_SID prompt Lista de QC SIDs (opcional):
accept slave_sids DEFAULT SIDprompt Lista de Slaves (opcional):
select * from (
select
decode(px.qcinst_id,NULL,username,
' - '||lower(substr(s.program,length(s.program)-4,4) ) ) Username,
decode(px.qcinst_id,NULL, 'QC', '(Slave)') QC/Slave ,
to_char( px.server_set) Slave Set,
to_char(s.sid) SID,
decode(px.qcinst_id, NULL ,to_char(s.sid) ,px.qcsid) QC_SID,
px.req_degree Requested DOP,
px.degree Actual DOP
from
v$px_session px,
v$session s
where
px.sid=s.sid (+)
and
px.serial#=s.serial#
order by 5 , 1 desc
)
where QC_SID in (SID_LIST)
and (SIDin (slave_sids) OR QC_SID=SID)
/
[]s
Chiappa
IMPORTANTE : em minha Opinião quando falamos de Paralelismo é ** crucial ** vc
entender o conceito , que é : com ele vc terá MÚLTIPLAS sessões fazendo
múltiplos I/Os em um segmento de dados ou índice GRANDE, que precisa ser lido
na íntegra ou quase), okdoc ? Então isso deixa claro que SE vc não tem a
capacidade de CPU, memória e/ou I/O extras e SEM USO NO MOMENTO para atender as
múltiplas sessões, OU SE quase todos os seus SQLs são lookups por chave em
índice , o Paralelismo NÂO vai ser eficiente, por mais netsed loops que vc
faça...
