MENU

quinta-feira, 14 de junho de 2012

READ ONLY table? Abordando uma nova funcionalidade do Oracle 11g


Para permitir o acesso somente leitura a uma tabela no banco de dados Oracle, normalmente utilizamos a sintaxe GRANT SELECT ON [tabela] TO [usuario], ou seja, somente o privilégio de objeto SELECT será dado pelo usuário proprietário da tabela a um outro usuário do banco de dados. Bem, e se quisermos que o proprietário da tabela também tenha acesso somente leitura a esta tabela? Por padrão, o proprietário (owner) da tabela não possui nenhuma restrição de escrita em suas próprias tabelas e, neste caso, para que o proprietário da tabela tenha acesso somente leitura à tabela, seria necessário criar uma TRIGGER de banco de dados que restringiria operações de INSERTUPDATE e DELETE na tabela, ou até mesmo uma outra solução mais simples, como a de criar uma restrição CHECK no estado DISABLE VALIDATE como demonstrado abaixo:

oracle11g@linux-abr6:~> sqlplus / as sysdba
QL*Plus: Release 11.1.0.6.0 - Production on Sex Mai 2 19:15:56 2008
S Copyright (c) 1982, 2007, Oracle. All rights reserved.
11.1.0.6.0
Conectado a: Oracle Database 11g Enterprise Edition Releas e- Production
tioning, OLAP, Data Mining and Real Application Testing options SQL> conn sc
With the Part iott/tiger Conectado. SQL> create table test (id number); Tabela criada.
d constraint chk_read_only check(
SQL> insert into test values (1); 1 linha criada. SQL> alter table test a
d1=1) DISABLE VALIDATE;
abela alterada.
T
L> insert into test values (2);
S Q
nsert into test values (2)
i* ERRO na linha 1:
serção/atualização/deleção na tabela com restrição (SCOTT.CHK_READ_ONL
ORA-25128: Não há i nY) desativada e validada
update test set id=2;
SQL>
pdate test set id=2
u* ERRO na linha 1:
serção/atualização/deleção na tabela com restrição (SCOTT.CHK_READ_ONL
ORA-25128: Não há i nY) desativada e validada
delete from test;
SQL>
elete from test
d*
O na linha 1: OR
ER
RA-25128: Não há inserção/atualização/deleção na tabela com restrição
(SCOTT.CHK_READ_ONLY) desativada e validada
truncate table test;
SQL>
runcate table test
t* ERRO na linha 1:
serção/atualização/deleção na tabela com restrição (SCOTT.CHK_READ_ONL
ORA-25128: Não há i
nY) desativada e validada

Em resumo, se houver uma restrição DISABLE VALIDATE, então nenhuma modificação será permitida nas colunas restringidas, ou seja, qualquer comando DML e/ou DDL (truncate) não será permitido. Para informações adicionais, no artigo deFevereiro de 2008, eu descrevo sobre algumas funcionalidades dos estados das restrições de integridade.

Aliás, se você percebeu, eu estou conectado a um banco de dados Oracle 11g (11.1.0.6.0) e isso não é por acaso. Nas versões anteriores ao Oracle 11g, para criarmos uma tabela somente leitura teríamos que usar um dos métodos mencionados acima, mas agora poderemos utilizar a facilidade do comando ALTER TABLE que foi aprimorado no Oracle 11g para permitir alterar o estado de uma tabela do modo READ WRITE para o modo READ ONLY e vice versa.


Para demonstrar esta nova funcionalidade, irei criar uma nova tabela de teste.

