Normas de Criao de Pacotes Oracle

ST-DBA_ORACLE
PT- Sistemas de Informao

Maio 2011

Error! name.

Unknown

document

property

Normas de Criao de Pacotes Oracle

Normas BD

Verso: Autor: Data:

V.6 ST/ABD 2007-12-19

Direc Projecto

o/Departamento

ou

ST/ABD

Documento

Normas de Cria o de Pacotes Oracle

Verso

Elaborado

Data

Verificao Nome Assinatura Data

2005-08-31

Aprovao Nome
HB/LR

Assinatura

Data
2005-10-03

v.1

ST/ABD

2005-08- HB/LR/DBA 31

v.2

ST/ABD

2005-10- HB/LR/DBA 03

2005-10-03

HB/LR

2005-10-03

v.3

ST/ABD

2006-02- HB/LR/DBA 26

2006-02-26

HB/LR

2006-02-26

v.4

ST/ABD

2007-09- HB/LR/DBA 07

2007-07-19

HB/LR

2007-09-07

v.5

ST/ABD

2007-10- HB/LR/DBA 22

2007-10-26

HB/LR

2007-10-30

v.6

ST/ABD

2007-12- HB/LR/DBA 19

2007-12-19

HB/LR

2007-12-20

Lista de Distribuio
Eq.Desenv*, ST*, CO*

Histrico do Documento
Verso
v.6 v.5 v.4

Data
2007-12-19 2007-10-26 2007-07-19

Elaborado/Verificado/Aprovado
ST/ABD ST/ABD ST/ABD

Descrio de alteraes
Clarificao de conceito DML ( Data Manipulation Language ) Incluso de detalhe de norma para instruo de commit . Incluso de normas especificas para a criao de constraints , uso de verses, uso do commit, uso do campo Notas de Instalao do plano de Instalao. Ajuste de normas de pacotes DML e DDL, parmetros para ficheiros com dump.

v.3

2006-02-06

ST/ABD

Incluso de normas especificas para a criao do plano de Instala o para pacotes de Data Repair; Alteraes resultantes da apresentao do documento e formao dada s equipas; Documento Base

v.2

2005-10-03

ST/ABD*

v.1

2005-08-31

ST/ABD*

ndice
1 Introduo 1.1 Organizao 1.2 Abreviaturas Utilizadas 1.3 Objectivo 1.4 mbito 1.5 Alterao s Normas Propostas 2 Normas de Desenvolvimento/Promoo de Pacotes BD/SQL 2.1 Regras Gerais 2.2 Regras DML/DDL 2.3 Definio do Plano de Instalao 3 Construo de Pacotes Harvest 3.1 Plano de Instalao pacotes .BD (Base de Dados) 3.2 Notas de Impacto de pacotes .MD (Manipulao de Dados) 3.3 Criao dos Scripts 3.4 Plano de Rejeio 4 Anexo - CheckList Criao de pacotes Oracle 6 6 6 7 7 7 9 9 12 13 14 14 15 16 19 20

Introduo
1.1 Organizao

Este documento encontra-se dividido em 3 captulos, procurando desta forma tornar mais fcil e imediata a sua leitura e compreenso: O Primeiro captulo (o actual) faz uma introduo a este documento, onde descrito o seu enquadramento e objectivos; Os Segundo Captulo contm as Normas de Desenvolvimento e Promoo de Pacotes de BD/SQL definidas para cumprir os objectivos deste documento; Os Terceiro Captulo contm as regras para a construo de Pacotes Harvest que so utilizadas para auxiliar as normas especficas do Segundo Captulo.

1.2 Abreviaturas Utilizadas

ST/ABD DDL DML DCL SQL Suporte Tcnico / Administrao de Bases de Dados Data Definition Language Data Manipulation Language Data Control Language Structured Query Language

1.3 Objectivo
Este documento tem como objectivo identificar e normalizar a informao necessria para a anlise, e desenvolvimento de objectos em bases de dados Oracle no mbito da promoo de SW pela utilizao do Gestor de Verses Harvest.

