Aprendendo TI no dia-a-dia

sexta-feira, 22 de novembro de 2013

[Oracle] - Comandos de ARCHIVE LOG no SQL*PLUS

Para verificar se a base de dados está em modo de archive log, use os comandos abaixo para consulta no SQL*PLUS:

archive log list
archive log stop
archive log start
archive log next
archive log all
archive log n

[PostgreSQL] - Efetuando Backup

1) Backup de BD
# Comando de Backup dos BD
# -v VERBOSE DA CONEXÃO
# -o OIDS, ????????? PRECISA REALMENTE OU SÓ SE TIVER "lo" ??????
# -b "lo", BLOBS
# -i IGNORAR VERSAO
# -Z1 a Z9 COMPRIME O BACKUP, 0=MENOR, 9=MAIOR COMPRESSAO.
# -Fc TIPO DE ARQUIVO "c" CUSTOMIZADO PARA ARMAZENAR OS BLOBS
# -f ARQUIVO DE DESTINO
# -W SOLICITA SENHA PARA AUTENTICAÇÃO
pg_dump -h 127.0.0.1 -U postgres -W -v -o -b -i -Z9 -Fc -f "c:\dump\backup_zeus.sql" "zeus" 2> "c:\dump\backup_zeus.log"

# Comando de Backup dos BD
# --host INFORMA O HOST/SERVIDOR QUE IRÁ CONECTAR
# --port INFORMA A PORTA UTILIZADA PELO HOST/SERVIDOR
# --username INFORMA USUÁRIO UTILIZADO PARA O BACKUP
# --ignore-version IGNORA VERSAO
# --verbose VERBOSE DA CONEXÃO
# --file INFORMA LOCAL DE ARMAZENAMENTO DO BACKUP
# --blobs INFORMA QUE SERÁ FEITO BACKUP DE OBJETOS BINÁRIOS
# --format INFORMA O TIPO DE ARQUIVO PARA ARMAZENAMENTO DO BACKUP "t" COMPACTADO, "p" TEXTO PLANO, "c" CUSTOMIZADO
pg_dump --host=localhost --port=5432 --username=postgres -W --ignore-version --verbose --file="C:\dump\backup_zeus.sql" --blobs --format=c "zeus" 2> "c:\dump\backup_zeus.log"

2) Backup das Variaveis Globais (Permissoes, Usuarios e Grupos)
# Comando de Backup das Permissoes, Usuarios e Grupos
pg_dumpall -g -i -v -h 127.0.0.1 -U postgres -W > "c:\dump\backup_zeus_meta.sql" 2> "c:\dump\backup_zeus_meta.log"

[MySQL] - Habilitando acesso remoto ao servidor

Dica velha que de vez em quando é necessário relembrar, por isso vou deixar registrado aqui para não ter que ficar procurando no google sempre que precisar.

Executar todos os passos abaixo como root:

1 – Edite o arquivo:
/etc/mysql/my.cnf

2 – Altere a seguinte linha:
bind-address = 127.0.0.1
Deixando assim:
bind-address = 0.0.0.0

3 – Reinicie o Mysql
# /etc/init.d/mysql restart

4 – Vamos agora dar GRANT no usuário root, logue no mysql:
# mysql -u root -p

5 – Após se logar, digite o seguinte comando:
GRANT ALL ON *.* TO root@'%' IDENTIFIED BY 'sua_senha';

Dessa forma você libera o acesso ao seu servidor Mysql vindo de qualquer máquina externa, caso queira liberar somente o acesso da sua máquina, é só verificar qual é seu IP e entrar com o comando:

GRANT ALL ON *.* TO root@'192.168.0.2' IDENTIFIED BY 'sua_senha';

6. Após isso, basta dar uma reiniciada novamente no Mysql e realiazar a conexão remota.
# /etc/init.d/mysql restart

====================================================

Caso você queira desfazer o acesso remoto é bem simples também.

1 – Altere a seguinte linha:
bind-address = 0.0.0.0
Deixando assim:
bind-address = 127.0.0.1

2. Logue no Mysql:
# mysql -u root -p

3. Delete todos os privilégios remotos:
DELETE FROM mysql.user WHERE User = 'root' AND Host = '%';
FLUSH PRIVILEGES;

