Repositório do RMAN: catálogo ou controlfile?

Em nosso último artigo ('Superprofissionais') nós interrompemos, por um momento, a série que aborda segurança de infra-estrutura em bancos de dados Oracle.

Aproveitando o intervalo, neste artigo nós vamos falar sobre o repositório do RMAN.

Definição

Entende-se por repositório do RMAN (Oracle Recovery Manager), o local onde são armazenadas informações sobre os metadados dos backups, archived logs e suas próprias atividades.

O local de armazenamento primário usado como repositório do RMAN é o controlfile (banco de produção, alvo do backup).

Mas também pode ser configurado um 'catálogo de recuperação independente' (recovery catalog), que é um schema que armazena o repositório do RMAN, contendo informações sobre um ou mais bancos.

É recomendável que o schema do recovery catalog seja armazenado em um outro database, montado em uma outra máquina, diferente de onde está rodando o banco alvo.

Essa recomendação faz sentido devido ao fato de ocorrência de uma eventual falha no banco alvo, ou na máquina onde este roda, seriam perdidas também as informações sobre os backups.

O recovery catalog é opcional.

Se não for configurado um recovery catalog, o RMAN irá usar o controlfile do banco alvo do backup como um repositório dos metadados do backup.

Os dados contidos no repositório do RMAN, tanto no controlfile como no recovery catalog, são usados para gerenciar os backups, restaurar e recuperar os bancos.

'Polêmica'

A 'polêmica' que eu me refiro aqui é referente ao uso de um ou outro repositório do RMAN.

Isso porque já existem controvérsias em relação ao controlfile, que muitos não o consideram como um repositório, embora a documentação oficial da Oracle e a prática nos diga que sim, que o controlfile pode ser usado como repositório do RMAN.

E também não vamos questionar se o recovery catalog, caso seja usado, deve ficar na máquina onde roda o banco de produção (alvo do backup) ou em um outro database, em uma outra máquina.

Eu entendo isso como fato consumado: o recovery catalog deve ficar em um outro database, em uma outra máquina diferente do banco alvo.

Vamos nos ater à opção entre um ou outro repositório, controlfile ou recovery catalog.

Controlfile

O controlfile armazena tudo o que é necessário para o gerenciamento dos backups, restauração e recuperação do banco.

'Superprofissionais'

Interrompendo por um momento, a série de artigos sobre segurança de infra-estrutura, vamos falar neste artigo sobre a divisão das tarefas nas atividades de TI.

São poucas as empresas que dividem de forma adequada as atividades na área de tecnologia, com funções bem definidas e diferenciadas.

O número de empresas que possuem profissionais específicos para cada área específica é ainda menor.

Voltando no tempo

Lembram dos 'antigos' CPDs?

Pois é, muitos sobrevivem até hoje.

Para quem não lembra, ou não teve o prazer de conhecê-los, os CPDs eram locais freqüentados, basicamente, por pessoas pouco sociáveis, de pouca conversa e menos amigos ainda, cercados por computadores e periféricos (funcionando ou não), ferramentas, etc.

De óculos e quase gênios, entendiam de tudo e mais um pouco sobre 'computadores'!

Podiam concertar desde calculadoras até computadores, impressoras, etc, passando por carrinhos de controle remoto.

Eram 'superprofissionais'!

Exagerando um pouco nas citações acima, fiz questão de lembrar dos CPDs apenas para mostrar que a visão a cerca dos profissionais de TI tem um antecedente histórico (se é que podemos assim dizer).

'Off-topic'

Falando sobre estes 'superprofissionais' dos CPDs, eu me lembrei das muitas cobranças que recebo por ser formado na área de tecnologia e trabalhar com computadores.

As pessoas 'normais' pensam que quem trabalha com computadores tem a obrigação de conhecer tudo sobre eles, independente da área em que atuam.

Se estes profissionais possuírem curso superior, a cobrança aumenta, e se possuírem especializações, pós-graduações, certificações... então é que a coisa aperta.