A normalizao um processo decisivo para alcanar a qualidade nos sistemas aplicacionais, tendo em conta a existncia de mltiplas equipas distribudas por diversos ambientes e com responsabilidades bem definidas.

1.4 mbito
Normas de construo de pacotes de objectos scripts Oracle DDL e DML. Padronizao e Sistematizao do Processo de Desenvolvimento de scripts de SQL, quer sejam DDL e/ou DML, enquadrando o mesmo com o Gestor de Verses.

Algumas reflexes:
Quais as causas para gerar um impacto Negativo ou Positivo num sistema aplicacional de Bases de Dados? Um bom levantamento de dados, adequada definio de requisitos e regras de negcios? Uma adequada identificao dos objectos a modelar? No propagao de erros para fases posteriores do projecto? O que pode afectar a correc ta definio de um DDL/DML?

Prazos escassos? Insuficiente formao das equipas? Os requisitos esto correctamente identificados? Falta de mtodos adequados?

possvel? Padronizar e sistematizar o desenvolvimento do modelo conceptual? Utilizar a prpria lngua falada para identificar entidades e relacionamentos? possvel sistematizar a descoberta das cardinalidades?

1.5 Alterao s Normas Propostas

A equipa ST/ABD responsvel por definir e promover as normas, descritas neste documento, entre todas as equipas envolvidas na promoo de pacotes de BD. A equipa ST/ABD ir controlar/divulgar novas verses deste documento e consequentes normas.

As alteraes destas normas iro evoluir seguindo as etapas: Os pedidos de alteraes (Requests) podero ser submetidos, via Remedy Service Request por outras equipas para a equipa ST/ABD; As alteraes podero ser submetidos internamente na equipa ST/ABD;

A equipa ST/ABD analisa e rev as alteraes propostas, aceitando -as ou rejeitando-as. No caso de serem rejeitadas, a equipa ST/ABD informar a entidade requerente sobre as razes da rejeio, actualizando o Remedy com esta informao; No caso de a alterao ser aceite, o documento de normas ser alterado e disponibilizado a todas as equipas.

Normas de Desenvolvimento/Promoo de Pacotes BD/SQL

2.1

Regras Gerais

Utilizao do Gestor de Verses Harvest para a promoo de pacotes

As equipas de Desenvolvimento, Testes, Gesto Operacional e DBAs, devero utilizar o Gestor de Verses Harvest para a promoo de alteraes s BDs envolvidas em cada projecto, e definidas nos ciclos de vida existentes. As equipas mencionadas devero ter um conhecimento de quais as regras implementadas para o Gestor de Verses Harvest, como por exemplo a identificao e objectivo de cada tipo de pacote, ciclos de vida 1 e equipas/responsabilidades definidas, sendo estas regras definidas pela equipa GFC .

Utilizao obrigatria do SQLPLUS para a validao da sintaxe e resultados no ambiente de Desenvolvimento

Os pacotes devero ser testados ao nvel da sintaxe no ambiente de Desenvolvimento, recorrendo obrigatoriamente ao SQLPLUS. A utilizao de qualquer outra ferramenta para execuo dos scripts, anteriormente ao check-in, como por exemplo TOAD/SQLNavigator poder levar a resultados distintos, ou mesmo dissimular possveis erros.

Realizao de Testes Unitrios no ambiente de Desenvolvimento

Os pacotes devero ser criados no ambiente de Desenvolvimento, e aps execuo, o resultado dever ser analisado com base nos requisitos funcionais propostos inicialmente. A equipa de desenvolvimento dever criar condies de teste para a execuo e confirmao do resultado com base numa amostra ou mesmo com a totalidade dos dados.

Utilizao do ambiente de Testes/Qualidade para os testes de sintaxe e Testes Integrados

