En SQL Server es pot utilitzar l'ordre DBCC SHRINKDATABASE per reduir l'espai ocupat pels arxius de dades i de log. El problema de SHRINKDATABASE és que, al contrari del que pugui semblar, si no s'utilitza be, pot donar com a resultat un important increment en la fragmentació dels índexs, i de les taules, cosa que deriva en un empitjorament del rendiment de la nostra base de dades..
En molts casos ocorre que per algun motiu canviem el nom de host en el nostre sistema operatiu, si aquest és el cas ia més comptem amb una instal lació de DB2 09/07 ESE i el sistema operatiu és Windows XP, la forma que la nostra instància DB2 arrencar correctament és:
Suposem que el nom antic és OLDNAME i el nou és NEWNAME..
Trucant a l'API de Twitter des procediments emmagatzemats de PL / SQL es poden enviar actualitzacions d'estat a un compte de Twitter. A part del curiós que pugui resultar, pot ser un mètode molt eficaç per a avisar-nos a nosaltres o als nostres usuaris sobre qualsevol esdeveniment que es produeixi a la base de dades.
Podem convertir Twitter fàcilment en un sistema d'alertes addicional per quan tinguem problemes a la nostra base de dades Oracle, o simplement si volem assabentar-nos o informar els altres de manera automàtica sobre la finalització de determinats processos, com ara les càrregues del Data Warehouse corporatiu .
Recordem que els comptes de Twitter es poden configurar de manera que estiguin obertes a qualsevol usuari, o es poden protegir perquè només accedeixin els usuaris de Twitter als que s'atorgui permís per a 'seguir'.
En MySQL esisteix un paràmetre que habilita el registre de les consultes que triguen més de x segons a executar-se, les anomenades Slow Queries. Bàsicament el que fa és ficar-les en un fitxer de log per després consultar-ho amb mysqldumpslow. Aquest mecanisme ens pot ser útil per millorar el rendiment global de la base de dades si reduïm el valor de forma progressiva per als temps d'execució "no admesos" abans de declarar una consulta com "lenta" o slow query...
A continuació deixo un petit post de com muntar un sistema automàtic de notificació via mail que ens indiqui quin és l'estat de la nostra base de dades. Per exemple el podem programar una mica abans de començar la nostra jornada laboral i abans de marxar o mentre estem de vacances (jaja. ..). Aquest exemple és sobre un Mysql 5.X corrent a Debian. Passos que segueix...
Segur que a tots els que treballeu amb Oracle (o amb Sap i com a base de dades Oracle com és el meu cas), us ha sorgit la necessitat de replicar una base de dades productiva (o d'un entorn de proves), en un altre sistema. En el meu cas, treballant amb Sap, regularment realitzar una còpia de la base de dades real en el sistema de desenvolupament (integració), perquè la proves dels canvis, desenvolupaments o parametritzacions siguin el més completes possibles (i el més fàcils possible de cara a l'usuari si disposa de les dades "reals" més actualitzats)...
La manera archivelog d'una base de dades Oracle protegeix contra la pèrdua de dades quan es produeix una fallada en el medi físic i és el primer pas per poder fer còpies de seguretat (en calent!!) Amb rman. Per posar la base de dades en mode archivelog (sense utilitzar la flash recovery àrea) hem de fer bàsicament dues coses, afegir dos paràmetres nous al fitxer de configuració, reiniciar la base de dades i canviar la manera treball a archivelog.
Com posar la base de dades Oracle 10g en mode archivelog
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:
MySQL, igual que la majoria de gestors de bases de dades, permet modificar fàcilment els seus paràmetres que controlen mides de memòria dedicats a determinades tasques, utilització de recursos, límits de concurrència, etc.
Ajustant adequadament aquests paràmetres es poden obtenir moltes millores de rendiment, sobretot si el servidor / s de la base de dades no va sobrat de recursos, i si per la part d'optimització SQL no es pot millorar molt més.
Jo fa poc he fet alguns ajustaments bàsics en una base de dades MySQL, així que vaig aprofitar per explicar una mica el procés que he seguit per a qui busqui una manera senzilla de fer una primera optimització de paràmetres a la base de dades. Amb això no vull dir que aquesta sigui la millor manera de fer-ho, només la que a mi m'ha resultat bé;)
El primer comentar que pot ser molt útil fer una ullada dins de phpMyAdmin a les seccions 'Mostra informació de temps d'execució de MySQL' i 'Mostra les variables del sistema MySQL', normalment accessibles des de la pàgina principal de l'aplicació.
Aquesta obra està subjecta a una Llicència de Creative Commons.