blog de il_masacratore

SQL08: Create table condicionat usant el diccionari de dades de Sql Server

0

En certes ocasions necessitem comprovar l'existència d'una taula en un script o tasca programada per a poder registrar esdeveniments de errors, primeres execucions etc ... Posem un exemple, un paquet de integration services que solem distribuir o executar allà a on anem i que deixa traces en un taula personalitzada que no és la omissió per als logs de càrrega. Podríem incloure sempre una tasca d'execució sql o d'script, que s'executi bé o malament, sigui la primera a executar-se en el paquet i després continue. Sent puristes això només no és del tot "prolix":

 CREATE TABLE LogsEtl
(Execució int PRIMARY KEY,
Paquet varchar (50),
Data datetime);
GO 

A la primera execució la sortida serà correcta però en posteriors fallarà en la creació de la taula.Això ho podem suplir consultant la vista sys.Objects , on hi ha un registre per cada objecte de la base de dades, i comprovar l'existència de la taula abans de crear-la. La visibilitat de les metadades es limita als elements protegibles i que són propietat de l'usuari o sobre els quals l'usuari té algun permís.

SSRs: # Error en una cel d'import decimal d'informe que tira d'Oracle

0

Fins ara desconec exactament com o on es detalla cada tipus d'error en l'execució d'un informe de reporting services. He tractat amb derivats de manca de permisos, processats incomplets de cubs però fins ara cap # Error en una cel perquè si.

L'error en qüestió m'apareix en l'execució d'un petit informe que tira d'un origen de dades ODBC contra una base de dades Oracle on es mostren totals (sumes, no percentatges) i m'ha sorprès molt la manca de detall sobre l'error que es produeix. Per a més dificultat, a sobre és en una combinació de paràmetres concreta (les n execucions anteriors han funcionat) i no en tota la columna sinó en una cel.A més arrossega tot subtotal o total en què s'inclogui ...

Després de mirar el log del servidor de RS, després de comprovar la consulta en un client extern amb la mateixa, després de pensar malament del format em donar per comprovar en el dissenyador d'informes l'origen de dades em faig una prova amb paràmetres a la babalà i bé però al posar els valors problemàtics si que almenys aparegui l'error:

Error en llegir dades del conjunt de resultats de la consulta.

Ora10g: ORA-00060 Deadlock detected (II)

0

Seguint amb el post anterior crec necessari comentar que hi ha altres tipus de bloqueig que es produeixen per un disseny conflictiu que s'uneix a les peculiaritats de oracle.

Deixo primer la traça d'exemple:

 *** ACTION NAME: () 2011.04.21 14:08:01.227
*** MODULE NAME: (MiPrograma.exe) 2011.04.21 14:08:01.227
*** SERVICE NAME: (SYS $ USERS) 2011.04.21 14:08:01.227
*** CLIENT ID: () 2011.04.21 14:08:01.227
*** SESSION ID: (1636.58026) 2011.04.21 14:08:01.227
Deadlock detectar (ORA-00060)
[Transaction Deadlock]
The following deadlock is not an ORACLE error.It is a deadlock due to user error in the design of an application or from issuing Incorrect ad-hoc SQL.

MySql: Controlar i reduir la fragmentació de taules consultant information_schema

0

La fragmentació té lloc sobretot en taules on hi ha molt moviment insert / delete. Aquest creix molt quan el volum de dades de la taula és molt variable en el temps: per exemple en taules de control de transaccions, de Logue d'usuaris, de taules intermèdies, etc. El primer símptoma de fragmentació seria lentitud en les consultes, principalment perceptible en taules amb molts registres. Per conèixer informació sobre això podem consultant la vista information_schema.tables on podem veure ràpidament l'estat de les taules i algunes dades interessants de les mateixes.

MySql: Trigger de connexió per auditoria de connexions

0

En mysql els triggers que existeixen són bàsics i només a nivell de taula. No hi ha com en SqlServer o Oracle un trigger que permeti caçar les connexions que s'obren i obtenir certa informació complementària referent a les sessions.
Un mal exemple. Es pot donar el cas que en un entorn web tinguem un granja de servidors apache i pel que sigui a algú se li va l'olla. Comença a obrir threads en el nostre mysql de forma massiva (pel motiu que sigui) i ens col.lapsa el servidor perquè no tenim limitades el nombre de connexions simultànies per a aquest usuari. Que mal rotllo no? I si a sobre això passa quan no estem a l'oficina ens podem trobar que no podem saber molt del que ha passat, per exemple veiem el pic en cacti però no tenim detall.

Per tenir una mica més i poder auditar quan i qui obre connexions, farem el següent:

  1. Creem schema un esquema (o no).

    create schema auditoria;
    utilitzeu auditoria;

  2. Creem dins la taula on emmagatzemar dades.
    CREATE TABLE aud_conexiones (
    id BIGINT unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY
    , Thread_id INT unsigned NOT NULL DEFAULT 0
    , Usuari VARCHAR (64) NOT NULL DEFAULT 'unknown'
    , Login_ts TIMESTAMP NULL DEFAULT NULL);
  3. Crearem un procedure que inseriu les dades de la sessió.
Contingut sindicat