SELECT s.WaitEventID, substring(e.Description,1,36) AS Description, s.Waits, s.WaitTime FROM monSysWaits s, monWaitClassInfo c, monWaitEventInfo e WHERE s.WaitEventID = e.WaitEventID AND e.WaitClassID = c.WaitClassID ORDER BY 3 DESC
SELECT s.WaitEventID, substring(e.Description,1,36) AS Description, s.Waits, s.WaitTime FROM monSysWaits s, monWaitClassInfo c, monWaitEventInfo e WHERE s.WaitEventID = e.WaitEventID AND e.WaitClassID = c.WaitClassID ORDER BY 3 DESC
Wann ist das letzte Backup (aller Datenbanken) gelaufen?
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>
Historische MDA Tabellen - historical MDA tables
Folgende MDA Tabellen können als historische Tabellen angesehen werden.
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.
Folgende sp_configure Parameter legen die "number of rows" in den "historical tables" fest.
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".
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.
Zwei Countertypen "cumulative" und "transient" sind bei den MDA Tabellen bekannt.
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
Capture the performance metrics for the running processes
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.
Understanding "pipe" Tables
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)
Determining Optimum SARGs
SELECT ParameterName, TypeName FROM monTableParameters WHERE TableName = "monOpenObjectActivity"
Um Daten von einem zum anderen Device verschieben zu können bietet IQ bis Version 12.7 das "sp_iqrelocate database" Kommando an.
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.
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.
Die sp_iqaddlogin ist unterschiedlich auf IQ 12.7 und IQ 15.
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
’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
Der "–iqnumbercpus" ist Parameter, der dem Optimierer die Anzahl der zu beachtenden CPUs vorgibt. Per default werden die vom System angezeigten CPUs zur Berechnung der parallelen Threads genommen (max. 128). Mit der folgende Formel kann berechnet werden wieviele Threads aufgemacht werden:
60x (Anzahl der ersten 4 CPUS) + (50x restliche CPUs) + 2x (numConnections +2) +1 = numThreads