SELECT db_name(DBID), datediff(dd, BackupStartTime, getdate())
    FROM monOpenDatabases

Wann ist das letzte Backup für eine bestimmte Datenbank gelaufen?

SELECT db_name(DBID), datediff(dd, BackupStartTime, getdate())
    FROM monOpenDatabases
    WHERE DBID = <number>

Folgende MDA Tabellen können als historische Tabellen angesehen werden.

• monSysSQLText
• monSysPlanText
• monSysStatement
• monErrorLog
• monDeadLock

Arbeitsweisen der historischen MDA Tabellen

Die historischen MDA Tabellen beinhalten Aufzeichnungen von ASE "Events" wie beispielsweise SQL STatements, Error Messages oder Deadlogs. Die Daten werden im Memory in so genannten "fixed-sized arrays" gespeichert. Die Speichergröße wird mit sp_configure festgelegt. Dabei sind die Daten "transient" und werden in “Ring buffers” verwaltet. Sobald der "Ring" voll geschrieben ist, wird der älteste Wert des "Rings" überschrieben. Historische Tabellen sind “stateful". Das bedeutet das der ASE einmal abgefragte Werte in der aktuellen Session nicht wieder anzeigt. Eine weitere Abfrage der selben MDA Tabelle wird in der aktuellen Session lediglich neue Daten anzeigen.

Config Parameter der "historical MDA tables"

Folgende sp_configure Parameter legen die "number of rows" in den "historical tables" fest.

• errorlog pipe max messages
• plan text pipe max messages
• sql text pipe max messages
• statement pipe max messages
• deadlock pipe max messages

Der Wert des Parameters ist die "number of rows" pro engine. Dabei gilt: Errorlog und Deadlock Pipes sind i. A. deutlich kleiner als "plan text", "sql text" und "statement pipes".

Tipps und Hinweise für "historical MDA tables"

Grundsätzlich sollten man auf den MDA Tabellen keine Subqueries oder Joins ausgeführt werden (Stichwort "transient" Counter). Stattdessen sollte man den Inhalt der MDA Tabellen in
Archivtabellen schreiben und daruf die Subqueries und Joins ausführen. Es empfiehlt sich, dass die Daten auf regelmäßiger Basis gesammelt werden, um keine Daten zu verlieren.

cumulative Counter

"cumulative" bedeutet, der Counter erhöt sich, bis der Maximalwert erreicht ist. Die meisten Counter Types sind "cumulative" und können einen Höchstwert von 2.147.483.647 annehmen. Ist der Höchstwert erreicht, wird der Counter zurück auf "0" gesetzt.

transient Counter
"transient" bedeutet, die Angezeigte Werte werden nach der Anfrage in der aktuellen Session nicht mehr angezeigt oder die Daten ändern sich schnell. Um sie nochmals Abfragen zu können, muss man sich entweder von der Session ab- und wieder anmelden oder die Werte in eine temporäre Tabelle schreiben.

Identifizieren von Countertypen der monTables Spalten

cumulative Countertypen ermitteln

SELECT TableName, ColumnName
  FROM monTableColumns
     WHERE (Indicators &1) = 1

transiente Countertypen ermitteln

SELECT TableName, ColumnName
  FROM monTableColumns
     WHERE (Indicators &2) = 2

SELECT s.SPID, s.CpuTime, t.SQLText
FROM monProcessStatement s, monProcessSQLText t
WHERE s.CpuTime = (SELECT MAX(CpuTime) FROM monProcessStatement)
AND s.SPID = t.SPID

Wenn ein leeres Resultset ausgegeben werden, dann die Query nochmals ausführen.

