Compactar taules per optimitzar MySQL

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:

 

Bases de Dades Express. Una manera de començar amb les grans.

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.

SQL08: affinity_mask, io_affinity_mask i com muntar dos entorns en un mateix servidor sense que es "trepitgin"

Ens posem en situació
En el nostre entorn és possible que necessitem disposar de dos rèpliques d'una/s base de dades en entorns diferenciats (el clàssic exemple seria producció i test). Per decidir com ho fem les preguntes més comuns que ens hem de fer són:

- Aquest nou entorn serà temporal? Conté bases de dades gran en quant a volum i / o la càrrega que ha de suportar és elevada (encara que sigui test)?
- Disposo de la versió de desenvolupament de SqlServer2008? Que només està al teu abast si tens una subscripció MSDN ...
- Disposo d'un servidor addicional?

En base a aquestes preguntes i totes les que se li puguin a un ocórrer es pot optar per diferents solucions:
-El més senzill i si la base de dades més la càrrega a suportar són petites podem utilitzar el mateix servidor per a totes les bases de dades (vam crear en el mateix servidor amb noms diferents (_Test) i Santes pasqües ...). Perquè no es molestin entre si podem utilitzar Resource Governor.

Oracle10g: Canviar el joc de caràcters de la base de dades

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;

Oracle10g: Manual standby database (plantejament inicial)

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.

SQL08: Actualització estadístiques de taula de forma dinàmica en tota una base de dades

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.

Exportar fàcilment dades d'Oracle a un fitxer pla

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&gt; SET HEADING OFF
SQL&gt; SET FEEDBACK OFF
SQL&gt; SPOOL C:\datos_de_clientes.txt
SQL&gt; SELECT 'Cliente ' || CLI_NOMBRE || ', ' || CLI_NIF || '. Fecha alta: ' || TO_CHAR(CLI_FECHAALTA,'YYYY-MM-DD')
     FROM TABLA_CLIENTES
     ORDER BY CLI_FECHAALTA DESC;
SQL&gt; SPOOL OFF;
SQL&gt; SET FEEDBACK ON
SQL&gt; SET HEADING ON

Les 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.

Oracle 10g: Possible optimització de bolcat massiu de dades

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)