Os pacotes devero ser promovidos para o ambiente de Testes (ou outro com funes de Teste/Qualidade) de forma a ser validada quer a sintaxe quer o resultado da execuo. Mesmo que no seja possvel obter resultados nas aces de DDL/DML, o pacote dever ser executado de forma a garantir uma correcta actualizao de objectos, bem como da validao da sintaxe. No caso de serem identificadas impossibilidades/constrangimentos na promoo e instalao de pacotes para o ambiente de Testes, estas razes devero ser reportadas no plano de instalao. As equipas de Desenvolvimento devero ser responsveis por realizar testes unitrios no ambiente de desenvolvimento, garantindo a eliminao de problemas/erros de sintaxe.

Promoo/Despromoo de um pacote BD
Um pacote de BD promovido para o estado seguinte aquando da anlise e enquadramento do mesmo, execuo e confirmao do correcto resultado tendo como base os logs e/ou outra anlise que seja identificada no plano de instalao;
1

Documentos Normas Harvest; Normalizao de Aplicaes Integradas em Ferramentas de GC; Modelos de Ciclo de Vida

A despromoo utilizada quando existem problemas na instalao do pacote, seja detectada insuficiente documentao sobre a instalao e resultados esperados ou mesmo quando o pacote no se enquadra nas normas aqui apresentadas.

Criao de Pacotes Harvest

A criao de pacotes Harvest dever ser uma actividade da responsabilidade das Equipas de Desenvolvimento e/ou equipas de Gesto e Suporte (ST/GS*, quando devidamente autorizado pelo Gestor de Verses), segundo as regras definidas e documentadas pela rea de Gesto de Ferramentas e Configuraes. As equipas de Desenvolvimento e/ou equipas de Gesto e Suporte so responsveis pela divul ao, para os g novos elementos das equipas, das normas de criao e promoo de pacotes Harvest. A equipa DBA dever participar com as equipas de desenvolvimento, com antecedncia, na anlise/optimizao de SQL e PLSQL e/ou fornecer sugestes de melhores prticas.

Timing para a Promoo/Instalao de Pacotes BD Ambientes No-Produtivos

A promoo/instalao de pacotes BD em ambientes no produtivos dever decorrer em horrio normal de trabalho, sendo que, em situaes excepcionais de necessidade de instala o de pacotes fora do horrio normal de trabalho (09:00 as 20:00), ou dos calendrios pr-definidos, ter de ocorrer uma validao prvia e atempada com o responsvel da rea ST/ABD; O Gestor de Verses est parametrizado de forma a enviar alertas (e-mails) automaticamente aquando da mudana de estado de cada um dos pacotes. Considera-se que no necessrio o envio de e-mails adicionais a informar a disponibilizao ou mesmo a informar a instalao de pacotes BD. A confirmao sobre a disponibilizao e/ou instalao dever ser validada unicamente atravs do acesso ao Harvest. A instalao dos pacotes ir depender unicamente da anlise do plano de instalao, devendo ser evitados ou mesmo eliminados e -mails e/ou contactos telefnicos, com excepo de situaes urgentes ou mesmo criticas para os SLAs acordados. Os scripts disponibilizados para instalao devero s conter instrues SQL vlidas. No sero aceites scripts com descritivos/notas de aces a serem executadas, sendo os pacotes associados rejeitados para o estado anterior.

Ambientes Produtivos
A promoo/instalao de pacotes BD em ambientes produtivos dever decorrer nos timings previamente planeados com o cliente e equipas PTSI, nos horrios pr -estabelecidos. Em situaes de necessidade de instalao de pacotes fora dos calendrios pr -definidos, ter de ocorrer uma validao prvia e atempada com o responsvel da rea ST/ABD. De forma a enquadrar a promoo de pacotes BD nos processos de Produo, a equipa de Gesto e Suporte (ST/GS*) dever disponibilizar informao sobre o horrio previsto para a instalao dos mesmos. Os scripts disponibilizados para instalao devero s conter instrues SQL vlidas. No sero aceites scripts com descritivos/notas de aces a serem executadas, sendo os pacotes associados rejeitados para o estado anterior.

Pacotes DML (Data Manipulation Language)