Quem nunca ouviu falar algo do tipo:

- Como pode você 'fulano', formado em Ciência da Computação, que vive fazendo cursos, trabalha o dia inteiro com isso, não conseguir arrumar a minha impressora?

- E este vírus que entrou na minha máquina, como é que você não consegue remover?

- Como você não conhece o software que o meu professor de informática (básica) me ensina?

- Como pode você não conseguir adicionar um vídeo na minha apresentação?

Limitando Quotas de Tablespaces

Neste artigo vamos falar sobre as quotas dos usuários nas tablespaces.

Qual o espaço que um usuário pode usar em uma tablespace?

Em quais tablespaces um usuário pode criar objetos?

As respostas a estas perguntas dependem das quotas disponíveis para o usuário nas tablespaces.

Definição de quotas

A quota que um usuário tem em uma tablespace pode ser definida na criação do usuário ou após a sua criação.

Para definir a quota no momento da criação do usuário, basta adicionar uma cláusula do tipo:

QUOTA <tamnho> ON <nome_tablespace> 

Por exemplo, vamos criar um usuário com quota de 12Mb em uma tablespace.

CREATE USER usr_1 IDENTIFIED BY senha_usr_1

DEFAULT TABLESPACE tabs1

TEMPORARY TABLESPACE temp

QUOTA 12M ON tbs_1;

Obs.: Podem ser adicionadas múltiplas cláusulas QUOTA, para definir quotas em várias tablespaces.

Para alterar a quota do usuário de 12Mb para 20Mb, teríamos:

ALTER USER usr_1 QUOTA 20M ON tbs_1;

Isso limitaria o usuário usr_1 a criar objetos como tabelas, índices e views materializadas até o limite de 12Mb, de acordo com a criação (CREATE USER .. acima), ou 20Mb após a alteração (ALTER USER .. acima) na tablespace tbs_1.

O comando abaixo pode ajudar a verificar quanto cada usuário está usando nas tablespaces e quais as quotas.

select username, tablespace_name,

bytes/1024/1024 usado_MB,

max_bytes/1024/1024 quota_Mb

from dba_ts_quotas

order by username;

Uma particularidade na análise do retorno destas informações é quanto ao valor "-0,000" (ou algo do tipo).

Este valor 'zero negativo' diz respeito à quota ilimitada (UNLIMITED QUOTA) na respectiva tablespace.

São estes casos que merecem atenção especial.

Um usuário pode receber quota ilimitada em uma tablespace no momento de sua criação ou após.

Por exemplo, na criação teríamos:

CREATE USER usr_2 IDENTIFIED BY senha_usr_2

DEFAULT TABLESPACE tabs2

TEMPORARY TABLESPACE temp

QUOTA UNLIMITED ON tbs_2;

E após a criação, caso a cláusula "QUOTA UNLIMITED ON tbs_2" não tivesse sido usada no momento da criação do usuário, por meio de um ALTER USER, teríamos:

ALTER USER usr_2 QUOTA UNLIMITED ON tbs_2;

Segurança

Este ato pode ter implicações de segurança.

Autenticação Remota de Usuários- Remote OS Authentication

No último artigo, nós falamos sobre a autenticação de usuários via sistema operacional - OS Authentication.

Seguindo adiante, na série de artigos sobre segurança de ‘infra-estrutura’ em bancos de dados Oracle e complementando o último artigo, vamos comentar sobre a Autenticação Remota - Remote OS Authentication - uma variação da autenticação via sistema operacional.

Autenticação de Usuários via Sistema Operacional - OS Authentication

No artigo anterior, sobre autenticação via sistema operacional, vimos como isso pode ser feito, seus benefícios e os cuidados que devemos tomar para não deixar que isso se transforme em uma 'brecha de segurança'.

Demonstramos que é possível criar um um usuário que será autenticado no sistema operacional local e configurá-lo para conectar no banco com um simples comando, sem informar usuário e senha. Algo do tipo:

sqlplus /