SQL> drop table test;
Tabela eliminada.
st (id number); Tabela criada. SQ
SQL> create table t eL> insert into test values (1); 1 linha criada.
-- Acessando a view USER_TABLES, podemos verificar que a tabela não está no modo
-- somente leitura
SQL> select table_name, read_only from user_tables;
TABLE_NAME READ_ONLY
EST
------------------------------ ---------
TNO
-- Alterando a tabela para o modo somente leitura
SQL> alter table test READ ONLY;
abela alterada.
T
L> select table_name, read_only from user_tables;
S QTABLE_NAME READ_ONLY
EST
------------------------------ ---------
TYES
QL> insert into test values (2);
S
nsert into test values (2)
i * ERRO na linha 1:
ualização não permitida na tabela "SCOTT"."TEST" SQL>
ORA-12081: operação de a
tupdate test set id=2;
update test set id=2
* ERRO na linha 1:
de atualização não permitida na tabela "SCOTT"."TEST" SQL>
ORA-12081: operaçã
odelete from test;
delete from test
*
linha 1: ORA-12
ERRO n
a081: operação de atualização não permitida na tabela "SCOTT"."TEST"
QL> truncate table test;
S
runcate table test
t *
ha 1: ORA-12081:
ERRO na li
n operação de atualização não permitida na tabela "SCOTT"."TEST"

Então, uma vez que a tabela esteja no modo somente leitura (READ ONLY), nenhum comando DML ou comando DDL (truncate) que modifiquem os dados da tabela não poderão ser executados. Inclusive, os comandos MERGE ou até sentenças SELECT FOR UPDATE não serão permitidos. No meu ponto de vista, esta funcionalidade acrescentada ao comando ALTER TABLE é de muita utilidade quando por algum motivo precisarmos de forma fácil e rápida restringir o acesso de escrita aos usuários nas tabelas do banco de dados.

-- Alterando o modo da tabela para permitir operações de escrita
SQL> alter table test READ WRITE;
abela alterada.
T
L> select table_name, read_only from user_tables;
S QTABLE_NAME READ_ONLY
EST
------------------------------ ---------
TNO
QL> drop table test;
S
bela eliminada.
T a