[Alterao Dez/2007] Os pacotes de actualizao de dados (DMLs), onde tambm se incluem os Data Repairs, devero ser criados/identificados como do tipo Manipulao de Dados (MD). Estes pacotes devero seguir o ciclo de vida definido anteriormente pela GFC, e executados em Background de forma a minimizar os riscos associados a perdas de ligao entre Harvest e servidor aplicacional2.

Pacotes DDL (Data Definition Language)

Os pacotes com scripts DDL devero ser identificados como pacotes BD. Estes pacotes podero conter scripts DML e DDL. Cada Script DDL dever conter apenas uma nica instruo. Os scripts DML podem conter uma ou mais instrues Os scripts DML devero conter a instruo de COMMIT apenas no final do mesmo Os scripts DDL NO devero conter a instruo de COMMIT ao final do mesmo. Comandos DDL possuem Commit implcito. No caso de ser necessrio a realizao de aces de import a determinados objectos, os procedimentos devero ser criados num pacote de BD. Nos scripts correspondentes s instrues de Import dever ser includo como parmetro os schemas de origem e destino (fromuser = <schema origem> touser <schema destino>)

Anlise/Instalao/Rejeio de pacotes BD
Um pacote poder conter um ou mais scripts. No caso de o mesmo falhar ao ser instalado/executado, este ser rejeitado para o estado anterior. Sempre que um script tiver de ser corrigido, dever ser criada uma nova verso do script (nunca reescrever a verso original), mantendo o nome do script, garantindo-se desta forma o registo do histrico de verses no Gestor de Configuraes. Aps a correco do pacote pelas equipas de Desenvolvimento, o respectivo plano de instalao dever ser revisto, em conformidade com as alteraes efectuadas; No decurso da anlise dos pacotes/scripts, a identificao de problemas/erros nos pacotes BD pressupem a rejeio dos mesmos; As notas de rejeio sero adicionadas ao form do pacote, pelos DBAs, numeradas e por ordem decrescente, indicando data e hora. Cabe s equipas responsveis pela criao inicial do pacote, a anlise das notas de rejeio, de modo a proceder s correces.

Documentos Normas Harvest; Normalizao de Aplicaes Integradas em Ferramentas de GC; Modelos de Ciclo de Vida

Pacotes vs Owner de Objectos de BD

Um pacote s dever, obrigatoriamente, conter scripts para um e um nico User. Devero ser criados diferentes pacotes consoante a existncia de diferentes USERS/BD.

Backup Aplicacional (export tabelas)

Caso seja necessrio a realizao de um backup aplicacional a determinadas tabelas, o pedido dever ser solicitado por ticket remedy ou e-mail, antes da promoo do pacote.

DataBase Links
A utilizao de DataBase links entre Bases de Dados deve ser avaliada de acordo com os requisitos de integrao com outras BDs, devendo ser evitada. A criao de um DataBase Link dever ter sempre a prvia autorizao da equipa de Gesto e Suporte responsvel pela aplicao de onde a informao vai ser extrada/actualizada (antes mesmo da criao de pacote). O pedido dever ser feito por ticket remedy ou email. Devero ser fornecidas as seguintes informaes: BD origem, user origem; Password user origem; BD destino; User destino; Password user destino.

2.2

Regras DML/DDL

Gerais
Os ndices devem ser criados antes de serem adicionados as PK (Primary Key) e FK (Foreign Key) das tabelas As PK e FK devero ser criados com a utilizao de instrues de Alter Table Add Constraint. Optar pela criao de sinnimos pblicos. No devem ser criados sinnimos com dblinks. Se efectivamente requerido dever ser criado um objecto que faa uso do DB Link e em seguida criado o sinnimo sobre o objecto. Optar pelo uso de Roles com password associada. Os scripts de DML devero conter obrigatoriamente a instruo de COMMIT no final do mesmo, mas apenas no final. Os scripts de DML no devero conter instrues de DDL e/ou DCL. Os scripts DDL NO devero conter a instruo de COMMIT ao final do mesmo. Comandos DDL possuem Commit implcito.

2.3

Definio do Plano de Instalao