Vimos também que isso é útil para a manipulação e execução de scripts, mas pode ser uma vulnerabilidade se o ambiente possui um esquema de autenticação de sistema operacional fraco.

Isso funciona para usuários locais, que estão no mesmo servidor onde o banco roda.

Autenticação remota -  Remote OS Authentication

Existe um outro tipo de autenticação de usuários, que usa o princípio da autenticação via sistema operacional, configurada para ser feita remotamente, a partir de um outro ponto da rede, de um outro 'host' -  a Autenticação Remota – Remote OS Authentication.

Então, o que aconteceria se um usuário de um servidor remoto tentasse conectar ao banco?

Podemos tomar como exemplo, um ambiente contendo dois servidores, host1 e host2, com o banco rodando no host1. Este banco tem o usuário ops$user_name identificado externamente. Digamos que haja um usuário user_name no host2, mas não no host1.

Quando o usuário user_name do host2 tentar conectar no banco que está rodando no host1 com o comando:

sqlplus /@host1

ele iria conseguir conectar?

Autenticação de Usuários via Sistema Operacional - OS Authentication

Dando continuidade à série de artigos sobre segurança de ‘infra-estrutura’ em bancos de dados Oracle, vamos abordar neste artigo uma das formas de autenticação de usuários em bancos Oracle: Autenticação via Sistema Operacional.

Autenticação via banco

Os usuários Oracle podem ser autenticados de diferentes formas, sendo que a mais comum é a autenticação via banco.

Quando um usuário é criado com o comando "create user <user_name> identified by <user_password>;", a única forma de o usuário 'logar' no banco é informando usuário e senha.

Autenticação via Sistema Operacional

Uma das alternativas de autenticação de usuários é a autenticação via sistema operacional.

Consideremos a criação de usuário conforme abaixo:

create user <ops$user_name> identified externally;

Se o sistema operacional tem um usuário chamado "user_name", então o Oracle não irá mais checar as suas credenciais. Ele simplesmente assume que o sistema operacional fez a autenticação e permite que o usuário acesse o banco normalmente, sem nenhuma verificação adicional.

Mas é ai que mora o perigo!

Se o ambiente possui uma política 'forte' de autenticação de usuários via sistema operacional, então o procedimento é seguro. Mas se o ambiente é 'fraco' em autenticação via sistema operacional, então há riscos de um usuário quebrar senhas ou entrar no banco sem precisar informá-las, apenas com:

sqlplus /

Entenda que, na falta de informações sobre usuário e senha, a string "/" instrui o banco a aceitar a conexão do usuário <user_name> à conta do banco do usuário <ops$user_name>.

Utilidade

Este tipo de autenticação, geralmente é muito útil em scripts de sistema operacional (shell scripts), onde a senha do usuário de banco não está embutida nos scripts, havendo apenas um comando do tipo 'sqlplus /' para que seja efetuada a conexão.

Pelo simples fato de a senha do usuário não estar presente nos scripts, podemos considerar este método conveniente e seguro. Mas devemos contar com a possibilidade de que, em um ambiente com autenticação de sistema operacional 'fraca', alguém pode criar um usuário (de sistema operacional) chamado <user_name> e poder efetuar o login no banco através da conta <ops$user_name>, com o comando 'sqlplus /'.

A string que identifica a autenticação via sistema operacional não precisa ser 'OPS$', como temos utilizado nos exemplos. Ela pode ser modificada, alterando-se o parâmetro do banco os_authent_prefix.

Para sabermos quem são os usuários corretamente configurados para serem autenticados pelo sistema operacional podemos usar o seguinte comando:

Aplicando um pouco de segurança ao LISTENER - PASSWORD LISTENER

Neste artigo vamos abordar mais um aspecto de segurança em infra-estrutura em bancos Oracle, mais especificamente sobre o LISTENER.

Um outro tema abordado no documento do Sr. Arup Nanda é referente ao LISTENER.

Ameaças

Uma das mais populares estratégias de ataque à infra-estrutura Oracle é a inserção de uma grande quantidade de texto no arquivo de parâmetros do LISTENER.

