Olá Priscila, Além dos detalhes citados, outras considerações na elaboração da sua estimativa :
- tempo de backup antes de fazer qualquer movimentação e garantir rollback (se necessário for) - tempo de validação pós migração, oferecer ao Cliente tempo para ele ver que tudo está conforme esperado - tempo do seu suporte pós-migração, para garantir que seu trabalho foi realizado com sucesso, que pode ser um acompanhamento de 1 dia, 1 semana ou 1 mês, pois tem processamento que roda apenas 1 vez por mês, por semana ... por dia ... coisas assim ... Isso tudo dentro da "janela" que você tem para realizar a atividade "migração" e ainda assim, se isso demorar mais do que X horas ... o quanto você suportará fisicamente até a atividade, para assim mostrar ao seu cliente que chegará ao fim do trabalho. Isso tudo também é valor tanto para você como para o Cliente. Espero ter ajudado. Eriovaldo 2013/11/13 Alessandro Lúcio Cordeiro da Silva <alecordeirosi...@yahoo.com.br > > > > > > Somente uma observação quanto ao cobrar por tempo de migração, na verdade > isso vale por qualquer serviço que você fizer. Não pense em comprar baseado > somente no parametro tempo, na verdade em muitos casos o valor a ser > cobrado é inversamente proporcional ao tempo. > > Uma vez um amigo meu ligou desesperado porque o banco de dados dele > estava fora do ar, o DATAFILE SYSTEM está com SCN a frente do SCN do > controlFile e o banco de dados não abria. Usei apenas 1 comando e em MENOS > de 5 minutos o banco estava no ar. Então devo receber menos do que alguem > que ficou horas para, por exemplo recriar um novo banco, importar os dados > usado o IMP(DP) e depois disso entregar um banco com os últimos dados > faltando? > > Veja que o conhecimento em Oracle fez toda a diferença, e esta diferença > não vem por osmose, vem por horas e horas de estudo e reproduzindo em > cenários de testes. > > Então o que eu acho melhor é você criar uma tabela de serviço/Hora onde > cada hora tem o seu preço diferente para cada serviço. Tente criar esta > tabela mais especifica possível. Tipo a sua migração vai incluir mudança do > S.O e Hardware? Você sempre deve ter isso em mente. > > > Alessandro Lúcio Cordeiro da Silva > Analista de Sistema > þ http://alecordeirosilva.blogspot.com/ > Porque esta é a vontade de Deus, a saber, a vossa > santificação: que vos abstenhais da prostituição. > (1º Tessalonicenses 4:3) > > > > Em Quarta-feira, 13 de Novembro de 2013 15:42, angelo < > angelolis...@gmail.com> escreveu: > > Acho que a experiencia também conta > > Vc ja fez migração antes? mesmo que pequenininha > Concordo em fazer um ensaio, num ambiente de homologacao, pra pegar todos > aqueles detalhezinhos que são aparecer na execução e ir anotando. Quanto > mais parecido com o real, melhor. > > > > > 2013/11/13 Rodrigo Gallacci <rodrigo.galla...@gmail.com> > > > Eu sinceramente analisaria o tamanho dos databases, veja o exemplo: > > Um DBA Pleno (sendo sincero) levaria em tese o mesmo tempo para migrar a > base que um Sênior, porém, se for encontrado algum bug/problema/falha no > processo um Sênior resolveria muito mais rápido, por isso o valor mais alto. > > Quanto à tempo de base, vamos expor um ambiente à prova, um expdp de um > database que gerasse 50G de dmp levaria em torno de 5 horas pra migrar, > isso sem contar a preparação, etc, etc. > > Eu cobraria um X á cada 100G de "base de dados real". E esse X seria > calculado na média: > > X = 80% do valor hora > > Ou cobre uma hora pra cada 100G de base de dados. > > Rodrigo Gustavo Gallacci > DBA Oracle ATG > > > 2013/11/13 Rafael Mendonca <raffaell.t...@yahoo.com> > > > Eu faria como o Chiappa recomenda, faria uma simulação do upgrade em um > database de teste e cronometrava quanto tempo daria, com isso veja o valor > da sua hora e multiplique pela quantidade de horas da simulação feita em um > ambiente de teste, colocaria algumas horas a mais por precaução (pois pode > ocorrer algum bug ou algo semelhante, e se for feito a noite ou no final de > semana/feriado vc com certeza reajustaria o valor da sua hora. > > > Em Quarta-feira, 13 de Novembro de 2013 12:51, J. Laurindo Chiappa < > jlchia...@yahoo.com.br> escreveu: > > Priscila, acho que tanto eu quanto o Rodrigo concordamos que a medida > principal é a quantidade de horas : não é absolutamente viável cobrar por > número de bases ou coisa assim, porque NADA IMPEDE do seu cliente ter uma > base gigantesca e uma pequenina, o que DISTORCERIA ENORMEMENTE a sua > cobrança, sim ??? > E para vc chegar na quantidade de horas, isso é uma função dos volumes das > bases todas e das dificuldades que podem surgir, coisas essas que vc só > "pega" fazendo uma análise de algumas horinhas para levantamento... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Priscila Viana <priska.san@...> > escreveu > > > > Não preciso de valores caso não possa colocar, mas de como cobrar mesmo, > se > > por base, por projeto, por tempo... > > Em 13/11/2013 13:24, "Rodrigo Gallacci" <rodrigo.gallacci@...> > > escreveu: > > > > > > > > > > > Na verdade eu julgo o valor relativo ao tempo que irá levar (o que tem > > > haver com tamanho da base de dados) e do know how de quem vai fazer. > > > > > > Aliás, não sei se podemos discutir valores nessa lista. Podemos? > > > > > > Rodrigo Gustavo Gallacci > > > DBA Oracle ATG > > > > > > > > > 2013/11/13 Priscila Viana <priska.san@...> > > > > > >> > > >> > > >> Solaris, bendito corretor do teclado do celular! > > >> Em 13/11/2013 13:09, "Priscila Viana" <priska.san@...> escreveu: > > >> > > >> Como devo cobrar um projeto de migração de banco oracle 9 para 11 em > > >>> plataformas windows e solares, quais pontos devo levar em > consideração? > > >>> Preciso de ajuda tenho reunião amanhã e nunca fiz esse tipo de > trabalho > > >>> por fora. > > >>> Obrigada. > > >>> Priscila Viana > > >>> > > >> > > > > > > > > > > > > > > > > >