O plano de Instalao dever estar correctamente preenchido e com informao clara e concisa. S assim se poder realizar uma correcta promoo/instalao. O no preenchimento da informao abaixo solicitada invalida a instalao do pacote, sendo este rejeitado.

Construo de Pacotes Harvest

Plano de Instalao pacotes .BD (Base de Dados)

O form Harvest - Plano de Instalao (PI) dever conter obrigatoriamente, de forma explcita os seguintes items:

User que ser instalado o pacote;

Identificar o user no Plano de Instalao Ex: IST qtibrp, PRD etibrp QA ysinglrp, PRD esinglrp

Base de Dados

Identificar a Base de Dados (instncia) no Plano de Instalao Ex: BD: IST QTIB1, PRD ETIB1 BD: QA Y25, PRD E45

Dependncia/Precedncia entre pacotes;

Informar no campo Pacotes Dependentes as dependncias do pacote, caso existam Identificar por ambiente (BD) os parmetros de entrada dos scripts na linha anterior ao nome de cada um dos scripts. Ex: Criao de sinnimos: BD : QGNV1 <parametro1> = <valor_parametro1> <parametro2> = <valor_parametro2> BD: EGNV1 ##<parametro1> = <valor_parametro1> ##<parametro2> = <valor_parametro2> BD : Y25 <parametro1> = <valor_parametro1> <parametro2> = <valor_parametro2> BD: E45 ##<parametro1> = <valor_parametro1> ##<parametro2> = <valor_parametro2>

Parmetros dos scripts;

Parmetros de Scripts de IMPORT de Dados

Para pacotes que incluem instrues de Import de Dados, com incluso de ficheiros de extenso dmp, obrigatrio constar o schema origem e o schema destino. Na criao/alterao de objectos (tabelas e ndices) obrigatrio a identificao da volumetria inicial e crescimento expectvel a 1 ano, por nmero de registos. No script de create table e create index dever ser includo o parmetro &tbs, por cada objecto (no nos podemos esquecer que cada Tabela/ndex ter que ter a sua prpria varivel de tablespace ex: &tbs1, &tbs2...&tbsn). O Valor da tbs ser passado na instalao pela equipa DBA. No deve indicar a STORAGE. Ex1: FORMS: <Tabela_A1> <Volume inicial - xxxx registos> <Previso de Crescimento Anual xxxx registos> Ex2: Alterao tabela <Tabela_A1> Incluso de novo atributo <Atributo>;<dominio>;<outros> Obs.: Caso se deseje usar PL/SQL, deve usar a clausula EXCEPTION

Volumetria de novos objectos ou de objectos alterados;

para tratament os de erros. No deve usar EXCEPTION WHEN OTHERS THEN NULL; Ordem de instalao de scripts (Ver abaixo as regras para criao dos scripts); Tempo previsto de instalao/volume de informao a tratar do script Identificar a ordem pela qual devero ser instalados os scripts (mesmo que haja apenas um nico script no pacote); Todos os scripts tero que estar mencionados no PI. Dever ser identificado o tempo expectvel da instalao de cada script bem como o volume de dados a tratar (expectvel);

Notas de Impacto de pacotes .MD (Manipulao de Dados)

[Alterao Dez/2007] A nvel dos pacotes de Manipulao de Dados -.md, devem respeitar-se as seguintes regras, de carcter obrigatrio:

Ambiente

[Alterao Dez/2007] Identificar claramente o(s) ambientes a que se aplica a Manipulao de Dados. Ex: Ambiente: QGNV1 e EGNV1

Motivo da alterao de Dados

Resumir o motivo da alterao dos dados (erro identificado e respectiva causa) Dever ser identificado o tempo expectvel da instalao de cada script Identificar tabela a tabela o tipo de aco Insert, Update, Delete e o n de registos afect ados, estimados ou no limite a ordem de grandeza. Ex: Tabela: Produtos; Insert; 5 registos; Clientes; Update; 20 registos;

Tempo previsto de instalao Tabelas afectadas, tipo de aco e respectivos n de registos afectados ou estimados

Constrangimentos na execuo