Este tipo de ataque faz com que o LISTENER tenha problemas e aborte sua execução.

O banco poderia estar aberto normalmente, mas com o LISTENER 'fora', não seriam permitas novas conexões ao banco.

Para fazer isso, o invasor poderia tentar alterar os atributos e parâmetros do LISTENER.

Uma tática conhecida é listar os vários serviços atendidos pelo LISTENER, com o uso do comando SERVICES.

Você pode verificar a quantidade de informações relevantes que podem ser obtidas com este comando, usando as instruções abaixo:

LSNRCTL> set displaymode verbose

LSNRCTL> services

Outra tática que o invasor poderia adotar seria 'parar' o LISTENER, o que também faria com que novas conexões fossem rejeitadas pelo banco.

E, finalmente, como o LISTENER pode ser administrado remotamente, o invasor poderia usar esta técnica para 'derrubar' o LISTENER e então explorar outras vulnerabilidades.

Como proteger o LISTNER destas ameaças?

A melhor opção para assegurar o LISTENER contra estas ameaças é retirar todas as permissões dos arquivos executáveis tnslsnr e lsnrctl, exceto dos seus owners. Assim, somente o owner do software Oracle poderia iniciar e parar o LISTENER.

Mas, em alguns casos, é necessário conceder privilégios para iniciar e parar o LISTENER para determinados usuários, tornando necessário conceder permissões de acesso a estes arquivos novamente.

No entanto, o acesso não-autorizado ao LISTENER poderia ser prevenido com o uso de uma senha para o LISTENER (que pode ser em conjunto com a retirada das permissões dos demais usuários).

Quando é definida uma senha para o LISTENER, a maioria dos comandos é desabilitada (comandos como o HELP, por exemplo, continuam funcionando).

Configurando uma senha para o LISTENER

A configuração de uma senha para o LISTENER funciona da mesma forma para todas as versões de banco, mas o processo de aplicação de senha varia, conforme abaixo:

         - Oracle 9iR2 e anteriores - todos os usuários precisam da senha;

         - Oracle 10g - os usuários do sistema operacional, que são owners do software do banco, não precisam de senha. Todos os outros precisam.

A senha para o LISTENER pode ser definida da seguinte forma:

LSNRCTL> change_password

Old password: <senha_antiga>

New password: <senha_nova>

