Alguna vegada us heu preguntat com desactivar el autocommit al Management Studio de Sql Server? Doncs la resposta és ràpida. El podeu canviar activant al menú Eines> Opcions> Execució de la consulta> SQL Server> Ansi> SET IMPLICIT_TRANSACTIONS.
Sembla una mica simple però com m'ho han preguntat un parell de vegades ...
Amb MySQL, quan s'eliminen registres d'una taula, l'espai no es reassignació automàticament. Queda com a espai buit que es realitzen noves insercions es va aprofitant.
El problema d'això és que si en una taula es realitzen moltes operacions de DELETE, l'espai físic de la taula va quedant cada vegada més fragmentat i el rendiment es redueix.
En els motors MyISAM i InnoDB de MySQL, disposem de la comanda OPTIMITZAR TABLE per poder realitzar sobre qualsevol taula una optimització que, entre altres coses, fa una defragmentació automàtica de la taula.
És molt recomanable utilitzar aquesta comanda regularment sobretot sobre les taules que reben més sentències d'eliminació de registres.
Com a precaució, tenir en compte que durant la seva execució, com és lògic, la taula queda bloquejada. Cal acordar quan ho anem a utilitzar amb taules grans i amb molt moviment.
La sintaxi és supersimple:
En una entrada anterior del bloc (Bases de Dades OpenSource. Per què escollim Mysql per al nostre projecte?), parlem de les bases de dades Open Source com a opció interessant i fiable per al desenvolupament de projectes de Business Intelligence. Vam veure diferents productes i algunes comparatives entre ells.
Pot passar que després d'instal lar Oracle o configurar una nova base de dades ens adonem que el joc de caràcters escollit durant la instalació no és el correcte. El que se'ns pot passar en casos com aquest és esborrar la base de dades i reconfigurar o coses pitjors ... Però no cal. Podem canviar el joc de caràcters parant la base de dades, aixecant de manera restrictiva, canviant la configuració i reiniciat la base de dades. Howto:
- Primer ens connectem amb la base de dades
$ sqlplus sys/pwd@prod as sysdba
- Aturem la base de dades
SQL>SHUTDOWN IMMEDIATE;
- Aixequem de forma restrictiva *
SQL>STARTUP MOUNT;
SQL>ALTER SYSTEM ENABLE RESTRICTED SESSION;
SQL>ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
SQL>ALTER DATABASE OPEN;
- Canviem el mapa de caràcters
SQL>ALTER DATABASE CHARACTER SET <nou mapa de caràcters>;
- Reiniciem la base de dades i yata
SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP;
Una base de dades Oracle en Standby és una còpia exacta d'una base de dades operativa en un servidor remot, usada com a backup, com a còpia per a consulta, recuperació de desastres, etc.
Una base de dades en mode Standby és més que un backup normal ja que es pot posar en producció en cas de desastre en un temps menor que si haguessim de restaurar una còpia (ja sigui des de rman o un simple exportació). Restaurar una còpia des de fitxer triga temps, i durant aquest període el sistema no està disponible. Amb una base de dades addicional en mode standby no hi ha res (o gairebé res de restaurar) en cas de desastre. En qüestió de minuts es fa el canvi permetent continuïtat en el servei.No ens ofereix els avantatges de rendiment d'un cluster o la seguretat del mirall però la relació de costos de temps i llicència versus avantatges em sembla correcta.
Des d'un punt de vista global:
-Disposem d'una còpia de la base de dades de forma remota, que podem comptabilitzar com a segon joc de còpies.
-A diferència d'un simple backup, la còpia es manté viva i les dades són actualitzats amb més freqüència.
Igual que en Oracle hi ha una taula on es llisten totes les taules de la base de dades (dba_tables) i podem utilitzar per realitzar operacions de manteniment de forma dinàmica, en Sql Server podem fer el mateix consultant la taula [basededades].dbo.sysobjects.
En l'exemple inferior (com en altres que he penjat) actualitzo les estadístiques de totes les taules d'una base de dades de Sql Server de forma dinàmica consultant el diccionari de dades. Aquest es podria encapsular en un stored procedure o directament executar en un job l'Agent de Sql Server per mantenir actualitzades les estadístiques de totes les taules d'una base de dades de forma automàtica.
Una manera molt simple d'exportar dades d'una consulta, taula, etc. d'una base de dades oracle a un fitxer pla és utilitzar la comanda SPOOL de SQLPlus. D'aquesta manera no cal dependre d'eines visuals, que no sempre estan disponibles, o no sempre funcionen com volem. A més es poden utilitzar les funcions de format d'Oracle en la mateixa sentència SELECT perquè les dades es generin ja en el format que necessitem.
Si, per exemple, volem recuperar algunes dades de tots els registres d'una taula de clients ordenats per data d'alta, només cal obrir una sessió de SQLPlus i executar aquesta sèrie de comandes:
SQL> SET HEADING OFF
SQL> SET FEEDBACK OFF
SQL> SPOOL C:\datos_de_clientes.txt
SQL> SELECT 'Cliente ' || CLI_NOMBRE || ', ' || CLI_NIF || '. Fecha alta: ' || TO_CHAR(CLI_FECHAALTA,'YYYY-MM-DD')
FROM TABLA_CLIENTES
ORDER BY CLI_FECHAALTA DESC;
SQL> SPOOL OFF;
SQL> SET FEEDBACK ON
SQL> SET HEADING ONLes primeres línies amaguen les capçaleres que contindrien el nom dels camps, i no ens interessen perquè nosaltres només volem les dades. Spool dirigeix la sortida de dades cap al fitxer 'datos_de_clientes.txt' de la unitat C de la nostra màquina local.
En execucions batch que facin un bolcat massiu de dades en una mateixa taula utilitzant un insert o update per registre dins d'un bloc pel motiu x es poden optimitzar amb l'ús de paràmetres (si el client ho permet) o si fem servir odbc amb bind variables.
Recordem els passos que segueix Oracle per processar una consulta:
1) Validació Sintáctica
2) Validació Semàntica
3) Optimització
4) Generació del QEP (Query Execution Pla)
5) Execució del QEP (Query Execution Pla)
Aquesta obra està subjecta a una Llicència de Creative Commons.