[Alterao Dez/2007] Identificar claramente quaisquer constrangimentos, justificados, execuo da Manipulao de Dados; Caso a nvel de negcio no hajam constrangimentos deve ser indicado Aplicar logo que possvel Ex1: Constrangimentos: Aplicar logo que possvel Ex2: Aplicar aps

Responsvel para contactos

[Alterao Dez/2007] Identificar o responsvel da Manipulao de Dados para contactos em caso de dvidas ou erros na execuo

Criao dos Scripts

Extenso .sql A extenso de cada um dos scripts dever ser obrigatoriamente: .sql Extenso .dmp A extenso de cada Dump dever ser obrigatoriamente: .dmp No incluir espaos no nome do script Header informativo O nome do script no poder conter espaos; Cada script dever conter um header informativo descrevendo o seu nome, sua finalidade (breve descrio), o nome do autor/responsvel e respectiva equipa. EX: /* Nome do script: Finalidade: Nome/Responsvel: */ Nomes de utilizadores nunca devero ser referenciados dentro dos scripts. Desta forma um pacote/ script poder ser executado em qualquer ambiente, sem necessidade de alterao. EX: Create or replace procedure XPTI_PRC. Uma excepo a esta regra o caso quando os scripts so executados com um user DBA e os objectos para serem criados no schema correcto devem referenciar o nome do schema. EX: Create or replace procedure siebel.XPTO_PRC .. Nunca devero ser criados scripts dentro de um mesmo pacote para execuo em ambientes diferentes. Ou seja: O Script_1 servir para t odos os ambientes do ciclo; No devem ser criados nunca script1_QA.sql e o Script1_PRD.sql Pretende-se com isto que um script que executado em Testes possa ser re-executado em Produo sem qualquer alterao. EX: BD: IST ## user = <valor_parametro1> BD: PRD ## user = <valor_parametro1> Grant select on siebel.s_asset to &user;

No referenciar nomes dos utilizadores dentro do script

O script dentro de um pacote deve ser executvel em qualquer ambiente do ciclo de vida definido (usar variveis de ambiente &)

Terminar comandos com ;

Todos os comandos SQL devem sempre terminar com ; ou ;/. No utilizar as duas formas, excepto para functions, procedure,

packages ou blocos annimos.

De notar que o / no final de um comando SQL poder implicar a sua reexecuo. No caso de no ter sido, utilizada nenhuma das situaes acima referenciadas, o comando sql no ser executado.

No caso dos Anounymous PLSQL deve-se terminar os programas da seguinte forma: EX: END; / Evitar o uso do caracter & dentro dos scripts (excepto para solicitar parmetros de entrada). O & um caracter especial do sqlplus, sendo que a presena do mesmo num script equivalente a uma varivel, a qual ser solicitada durante a execuo. Se efectivamente for necessrio utilizar este caracter dever-se- colocar no incio e no final do script o seguinte: set define #; . . .<corpo do script> set define &; Nota: Neste caso assume-se que o carcter # no deve estar presente no script a executar. Os scripts devero ser preferencialmente identificados com letras minsculas, incluindo a extenso do mesmo.. A definio dos scripts dever ser feita, na sua totalidade, com letras minsculas ou, na totalidade com letras maisculas. Esta regra abrange tambm as extenses dos scripts. No permitida a identificao de physical storage (logging, parallel, ) na criao dos objectos. A excepo a esta regra o uso do parmetro tbs, usado para definir a tablespace que ser usada, conforme definido acima. No plano de instalao, a informao sobre a quantidade de registos das tabelas e ndices necessrio que seja includa a clusula de tablespace e dever haver uma passagem de parmetro, indicando qual a tablespace mais adequada para o uso. O preenchimento do valor da varivel dever ser feita pelo DBA, a partir da informao fornecida de quantidade de registos iniciais e finais. EX: create table XPTO (a date) tablespace &tbs;

Evitar o uso do caracter &

Nome dos scripts em minsculas

Physical storage

Log de execuo