4. Reinicie o Mysql e pronto, não estará mais acessível remotamente.

Fonte:
http://jf.eti.br/habilitando-acesso-remoto-ao-servidor-mysql/

quinta-feira, 21 de novembro de 2013

[Oracle] - Alterando Tablespaces de tabelas e índices

A tarefa é trivial, mas não é algo que você faz todo dia. Então resolvi documentar aqui para facilitar a minha vida. Há várias formas diferentes de se rearranjar tablespaces. Com a popularização dos RAIDs, não é mais tão comum ficar dividindo tablespaces através de discos isolados, mas ainda assim, há bons motivos para você criar todos os objetos em apenas um tablespace:

O backup on-line pode ser feito um tablespace por vez, diminuindo a quantidade de logs gerados durante o backup;
Você pode transportar tablespaces entre bases (teste e produção por exemplo) sem ter que exportar e importar todos os dados;
Você pode utilizar diferentes parâmetros de storage, particionamento, etc;
Fica mais fácil monitorar o crescimento da base com várias aplicações se cada aplicação possuir suas próprias tablespaces;
Separar índices de tabelas ainda é uma boa política, especialmente porquê os índices podem ser reconstruídos e as tabelas não;
Objetos especiais como LOBs e dados estáticos são bons candidatos a terem seu próprio tablespace;

Assim sendo, é comum você pegar uma tabela que cresceu muito e alocar um tablespace só para ela e coisas do tipo. Particularmente, quando os desenvolvedores tem a liberdade de criar objetos no ambiente de testes (sim, isso é polêmico e fonte para outra conversa), é comum ter que ajustar os parâmetros de storage antes de colocar os objetos no ambiente de homologação ou produção. Seja qual for o motivo da movimentação, você terá que fazer a migração em 3 etapas:

Migrar tabelas com o comando:
ALTER TABLE nome_da_tabela MOVE TABLESPACE nome_do_novo_tablespace;

Migrar índices com o comando:
ALTER INDEX nome_do_indice REBUILD TABLESPACE nome_do_novo_tablespase;

Migrar LOBs com o comando:
ALTER TABLE nome_da_tabela MOVE LOB(nome_da_coluna_lob) STORE AS (nome_do_novo_tablespace);

Note tabelas que contem LOBs, possuem um índice que aparece na tabela DBA_INDEXES com data_type do tipo LOB. Se você tentar reconstruir estes índices em outro tablespace você terá um erro do tipo: “ORA-02327: cannot create index on expression with datatype LOB”. Por isso é importante a etapa de migração dos LOBs.

Segue aqui um script para fazer isso rapidamente num para todos objetos de um determinado esquema:

SELECT 'ALTER TABLE nome_do_esquema.' || table_name || ' MOVE TABLESPACE nome_do_novo_tablespace;' FROM dba_tables WHERE owner = 'nome_do_esquema'; SELECT 'ALTER INDEX nome_do_esquema.' || index_name || ' REBUILD TABLESPACE nome_do_novo_tablespace;' FROM dba_indexes WHERE owner = 'nome_do_esquema' AND index_type != 'LOB'; SELECT 'ALTER TABLE nome_do_esquema.' || table_name || ' MOVE LOB( ' || COLUMN_NAME || ' ) STORE AS (TABLESPACE nome_do_novo_tablespace);' FROM dba_tab_columns WHERE owner = 'nome_do_esquema' AND data_type LIKE '%LOB';

[PostgreSQL] - Movendo objetos no Postgres

Quando você cria um objeto seja ele uma tabela, visão, função, etc, a não ser que você especifique o contrário, ele vai ser criado no esquema ‘public’, no tablespace ‘pg_default’ e o dono do objeto será o ‘postgres’. Dependendo da aplicação, não há nenhum problema nisso. Sério, existem aplicações que funcionam muito bem com este arranjo padrão. Mas você pode querer organizar melhor os seus objetos em diferentes esquemas, pode querer melhorar a segurança e criar donos diferentes para os objetos e pode também querer armazenar seus objetos em discos ou partições diferentes.