sp_configure "pipe"
go
Configuration OPTION IS NOT UNIQUE.
 
 Parameter Name                 DEFAULT     Memory Used Config Value Run Value    Unit                 Type
 ------------------------------ ----------- ----------- ------------ ------------ -------------------- ----------
 deadlock pipe active                     0           0            0            0 switch               dynamic
 deadlock pipe max messages               0           0            0            0 number               dynamic
 errorlog pipe active                     0           0            0            0 switch               dynamic
 errorlog pipe max messages               0           0            0            0 number               dynamic
 plan text pipe active                    0           0            0            0 switch               dynamic
 plan text pipe max messages              0           0            0            0 number               dynamic
 sql text pipe active                     0           0            0            0 switch               dynamic
 sql text pipe max messages               0           0            0            0 number               dynamic
 statement pipe active                    0           0            0            0 switch               dynamic
 statement pipe max messages              0           0            0            0 number               dynamic    
 
(1 row affected)
(RETURN STATUS = 1)

SELECT ParameterName, TypeName FROM monTableParameters WHERE TableName = "monOpenObjectActivity"

Gelegentlich kommt es vor, dass Anwendungen schneller wachsen als erwartet. Im allgemeinen werden dann neue Devices eingehängt, so dass irgendwann der IQ sehr viele Devices verwalten muss. Das kann zu performance Engpässen kommen. Denn der IQ öffnet für jedes Device so genannte Threads, die dann auch entsprechend verwaltet werden müssen. Läuft das Verhältnis zwischen Datenvolumen und Anzahl der Devices auseinander kommt es zu einem "Verwaltungsoverhead". Darum kann es sinnvoll sein von kleinen Devices auf größere "umzuziehen". Dabei hilft die System-Stored Prozedure sp_iqrelocate.

Die einzelnen Schritte für ein Relocate

1. Check DBSPACEs
Noch im laufenden Betrieb können die neuen Devices eingehängt werden. Anschließend evtl. den Datenbankplatz mit sp_iqdbspace prüfen.

2. DBSPACE Status ändern
Damit keine Daten mehr auf die "alten" Devices geschrieben werden wird nun deren Status geändert. Das wird mit alter dbspace 'Name_of_IQ_MAIN_SPACE' relocate gemacht. Der Status ändert sich dann auf RO (readonly) und kann wieder mit sp_iqdbspace überprüft werden.

3. Daten mit sp_iqrelocate verschieben
Um die Daten erfolgreich verschieben zu können muss nun sichergestellt wrden, dass keine user mehr auf die Datenbank zugreifen. das kann beispielsweise mit einem Neustart des IQs mit der Startoption (Switch) -gm 1 gemacht werden. Damit kann sich nur ein User einlogen. Oder der IQ wird mit einem neuen Namen und auf einem neuen Port restartet.

Wenn Der IQ gegen unerwünschte Benutzerzugriffe gesichert ist kann der Behfehl sp_iqrelocate database abgesetzt werden. Je nach Anzahl der zu verschiebenden Devices und der Datenmenge kann das einige Zeit in Anspruch nehmen. Ist das Relocate durchgelaufen, muss man evtl. mehrmals commit ausführen.

Der Output von sp_iqrelocate zeigt dann die Objekte und die Anzahl der "relocierten" Blocks an und sieht dann etwa so aus:

(DBA)> sp_iqrelocate DATABASE
Execution time: 42.004 seconds
Object                                          Blocks Relocated STATUS
--------------------------------------------------------------------------
rmdb_dbo.LGDS2_BI_ACCOUNT.ASIQ_IDX_T1707_C1_FP  0                no relocs
rmdb_dbo.LGDS2_BI_ACCOUNT.ASIQ_IDX_T1707_I63_HG 0                no relocs
rmdb_dbo.LGDS2_BI_ACCOUNT.ASIQ_IDX_T1707_C2_FP  0                no relocs
rmdb_dbo.LGDS2_BI_ACCOUNT.ASIQ_IDX_T1707_C3_FP  0                no relocs
rmdb_dbo.LGDS2_BI_ACCOUNT.ASIQ_IDX_T1707_C4_FP  0                no relocs
rmdb_dbo.LGDS2_BI_ACCOUNT.ASIQ_IDX_T1707_C5_FP  0                no relocs
rmdb_dbo.LGDS2_BI_ACCOUNT.ASIQ_IDX_T1707_C6_FP  0                no relocs
rmdb_dbo.LGDS2_BI_ACCOUNT.ASIQ_IDX_T1707_C7_FP  0                no relocs
rmdb_dbo.LGDS2_BI_ACCOUNT.ASIQ_IDX_T1707_C8_FP  0                no relocs
...

