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 dados....http://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 SID prompt "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 (SID in (&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...