No deve ser usado comando de spool no incio do script para gerao de log da execuo do mesmo. O Gestor de Verses Harvest j o faz

automaticamente, ignorando estes comandos no interior dos scripts. Ex: (NO DEVE SER FEITO) SPOOL <n de pacote>_<nome do script>.log ..... SPOOL OFF;

Plano de Rejeio
Sempre que um pacote incorra em falta de informao ou incorreco nos scripts que invalidem a correcta instalao do pacote quer em Testes quer em Produo, o pacote ser rejeitado. Nesse caso a equipa ST/ABD incluir na Nota de Rejeio a informao considerada relevante, conforme abaixo:
Nmero de Rejeio, data e hora da rejeio As equipas envolvidas na rejeio do pacote devero colocar a identificao da sequncia, dada e hora da rejeio e nome do DBA envolvido na rejeio: Ex: 2 Rejeio 05/05/2005 10:00 Nome DBA ADBA1 1 Rejeio 03/12/2003 18:30 Nome DBA BDBA2 Motivo de rejeio Descrio clara e concisa do motivo de rejeio com eventual acompanhamento do erro ocorrido ou sugesto de correco. De forma a facilitar a identificao do motivo da rejeio mais recente, as notas de rejeio sero includas cabea do Atributo Nota de Rejeio Ex: 3 Rejeio 03/12/2003 19:50 .... 1 Rejeio 03/12/2003 18:30

As notas de rejeio sero includas por ordem de decrescente de nmero de rejeio ( cabea)

Construo de scripts correctivos

Conforme Erro/Correco indicar no PI instrues para DBA. Caso o contedo do pacote no tenha correco possvel, o pacote passar ao estado de descontinuado, no evoluindo no ciclo de vida.

Anexo - CheckList Criao de pacotes Oracle



CheckList para a Criao de Pacotes Oracle 1- O pacote contm scripts para um nico user e BD; 2 - Est identificado o user, bd no plano de instalao, para cada ambiente; 3 - A extenso de cada script est identificada como sql ou dmp; No caso de scripts com extenso DMP, verificar se h a indicao do schema Origem e schema Destino; Devero estar explcitos os parmetros os parmetros: fromuser<schema_origem> touser=<schema_destinio> ignore=y;; 4 - Nome do script no contm espaos ( ) ; 5 - Pacote contm indicao para apenas uma BD por ambiente; 6 - No definido o owner dentro dos scripts, com excepo da instalao feita com o user DBA No caso da excepo mencionada, a instalao ser efectuada com o user DBA, dever ser includo no plano de instalao), casos SIEBEL, etc 7 - No definido o owner dentro dos scripts, com excepo da instalao feita com o user DBA Todos os comandos SQL devem sempre terminar com ; ou ;/. No utilizar as duas formas, excepto para functions, procedure, packages ou blocos annimos. 8 - O carcter & exclusivamente utilizado como passagem de parmetros, com excepo deve-se usar define # Assume-se que o carcter # no esteja presente no script a executar, de forma que o sqlplus trate o & como um caracter comum; 9 - No usado o spool <nome da ficheiro>.log. Considera-se que o harvest j cria logs; 10 - Os scripts so executados em todos os ambientes, sem alteraes; 11 - Backups adicionais so solicitados por e-mail ou ticket Remedy; 12 - Esto Identificados os parmetros de entrada por cada BD ambiente; 13 - A volumetria das novas tabelas criadas est identificada; 14 - Esto definidos os parmetros tbs - tablespace para cada nova tabela criada; 15 - A ordem de instalao dos scripts est identificada no plano de instalao; 16 - Evitou-se a colocao de DML e DDL dentro de um mesmo script; 17 - Foram realizados Testes unitrios no ambiente de Desenvolvimento; 18 - Foram realizados Testes de sintaxe e Testes Integrados no Ambiente de Testes Neste caso dever ser usado sqlplus, outras ferramentas (como o TOAD) podem mascarar os resultados, e ter comportamentos diferentes do que o SQL Plus (ferramenta que utilizada para instalao dos pacotes, seja via Harvest, seja manualmente;