Reenter new password: <senha_nova>

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host)(PORT=1521)(I

VPD - Virtual Private Database - Segurança dos dados em nível de linha

Em um artigo anterior nós fizemos uma breve introdução à segurança em nível de linha (Row Level Security).

Neste artigo vamos falar sobre o VPD - Virtual Private Database - uma feature que a Oracle disponibiliza nas versões Enterprise do seus bancos de dados, a partir da versão 8i, para implementar  a segurança em nível de linha.

Necessidade

A segurança dos dados contidos em um Banco de Dados, até bem pouco tempo, era possível ser garantida simplesmente através dos privilégios de objeto, controlando as operações DML básicas (select, insert, update e delete). No entanto, nos dias de hoje, com o mundo conectado através da internet, ganham cada vez mais espaço as web applications (sistemas desenvolvidos para a web).

A necessidade de disponibilidade de dados on-line e informações em tempo real impulsionam o desenvolvimento deste tipo de aplicação.

Um banco de dados voltado para ambiente web possui características e necessidades peculiares como, por exemplo, a convergência de dados de múltiplos bancos para um único database, fazendo com que dados de diferentes organizações sejam consolidados em um mesmo objeto do banco.

Nos bancos voltados para web, os privilégios de objeto, por si só, não são suficientes para controlar o acesso e garantir a segurança dos dados. Isso porque não será possível apenas dizer que um determinado usuário tem permissão de leitura em uma determinada tabela, mas sim, a quais dados desta tabela ele deve ter acesso. Se não fosse assim, este usuário teria acesso a informações de várias entidades.

Isso é segurança de dados em nível de linha (Row Level Security).

É possível implementar e controlar row level security por meio das aplicações, mas o desenvolvimento e a manutenção das políticas são trabalhosas e não trazem um bom nível de confiabilidade, pois somente o acesso por meio destas aplicações é que estaria assegurado. Se um usuário conseguisse acessar o banco por outra aplicação ou ferramenta (SQL Plus, SQL Developer, Toad, etc), ele não estaria sujeito à política de segurança e poderia ter acesso a todos os dados de um determinado objeto.

VPD – Virtual Private Database

A Oracle possibilita a implementação de row level security por meio do VPD, uma feature nativa da versão Enterprise (8i em diante).

A idéia chave do VPD é adicionar uma condição extra na cláusula WHERE de todos os DMLs, de forma transparente ao usuário.

Nos DMLs concebidos pelo usuário sem uma cláusula WHERE, o VPD se encarrega de 'criar' uma, com os predicados definidos pela política de segurança. Esta política pode ser anexada a tabelas, views e sinônimos e é acionada quando os DMLs acessam os objetos associados com a política.

A segurança dos dados passa então a ser centralizada no banco de dados, valendo para todo e qualquer acesso ao banco, independente da fonte (aplicação, ferramenta de terceiros, SQL*Plus, etc.).

Application Context

Application contexts (contextos de aplicação) são úteis para determinar como a política será implementada, e poderão ser usados na procedure responsável em definir o predicado, a condição 'extra' que será anexada às cláusulas WHERE.

Os contextos podem ser alimentados por meio de trigger (de logon, por exemplo) ou a partir de uma chamada em um determinado ponto da aplicação. Estes contextos podem conter informações sobre conexão (IP, host, usuário) ou conteúdo de qualquer coluna de tabela do banco (nome, código ou cargo do usuário, código da entidade, centro de custo, departamento, etc), o que melhor definir a coluna alvo do VPD, que será usada para definir os privilégios de acesso.

Exemplo:

Consideremos a existência de duas tabelas: gerentes e salarios, conforme abaixo:

gerentes

cod_pessoa nome             cod_empresa

              1            Maria                              1

              2            João                                2

              3            Pedro                              3

salarios

funcionario      salario        cod_empresa

José                   1000                         1

Antônio               2000                         3

Tereza                3000                         1

Betânia               4000                         2

Imaginemos que a coluna alvo do VPD seja a cod_empresa, e esta informação é passada para um contexto no momento em que o usuário faz o logon no banco (por meio de logon trigger).

Neste caso, quando a gerente Maria fizer o logon, a trigger chama a procedure que alimenta o contexto e este recebe o valor 1, que é o código do setor da gerente Maria.

Suponhamos ainda que a política de segurança tenha sido adicionada à tabela salarios, e no momento em que a gerente Maria fizer um SELECT para saber os salários dos funcionários, o VPD vai se encarregar de anexar o predicado 'cod_empresa=1' a todas as cláusulas WHERE.

Então, o SELECT da gerente Maria passa a retornar somente os funcionários José e Tereza, que pertentem à empresa 1.

SELECT da gerente Maria:

         select * from salarios;

Neste momento o VPD iria alterar o comando para:

         select * from salarios where cod_empresa=1;

Certificação Profissional

Neste artigo vamos falar um pouco sobre Certificação Profissional.

Muito se tem falado sobre os programas de certificação profissional, sobre sua validade e utilidade em termos de mercado.

Podemos identificar dois posicionamentos em relação à certificação: de um lado, há muita expectativa por parte dos candidatos à certificação, se ela irá lhes garantir uma posição no mercado, ou o sucesso profissional. E por outro lado fica o mercado, na espectativa de que estes profissionais certificados venham atender a sua necessidade, que não é só por certificação, mas por conhecimento, habilidade, capacidade e diferenciais.

O mercado conhece os profissionais e sabe exatamente do que precisa, qual o perfil ideal.

Já os profissionais nem sempre sabem do que o mercado precisa (e muitas vezes exige), e isso faz com que o mercado siga sem que leve consigo alguns profissionais.

É necessário que o profissional conheça o mercado, entenda suas necessidades e exigências, e faça ou tenha algo mais a apresentar: um diferencial.

Não vou ousar falar em bom e mau profissional, mas em profissional aceito e não aceito pelo mercado.

Podemos analisar o mercado como uma mulher experiente, vivida e exigente, que está em busca do seu parceiro ideal.

Oracle 11g – New Features - II

Recebemos muitos e-mails sobre o primeiro artigo referente à versão 11g (Oracle 11g – New Features - DBAs).

Este segundo artigo sobre a versão 11g tem a intenção de mostrar mais algumas new features aguardadas por todos nós, e já anunciadas pela Oracle.

Como mencionamos no artigo anterior, a oracle tem previsão de lançar a versão 11g oficialmente ainda este ano, talvez no Oracle Openworld 2007 (outubro).

Selecionamos algumas new features interessantes:

RESULT_CACHE - Parâmetro que poderá ser configurado para armazenar o resultado de um comando SELECT em cache. Assim, se uma nova sessão executar o mesmo SELECT, o Oracle poderá retornar o resultado do cache, o que irá resultar em ganho de performance.

SEQUENCES - Em PL/SQL, não será mais necessário usar uma sequence nextval em forma de comando SELECT, com as cláusulas SELECT e FROM (dual). Poderá ser usada uma atribuição direta, por exemplo variavel := sequence.nextval;.

FINE GRAINED DEPENDENCY TRACKING - Adicionando colunas a uma tabela (ou dropando) não irá mais invalidar views e packages (a não ser, é claro, que haja dependêcia das colunas dropadas).

VPD (FGAC) - Passará a ser possível utilizar também nas packages UTL_SMTP, UTL_MAIL e UTL_HTTP.

EDITIONS - Será possível criar e trabalhar com o conceito de versões de views, triggers, sinônimos, etc. no banco de dados. Versões de tabelas só com o já conhecido Orac

Row Level Security - Segurança dos dados em nível de linha

A segurança em ambientes computacionais abrange vários aspectos em diferentes níveis.

Vamos falar um pouco sobre o aspecto da segurança dos dados armazenados no banco de dados, mais precisamente, da segurança em nível de linha (Row Level Security).

A necessidade deste tipo de segurança é decorrente das atividades normais de qualquer organização.

Vamos tomar como exemplo o ambiente familiar.

Neste ambiente também existem diferentes aspectos e níveis de segurança, não só de pessoas e bens, mas também de informações.

Poucas pessoas têm acesso irrestrito ao interior da casa e, as que têm, geralmente, não podem fazer o que querem com os bens, sair, chegar e se alimentar sem restrição de horário, e nem todas podem participar de todas as conversas ou ter acesso a todas as informações. As crianças, por exemplo, além de terem horários estipulados, são freqüentemente barradas em várias conversas do casal.

Deve haver uma certa disciplina, que podemos comparar com a política de segurança dos ambientes computacionais.

Este breve exemplo ilustra de maneira clara como funcionam as coisas nos ambientes computacionais, onde nem todas pessoas têm acesso a tudo, a toda hora e nem podem fazer o que quiserem com as informações.

Faz parte da política de segurança o acesso de pessoal aos elementos do ambiente computacional e o acesso aos dados propriamente ditos.

A segur

Oracle SQL Developer - Apresentação

Neste artigo vamos apresentar o Oracle SQL Developer, uma ferramenta gráfica free voltada para o desenvolvimento e que também oferece várias opções para administração em bancos de dados. O seu principal objetivo é simplificar a execução destas tarefas.

“Esta ferramenta consegue aliar os benefícios da interface gráfica com o poder da linha de comando”

Tom Kyte.

Esta ferramenta é desenvolvida em Java e é certificada para versões de banco iguais ou superiores à 9.2.0.1, incluindo a Express Edition. É multi-plataforma, rodando nas plataformas Windows, Linux e Mac OS X.

Usa JDBC thin driver o que não requer a existência de um Oracle home (instalação de banco ou client).

Para instalá-lo é necessário apenas que, o arquivo que foi baixado do site de downloads da Oracle, seja descompactado.

Oracle 11g – New Features - DBAs

Este ano, provavelmente em outubro, no Oracle Openworld 2007, será lançada oficialmente a versão 11g do RDBMS da Oracle. No ano passado, neste mesmo evento, a Oracle anunciou algumas new features, chegando a 482 o número estimado de novidades.

Neste artigo vamos citar algumas características referentes à administração de banco de dados, que farão parte do Oracle 11g.

- Particionamento – ‘Interval partitioning’ para tabelas, onde automaticamente serão criadas partições baseadas no tempo, quando novos dados forem adicionados e particionamento por objetos lógicos.

- Load Balancing – Inicialmente introduzidas na release 2 do 10g, agora vem um pacote mais completo de utilidades para load balancing. Estão incluídas novidades para o Oracle HTTP Server, RAC, ASM, Data Guard e listener.

- simple_integer datatype – Trata-se de um novo tipo de dados, que sempre será NOT NULL, e mais rápido que o PLS_INTEGER.

- Compressão de tabelas e índices – Passará a funcionar para todos os tipos de DMLs, permitindo que as tabelas marcadas como ‘compressed’ sejam manipuladas como uma tabela ‘normal’. Também permitirá adicionar e remover colunas.

- Triggers – As DML triggers serão mais rápidas, com promessa de serem 25% superiores em relação às atuais, o que impactará nas tri

História da Oracle

Neste ano de 2007 a Oracle comemora o seu trigésimo aniversário.

Em homenagem à esta importante data, vamos falar um pouco sobre sua história.

A Oracle foi fundada em agosto de 1977, inicialmente foi chamada de Software Development Labs (SDL), uma empresa de consultoria que contava com Bob Miner (presidente), Ed Oates e Bruce Scott (engenheiros de software) no seu primeiro projeto.

Larry Ellison, um dos grandes nomes da Oracle, trabalhava na empresa para a qual a SDL prestava a consultoria.

Este Bruce Scott, é o Scott de ‘scott/tiger’ (Tiger era o nome do gato da sua filha), usado até hoje nos schemas de exemplo do sistema gerenciador de banco de dados  (RDBMS) desenvolvido pela empresa.

Antes de formar a Oracle, Bob Miner foi gerente de Larry Ellison em um projeto da CIA, apelidado de “Oracle”.

Ed Oates e Bruce Scott fizeram 90% do trabalho de dois anos (desse projeto de consultoria), no primeiro ano, de modo que tiveram o ano seguinte para trabalhar no Oracle. Ed Oates terminou os outros 10% no ano seguinte, enquanto Bob e Scott começaram a escrever o banco de dados Oracle.

Quando concluíram o trabalho decidiram então, que queriam ser uma empresa de produto, em vez de uma empresa de consultoria.

Mas Larry não estava interessado nisso. Ele estava acompanhando o que a IBM estava fazendo e descobriu um trabalho sobre o System/R baseado no trabalho de 1970 de Codd sobre bancos de dados relacionais. Ele descrevia a linguagem SQL, que na época era chamada SEQUEL/2.

Larry levou o trabalho a Bob e Scott e perguntou se eles poderiam montar isso. Acharam que seria muito fácil e assim começaram.

Scott tinha 24 anos na época, Bob era 15 anos mais velho e Larry era 10 anos mais velho que Sccott.

Scott deixou a Oracle em 1982, depois de aproximadamente cinco anos e meio trabalhando lá. Quando saiu, eles

Boas Vindas

Sou Anderson Rodrigo Farias, formado em Ciência da Computação pela Universidade do Extremo Sul Catarinense – UNESC e pós-graduado em Gerenciamento de Banco de Dados, também pela UNESC.

Atuo como DBA Oracle da Betha Sistemas LTDA, uma empresa de desenvolvimento de softwares para órgãos públicos de todo o país.