Oracle Database 11G: 5 mudanças que ocorreram em relação ao 10G


     No artigo de hoje vou comentar sobre algumas mudanças que ocorreram no Oracle Database 11G, em relação a versão anterior deste Banco de Dados (BD), o Oracle Database 10G. Este artigo será bastante útil para quem deseja atualizar o BD para 11G ou para quem já atualizou e ainda não identificou todas as mudanças que ocorreram. Aconselho a aqueles que ainda irão fazer a atualização, que leiam antes o artigo Atualização/Migração de Banco de Dados Oracle 10G para 11G e que configurem o parâmetro COMPATIBLE do BD para manter o 11G com as características de um 10G temporariamente, com o objetivo de "dar um tempo" para que as aplicações sejam adaptadas às mudanças desta última versão.

     As principais mudanças que foram implementadas no 11G e que impactaram nos sistemas dos BDs que eu administro, são relacionadas à segurança do BD. O 11G está mais seguro, nele foram eliminadas várias brechas de segurança que existiam no 10G. Essas novas implementações de segurança, porém, podem gerar erros nas aplicações que já eram executadas no 10G sem problema algum. Neste artigo você verá alguns erros que podem acontecer e algumas formas de como evitá-los.
    
     Dentre as principais mudanças que ocorreram no 11G, irei destacar as seguintes:

        1- Senhas case sensitive: 
      No Oracle 10G as senhas de usuários não são sensíveis aos caracteres maiúsculos e minúsculos. No 11G, por padrão, as senhas são case sensitive.Para desabilitar esse novo comportamento, se for necessário, altere o parâmetro  sec_case_sensitive_logon do BD, como no exemplo abaixo:
            ALTER SYSTEM SET sec_case_sensitive_logon=FALSE SCOPE=BOTH;
        
          Na empresa em que trabalho precisei implementar esta alteração porque temos algumas aplicações que se autenticam com as contas de usuários Oracle. São aproximadamente 3 mil contas de usuários Oracle que são utilizadas diariamente pelos usuários para se autenticar em algumas aplicações. Para evitar suporte demasiado aos usuários com as senhas após a atualização dos BDs, achamos melhor manter as senhascase insensitive (mesmo comportamento da versão 10G).

        2- Roles default com senhas:
      No Oracle 10G se um usuário possui uma role default com senha, ele pode utilizar todos os privilégios daquela role sem fornecer a senha dela. Sempre que a role for default, o usuário nem precisa saber qual é a senha dela. No 11G isso mudou. Agora mesmo que a role seja default, o usuário terá que fornecer a senha para que ele possa utilizar os seus privilégios. Não adianta nem tentar criar uma trigger de logon para fornecer automaticamente a senha de uma role quando determinado usuário se logar, pois o BD não permite executar código para fornecer senhas de roles dentro de triggers de logon. Se você atualizou para 11G e seu BD não está configurado para o modo de compatibilidade com o 10G, você terá que resolver este problema através de 1 das soluções abaixo:
            a) A aplicação ou usuário que deseja utilizar os privilégios da role default com senha terá que executar o seguinte comando: SET ROLE  nome_role IDENTIFIED BY senha
            b) Você terá que alterar a role para não exigir senha (remover senha da role). Em ambientes de homologação eu não configurei o parâmetro COMPATIBLE, neste caso, tive que implementar esta solução nas roles com senha que existiam nestes BDs.
   
        3- Colunas ambíguas
      Ao atualizar para o Oracle 11G algumas funcionalidades das aplicações podem começar a disparar o erro "ORA-00918 column ambiguously defined". Por que isso não ocorria antes? No 11G o otimizador de queries está mais exigente. Se 2 ou mais tabelas possuem colunas com o mesmo nome, ao especificar estas colunas em uma instrução SQL você deverá obrigatóriamente prefixar o álias ou nome da tabela. Sem prefixá-las, acontecerá o erro ORA-00918. Em algumas versões/patchset do Oracle, ele aceitava nomes de colunas ambíguas sem prefixar álias ou nome da tabela. Para evitar este erro, sempre especifique álias ou nome da tabela como prefixo para nomes de colunas nas instruções SQL. Para mais informações, leia: http://dbaspot.com/oracle-faq/475942-ora-00918-column-ambiguously-defined.html.
  
  
        4- Coluna PASSWORD da visão DBA_USERS
      No Oracle 10G, ao consultar a visão DBA_USERS, a coluna PASSWORD exibia a senha criptografada dos usuários do BD. Com isso, usuários com privilégios de DBA, podiam hackear as senhas de usuários de BD (para mais informações leia o artigo http://www.rodrigoalmeida.net/blog/tecnica-de-hack-em-senhas-armazenadas-pelo-oracle). No Oracle 11G a coluna PASSWORD da visão DBA_USERS não exibe mais a senha criptografada dos usuários. Para fazer isso, agora é necessário consultar a visão USER$.
           Ex.:  SELECT NAME, PASSWORD FROM USER$;
     
        5- Compilação de objetos remotos
      No Oracle 11G, objetos remotos são verificados em tempo de compilação. Isso não ocorria no 10G. Antes, se você referenciava um objeto remoto inexistente em uma Stored Procedure (SP), a SP era compilada sem nenhum problema, pois o Oracle só iria validar a existência daquele objeto em tempo de execução. No 11G o Oracle já faz essa validação em tempo de compilação. Achei essa característica muito boa. Isso evita a compilação de objetos que possam retornar erros futuros. Quando atualizei alguns BDs para 11G, o número de objetos inválidos em alguns desses BDs aumentou consideravelmente, devido a objetos remotos que eram referenciados e que não existiam mais. Estes objetos eram lixo que estavam no BD e que só consegui identificá-los na versão 11G.
   
      

quarta-feira, 13 de junho de 2012

SGDB ORACLE 11g R1 e R1.2 - CONCEITOS BÁSICOS


Oque significa SID?
Oracle System ID (SID)

Para que é usado o SID?
É usado para identificar uma instancia do ORACLE no seu Sistema Nativo(Windows,Linux), ou seja A instância do Oracle tem nomenclatura de SID.

Como eu crio Instancias do Oracle em meu Sistema Nativo?
Utilizando a ferramente dbca(explicada no próximo post(Utilitários do Oracle)) ou manualmente, que realmente para quem não quer ser DBA, não interessa tanto.
Posso ter uma Instancia do Oracle ou ter “n” Instancias, ou seja Posso ter 1 SID ou “n” SIDs.

Como configurar o SID?
Configure a variavel de ambiente, ORACLE_SID . Oque quer dizer que você trabalha em particular com aquela instancia do Oracle. So podemos ter uma instancia configurada na variavel SID.

Qual a relação SID e BD ?
SID é oque chamamos em outros SGBD de Criar um BD, em oracle não se cria um Banco de dados, se instala o SGBD Oracle e se cria Instancias do BD ou seja SIDs.


Como configurar manualmente, ORACLE_SID, ORACLE_HOME and PATH?
. oraenv
So serve para plataformas Nativas derivadas de UNIX, ela configura as variavel de ambiente para que o usuario possa se conectar a uma Instancia do banco de dados. Se essas variáveis não estiverem configuradas utilitários como sqlplus,dbca não vão funcionar.

Oque é um Schema?
É o conjunto de TODOS os objetos que pertencem ao usuário.

Oque são esses objetos pertecentes ao usuário do Schema?
tabelas, views, procedures, functions, packages, etc

Quem é o dono do Schema?
O próprio usuário.

Como Criar um Schema?
Crie um Usuário.

Qual o nome do Schema do Usuário?
O nome do Schema do Usuário é o mesmo do usuário, em um usuário chamado “joao”, temos um Schema respectivo a ele chamado “joao”.

Como é feito a criação do Schema?
Após criar um usuário, o Schema daquele usuário é criado automaticamente pelo Oracle.

Como criar um usuário?
CREATE USER IDENTIFIED BY senha;
Isso é feito no SQLPLUS, que esta logo abaixo em Utilitários do Oracle.

Como criar um banco de dados em Oracle?
Em oracle não temos o conceito de Criar um novo banco de dados, o utilitário – dbca – Cria novas Instâncias ou seja (SID), portanto para criar oque em outros SGBD chamamos de novo banco de dados, Em oracle CRIAMOS tabelas nos usuários ou SID(instancias do Oracle via dbca). Então parar criar um novo “BANCO DE DADOS” em oracle CRIE TABELAS NO USUARIO ou crie novos SID. ISSO É EXPLICADO MELHOR EM UTILITÁRIOS DO ORACLE, logo abaixo.


Qual a relação SID e usuários?
Todos os usuários pertecem a um SID(ou seja o criado com dbca, ou seja o BD).

Como eu crio tabelas?
Crie tabelas usando o usuário que você criou.

Se eu criar as tabelas, de quem serão elas?
Quando você cria as tabelas, elas pertecem ao usuário que criou elas.

Quais são os usuário root do oracle?
System e sys, Porem eles não devem ser usados, somente para a criação de novos usuário. Eles são considerados o “root” em sistemas de plataforma Nativa derivadas de UNIX.

Oque é um Listener?
É um processo, que fica Esperando requisição de Conexão a Instancia do banco de dados, no Servidor.

Oque faz o Listener?
Ele estabelece a conexão entre um client para ter acesso ao Oracle em um Servidor, ou seja:
Cliente <-----> Listener <------> Servidor
Se o Listener achar que a Conexão pode ser estabelecidade, os dados fluem normalmente do Cliente para o Servidor, ou seja

Cliente <--------------------> Servidor
E o processo do Listener fica Aguardando Conexões de outros Clientes.

Aonde ficam armazenados os dados do Listener?
No arquivo Listener.ora

Oque devo Intender do Listener.ora?
01. O nome default do listener é listener;
02. O paramêtro ADDRESS_LIST contém um bloco de endereços nos quais o listener atende as conexões recebidas. Cada endereço definido nesse bloco representa uma maneira diferente pela qual um listener recebe uma conexão;
03. Os endereços IPC identificam solicitações de conexão recebidas de aplicações no mesmo nó do listener e informações enviadas ou registradas pelo dispatcher de um banco de dados. Se os endereços IPC identificarem solicitações de conexão do mesmo nó, o valor KEY será igual ao nome de serviço do banco de dados. Se os endereços identificarem o dispatcher de um banco de dados, o valor KEY será igual ao identificador do sistema de banco de dado(SID). Se o nome de serviço é o mesmo do SID, será necessário apenas um endereço IPC.
04. O endereço TCP identifica as conexões TCP recebidas de clientes na rede que estão tentando se conectar à porta 1521. Os clientes utilizam a porta definida no arquivo tnsnames.ora para conectar-se a esse listener. De acordo com o SID_LIST definido para esse listener, o listener especifica o banco de dados ao qual se conectar.
05. Um listener pode atender a mais de um banco de dados em uma máquina. O bloco SID_LIST_listener_name é onde esses SIDs são definidos.
06. O parâmetro SID_LIST será definido se mais de um SID for definido.
07. O parâmetro SID_DESC deve existir para cada SID definido.
08. ORACLE_HOME é onde o diretório home do banco de dados é definido. Ele permite ao listener identificar o local do arquivo executável de um banco de dados.
09. O parâmetro SID_NAME define o nome do SID com o qual o listener aceita conexões.

Como gerenciar o Listener?
Pelo comando em linha de comando: lsnrctl

Como criar Listener?
Pelo comando em linha de comando: netca

terça-feira, 12 de junho de 2012

Habilitando o archivelog mode no Oracle 11g


Para efetuar backups online (hot backup), isto é, fazer backup do banco de dados com ele UP, não havendo necessidade de parar o banco para fazer (cold backup). Você precisa ativar o modo archivelog, desta maneira, os redo logs online são arquivados, criando arquivos de log de todas as transações do banco de dados.
O Oracle grava nos arquivos de redo log online de maneira cíclica: após preencher o primeiro arquivo de log, ele começa a gravar no segundo, até que ele esteja cheio, e em seguida, começa a gravar no terceiro. uma vez que o último arquivo de redo log online esteja cheio, o processo em segundo plano LGWR (log write) começa a sobrescrever o conteúdo do primeiro arquivo.
Por default o modo NOARCHIVELOG vem como padrão, ele protege a integridade do banco de dados no caso de falha de uma instância ou uma queda de sistema, porque todas as transações encerradas com commit, mas que ainda não foram gravadas nos arquivos de dados estarão disponíveis nos arquivos de redo log online.
Quando o Oracle está executando no modo ARCHIVELOG, o processo em background ARCn (archiver process) faz uma cópia de cada arquivo de redo log antes de sobrescrevê-lo. Exemplo: se o disco que esta os data files der algum problema, com os archives logs podemos reconstruir o banco de dados até o momento anterior ao problema, devido a um backup recente dos data files e aos arquivos de redo log que foram gerados desde que ele ocorreu. Abaixo, uma imagem para ilustrar o processo ARC, copiando os arquivos do redo log e passando para a localização do archive log.


Chega de teoria e vamos para a pratica; verificando se esta ativado o archivelog:
SQL> select log_mode from v$database;
LOG_MODE
————
NOARCHIVELOG

Com esta seleção, percebemos que a resposta é que não esta com o archive log mode ativado, outra forma de verificar se esta em archive log mode é:
SQL> archive log list
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     61
Current log sequence           63

Caso queira mudar a localidade dos archives logs, você pode mudar com o seguinte comando:
alter system set LOG_ARCHIVE_DEST_1=’LOCATION=/u01/app/oracle/flash_recovery_area/ mandatory’ scope=both;

Ok, vimos que o modo archivelog esta desabilitado, para habilitar precisamos parar o banco:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

Subindo a base no estado mount:
SQL> startup mount;
ORACLE instance started.
Total System Global Area  535662592 bytes
Fixed Size                  1337720 bytes
Variable Size             327157384 bytes
Database Buffers          201326592 bytes
Redo Buffers                5840896 bytes
Database mounted.
SQL>

Alterado o banco para o modo archivelog:
SQL> alter database archivelog;
Database altered.

Abrindo o banco:
SQL> alter database open;
Database altered.

Verificando o estado do archive log:
SQL> archive log file;
SP2-0718: illegal ARCHIVE LOG option
SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     78
Next log sequence to archive   80
Current log sequence           80

Forçando a troca do archive log, com isso, podemos ver se já foi gerado o arquivo de archive log:
SQL> alter system switch logfile;
System altered.

Descobrindo a onde estão sendo salvos os archives logs:
SQL> show parameter DB_RECOVERY_FILE_DEST
NAME                                 TYPE        VALUE
———————————— ———– ——————————
db_recovery_file_dest                string      $ORACLE_BASE/flash_recovery_area
db_recovery_file_dest_size           big integer 2G

Agora podemos verificar se foi gerado o archivelog, com o comando pwd mostro o diretório corrente e com o ls eu listo os arquivos da pasta:
[oracle@oracle11g 2011_07_13]$ pwd
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_07_13
[oracle@oracle11g 2011_07_13]$ ls -lah
total 22M
drwxr-x— 2 oracle oinstall 4.0K Jul 13 10:08 .
drwxr-x— 3 oracle oinstall 4.0K Jul 13 09:59 ..
-rw-r—– 1 oracle oinstall 21M Jul 13 09:59 o1_mf_1_80_71v96hr3_.arc
-rw-r—– 1 oracle oinstall 978K Jul 13 10:08 o1_mf_1_81_71v9pr0h_.arc

Algumas views importantes para informações do archive log:
ViewsDescrição
V$DATABASEMostra se a base de dados esta em ARCHIVELOG ou NOARCHIVELOG
V$ARCHIVED_LOGExibe historico dos ARCHIVELOGS do CONTROL FILES. Se você usar um catálogo de recuperação, a view RC_ARCHIVED_LOG contém informações semelhantes.
V$ARCHIVE_DESTDescreve o estado atual da instância, todos os destinos dos archives e o tamanho atual.
V$ARCHIVE_PROCESSESExibe informações sobre o estado dos processos de arquivo diferentes para uma instância.
V$BACKUP_REDOLOGContém informações sobre todos os backups dos archived logs. Se você usa o recovery catalog, o RC_BACKUP_REDOLOG contém informações similares.
V$LOGExibe todos os grupos de redo log para o banco de dados e indica que precisam ser arquivados.
V$LOG_HISTORYContém informações de logs registros, que marca os archives com o range de SCN, para cada archive log.

Gerenciando tablespaces no Oracle 11g


Um banco de dados é armazenado logicamente em uma ou mais tablespaces que, por sua vez, é armazenada fisicamente no disco em um ou mais arquivos para cada tablespace. Devemos ser capazes de alocar corretamente os arquivos, ter controle do crescimento e saber quando agir. Você sabe onde estão os seus tablespaces ? Sabe o tamanho deles ? Eles estão no mesmo disco ? Enfim, pretendo fazer dois artigos com informações de gerenciamento de tablespace no banco de dados Oracle.
É de grande importância que as tablespaces estejam em discos diferentes, que tenha algum método de RAID e/ou melhor, que seja gerenciado pelo ASM (Automatic Storage Management), assim podemos garantir garantir um alto nível de desempenho, disponibilidade e facilidade de recuperação. Entretanto, devemos distribuir em vários discos seus arquivos de dados, mantendo cópias espelhadas dos archive logs e control files.
Smallfile X Bigfile
A partir da versão do 10g, é possível criar um tipo de tablespace, chamada bigfile. Essa novidade também se aplica no Oracle 11g. Com esse novo recurso, podemos criar um arquivo de dados de terabytes, utilizando a opção bigfile. A tablespace bigfile, contém somente um arquivo de datafile ou um tempfile, que contém aproximadamente 4 bilhões de blocks. O tamanho máximo de um único datafile ou temfile é de 128 terabytes, para uma tablespace de 32k de blocos e 32TB para uma tablespace com 8k blocos.
Já a tablespace smallfile é padrão, que pode contém 1022 datafiles ou tempfiles, cada uma podendo ter aproximadamente 4 milhões de blocos.
Como no próprio site da Oracle, existe algumas restrições na criação do bigfile, as mais importantes são: Você só pode especificar apenas um datafile na cláusula DATAFILE e/ou na TEMPFILE, Você também não pode especificar EXTENT MANAGEMENT DICTIONARY.

Vamos começar verificando quantos tablespace temos nesta instância:
SQL> select * from v$tablespace;
TS#   NAME            INC BIG FLA ENC
0    SYSTEM            YES NO YES
1     SYSAUX            YES NO YES
2    UNDOTBS1       YES NO YES
4    USERS               YES NO YES
3     TEMP                NO NO YES
6     EXAMPLE        YES NO YES
6 rows selected.

Com este select, podemos dizer que temos 7 tablespace, que seis são tablespace permanentes e uma do tipo temporária (TEMP).
Ao criar um tablespace, me deparei com a mensagem de erro:
SQL> create tablespace william;
create tablespace william
*
ERROR at line 1:
ORA-02199: missing DATAFILE/TEMPFILE clause

O erro ocorre porque não definimos nada no parmetro: db_create_file_dest. Para verificar se tem algo setado, use este select:
SQL> show parameter file_dest
NAME                                                      TYPE        VALUE
—————————————— ———– ——————————
audit_file_dest                                       string            /u01/app/oracle/admin/orcl/adump
db_create_file_dest                              string
db_recovery_file_dest                         string             $ORACLE_BASE/flash_recovery_area
db_recovery_file_dest_size                big integer    2G
SQL>

Para setar este parâmetro, rodamos um alter system set, segue exemplo abaixo.
SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST=’/u01/app/oracle/oradata/orcl’ SCOPE=BOTH;
System altered.

Com isso, definidos que o caminho de qualquer tablespace default, será criada nesta pasta acima e o parâmetro SCOPE, aplica a configuração no ambiente atual, sem a necessidade de parar o banco e iniciar novamente, também já configura este parâmetro no arquivo do SPFILE. Tentamos criar novamente a tablespace:
SQL> create tablespace william;
Tablespace created.

Verificando onde a tablespace foi criada:
SQL> select tablespace_name, name, status, bytes/1024/1024 “Megas”
FROM V$DATAFILE_HEADER;
Space usage report by Tablespace
TABLESPACE_NAME NAME                                                                         STATUS      Megas
SYSTEM        /u01/app/oracle/oradata/orcl/system01.dbf                       ONLINE      730.0
SYSAUX        /u01/app/oracle/oradata/orcl/sysaux01.dbf                         ONLINE      640.0
UNDOTBS1     /u01/app/oracle/oradata/orcl/undotbs01.dbf                  ONLINE      100.0
USERS        /u01/app/oracle/oradata/orcl/users01.dbf                             ONLINE        6.3
EXAMPLE        /u01/app/oracle/oradata/orcl/example01.dbf                 ONLINE      100.0
WILL        ../../../orcl/ORCL/datafile/o1_mf_william_73ccjo34_.dbf    ONLINE      100.0
Renomeando uma tablspace, Lembrando que você não pode renomear tablespace do system, sysaux e tablespace offline:
SQL> alter tablespace william rename to will;
Tablespace altered.

Redimensionando tablespaces, com alter database, dimunuindo de 100m para 50m:
SQL> alter database
datafile ‘/u01/app/oracle/oradata/orcl/ORCL/datafile/o1_mf_william_73ccjo34_.dbf’
resize 50m;
Database altered.

Reduzindo para 1k:
SQL> alter database
datafile ‘/u01/app/oracle/oradata/orcl/ORCL/datafile/o1_mf_william_73ccjo34_.dbf’
resize 1k
ERROR at line 1:ORA-03214: File Size specified is smaller than minimum required

Com esse erro, percebemos que não podemos reduzir muito, porque já contém dados no arquivo, que estão usando este espaço. Abaixo, mostro também que se aumentarmos mais do que temos no Sistema operacional, pode dar erro também:
SQL> alter database
datafile ‘/u01/app/oracle/oradata/orcl/ORCL/datafile/o1_mf_william_73ccjo34_.dbf’
resize 1t;
alter database datafile ‘/u01/app/oracle/oradata/orcl/ORCL/datafile/o1_mf_william_73ccjo34_.dbf’ resize 1t
ERROR at line 1:
ORA-01144: File size (134217728 blocks) exceeds maximum of 4194303 blocks

Criando uma tablespace, com um tamanho de 100megas, que irá crescer em 50 a 50 megas, até completar 20gigas.
SQL> CREATE tablespace wiliam datafile ‘/u01/app/oracle/oradata/orcl/william.dbf’
size 100m
autoextend on
next 50m
maxsize 20g;
Tablespace created.