4. Drop DBSPACE
Ist alles OK, können die "alten" Devices gedropt werden. Das entsprechende Kommando heißt: drop dbspace 'Name_of_IQ_MAIN_SPACE'. Der Vorgang sollte nur wenige Sekunden dauern. Anschließend kann der IQ wieder für Benutzer frei gegeben werden.

Ab IQ 15.0 kommt ein zweiter Layer zu den Datenspeichern hinzu; Das dbfile. Dementsprechend können einem DBSPACE dbfiles hinzugefügt werden. Die dbfiles können ähnlich behandelt werden, wie im IQ 12.7 die DBSPACES. Das Kommando heißt nun nicht mehr sp_iqrelocate sondern sp_iqemptyfile. Objekte auf einem DBSPACE können aber nicht verschoben werden, sie müssen gelöscht werden.

Das IQ_SYSTEM_MAIN kann auch per sp_iqrelocate verschoben werden. Davon kann aber nur abgeraten werden, denn das IQ_SYSTEM_MAIN wird insbesondere beim Aufbau eines Multiplex und später für den Upgrade auf IQ 15 benötigt. Wenn das Device nicht mehr vorhanden ist, können Probleme mit den von Sybase gelieferten Tools (z.B. iqunlad) auftreten.

IQ 12.7

sp_iqaddlogin ‘userid’, ‘password’, [ number_of_connections ] [ , password_expiration ]

IQ 15

sp_iqaddlogin ‘username_in’, ‘pwd’, [ ’password_expiry_on_next_login ’] [ , ’policy_name’]

Was ist gelich bzw. unterschiedlich

• 'username_in' = 'userid'
• ’password_expiry_on_next_login’ != 'password_expiration'
• ’policy_name’

’password_expiry_on_next_login’ muss entweder "OFF" oder "ON" sein,
z.B. sp_iqaddlogin 'username', 'password', 'ON' ’password_expiry_on_next_login’ ist standardmäßig "OFF", d.h. das Passwort bleibt immer gültig.

Die Login Policy definiert number_of_connections, locked, password_life_time, u.s.w.

Bei IQ 15 wird jede Datenbank mit der so genannten "root policy" angelegt. Das ist die "default login policy". Sie kann modifiziert aber nicht entfernt werden. Wenn die "login policy" beim Anlegen eines Accounts nicht definiert wird, so greift automatisch die "root policy".

Sonderzeichen
Im IQ 12.7 konnten zahlreiche Sonderzeichen im Passwort verwendet werden. Im IQ 15 so sind folgende Zeichen zur Zeit nicht mehr möglich:

• +
• %
• =
• !

Darüber hinaus können Passwörter nicht mehr mit Zahlen beginnen. Ein "3Rdg6zT7t" als Passwort wirft eine Fehlermeldung.

1> sp_iqaddlogin 'username', '4password'
2> go
Msg 102, Level 15, State 0:
SQL Anywhere Error -131: Syntax error near '4' ON line 1

Hier die IQ Version auf der die Test gemacht wurden:

(DBA)> SELECT @@version
@@version
-------------------------------------------------------------------------------
Sybase IQ/15.1.0.5034/090925/P/ESD 1/Sun_Sparc/OS 5.10/64bit/2009-09-25 04:28:41

60x (Anzahl der ersten 4 CPUS) + (50x restliche CPUs) + 2x (numConnections +2) +1 = numThreads