Note no padrão ISO esquema e dono de objeto se confundem. Isto pode ou não ocorrer no PostgreSQL dependendo de como você organizar as coisas. Note que por padrão, a variável ‘search_path’ sempre aponta para ‘$user’, public’. Ou seja, se você criar um esquema com o nome de um usuário, os objetos vão ser sempre procurados neste esquema em primeiro lugar. Se não achar lá, vai procurar no esquema public.

Bom, por algum motivo você resolveu mudar as coisas… você pode se surpreender como é simples mudar um único objeto de lugar. Imagine uma tabela ‘foo’, uma sequência ‘foo_seq’ e uma visão ‘foo_vw’ que vão ser migrados para o esquema ‘bar’, usuário ‘bar’ e tablespace ‘novo_tablespace’:

Para mudar um objeto de esquema, basta utilizar o SET SCHEMA:
ALTER TABLE foo SET SCHEMA bar;

ALTER SEQUENCE foo_set SET SCHEMA bar;

ALTER VIEW foo_vw SET SCHEMA bar;

Para mudar o dono de um objeto, basta utilizar o OWNER TO
ALTER TABLE foo OWNER TO bar;

ALTER SEQUENCE foo_seq OWNER TO bar;

ALTER VIEW foo_vw OWNER TO bar;
Para mudar o tablespace de um objeto (no caso só se aplica para tabelas e índices, pois os demais objetos são armazenados apenas no catálogo):
ALTER TABLE foo SET TABLESPACE novo_tablespace; ALTER INDEX foo_idx SET TABLESPACE novo_tablespace;

Automatizando

Claro que se você quiser migrar um conjunto enorme de objetos, você vai querer automatizar um pouco este trabalho. Aqui vou demonstrar apenas um exemplo de migração de tabelas, sequências, visões e funções para um novo esquema. Você pode migrar outros objetos como tipos, domínios, agregações, extensões, tabelas externas, operadores e outros bichos avançados do Postgres. Aqui eu coloquei apenas os objetos mais utilizados para não complicar:

-- Script para mover tabelas, sequências, visões e funções do esquema 'PUBLIC' para o esquema 'bar'
-- Cria o esquema novo
CREATE SCHEMA AUTHORIZATION bar;
-- Os comandos \t e \o são interpretados apenas pelo psql.
-- São utilizados para exportar o resultado das consultas abaixo
\t
\o move.sql
SELECT 'ALTER TABLE ' || table_schema || '.' || table_name || ' SET SCHEMA bar;'
FROM information_schema.tables
WHERE table_schema = 'public'
ORDER BY table_name;

SELECT 'ALTER SEQUENCE ' || sequence_schema || '.' || sequence_name || ' SET SCHEMA bar;'
FROM information_schema.sequences
WHERE sequence_schema = 'public'
ORDER BY sequence_name;

SELECT 'ALTER VIEW ' || table_schema || '.' || table_name || ' SET SCHEMA bar;'
FROM information_schema.views
WHERE table_schema = 'public'
ORDER BY table_name;

SELECT 'ALTER FUNCTION ' || n.nspname || '.' || p.proname || ' (' || pg_catalog.pg_get_function_arguments(p.oid) || ') SET SCHEMA bar;'
FROM
pg_catalog.pg_proc p
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname = 'public'
ORDER BY p.proname;

\o
\t
-- O comando \i é interpretado pelo psql apenas.
-- Ele é utilizado para executar o script indicado.

\i move.sql

Navegando pelo psql

Os usuários do pgAdmin III muitas vezes ficam perdidos ao utilizarem o psql. Na verdade é mais fácil e rápido do que parece. Utilize os comandos \dn para ver os esquemas existentes na sua base, o \dp para ver as permissões nos objetos e o \db para ver os tablespaces.

Cuidado ao mover objetos grandes para um novo tablespace

Uma observação importante é que ao alterar o esquema e o dono de um objeto, apenas o registro no catálogo do sistema é alterado (mais especificamente na pg_catalog.pg_class). Então esta alteração é bem rápida. Para alterar o tablespace, além de alterar o catálogo, o postgres ainda tem de copiar o objeto fisicamente para o novo tablespace. Então, um objeto grande pode levar um bom tempo para mover.

Fonte:
http://savepoint.blog.br/movendo-objetos-no-postgres/

Páginas