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.

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.

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

• '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:

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

SELECT object_name(s.id) tablename,
c.name column_name,
convert(int,c4)actual_steps,
convert(int,c5)requested_steps,
moddate last_updated
FROM sysstatistics s,syscolumns c
WHERE formatid=100
-- AND s.id = object_id("TABLE_NAME")
AND s.id=c.id
AND s.id >100
AND s.c4 != NULL
AND s.c5 != NULL
ORDER BY 1,2

Um einen Überblick über die Füllstände von aller Benutzer/UserTabellen im Sybase IQ zu bekommen müsste man für jede Tabelle die Stored Procedure sp_iqtablesize ausführen. Das kann schnell mühsam werden. Mit der folgenden Stored Procedure geht das schneller. Allerdings benötigt die Procedure auch Ressourcen und sollte darum nur ausgeführt werden, wenn der IQ nicht oder nur wenige benutzt wird.

Mit dem beigefügten Event wird die Procedure sp_iqUserTableSize täglich um 1 Uhr Nachts ausgeführt.

--
-- Quelle: http://www.sybinfo.de/asiq/historie-und-abfrage-der-groessen-fuellstaende-von-usertabellen/
--
-- Autor: Frank Massholder
-- Name: sp_iqUserTableSize
-- Das Script ist für den freien Gebrauch "freeware"
-- es wird jedoch keine Garantie darauf gegeben "no warentie"
--
-- Erstelle eine Stored Procdedure, um die Größen/Füllstände der
-- Benutzertabellen im Sybase IQ zu archivieren
--
ALTER PROCEDURE sp_iqUserTableSize
AS
BEGIN
  DECLARE @TableName varchar(64)
  DECLARE @TblName varchar(64)
  DECLARE @TblOwner varchar(64)
  DECLARE @TblSize char(20)
  DECLARE @ControlTblName varchar(64)
  DECLARE @cntTblName int
  DECLARE @i int
  SELECT @TblName = ('TblName')
  SELECT @ControlTblName = ('ControTblName')
  SELECT @cntTblName     = (SELECT count(*) FROM dbo.sp_iqtable())
 
  DECLARE cur_TableName CURSOR FOR
  SELECT table_owner+'.'+table_name
    FROM dbo.sp_iqtable()
      ORDER BY table_owner
        FOR READ ONLY
 
  OPEN cur_TableName
    SET @i = 1
    WHILE (@i <= @cntTblName)
    BEGIN
      FETCH NEXT cur_TableName INTO @TableName
      SELECT @ControlTblName =
      (
        SELECT @TblName
      )
      SELECT @TblName =
      (
        SELECT Tablename
        FROM  dbo.sp_iqtablesize(''+@TableName+'')
      )
      SELECT @TblOwner =
      (
        SELECT Ownername
        FROM  dbo.sp_iqtablesize(''+@TableName+'')
      )
      SELECT @TblSize =
      (
        SELECT KBytes
        FROM  dbo.sp_iqtablesize(''+@TableName+'')
      )
      INSERT INTO DBA.TBL_UserTableSize
      (
          LogDate
        , Ownername
        , Tablename
        , KBytes
      ) VALUES
      (
          getdate()
        , ''+@TblOwner+''
        , ''+@TblName+''
        , ''+@TblSize+''
      )
      -- Wenn die Ausgabe auf dem isql Prompt ausgegeben werden soll,
      -- muss die PRINT-Anweisung auskommentiert werden.
      -- (Hinweis: Verwende für Sybase IQ besser dbisql oder squish als isql)
      -- PRINT @TblOwner || '.' || @TblName || '           SIZE: ' || @TblSize
      SET @i = @i + 1
    END
  CLOSE cur_TableName
  DEALLOCATE CURSOR cur_TableName
  -- Lösche Daten, die älter als ein Jahr sind
  DELETE DBA.TBL_UserTableSize
    WHERE LogDate <= DATEADD(month, -12, getdate())
  COMMIT
END
 

Continue Reading »

Für das Aufsetzen einen IQ-Servers der die Konfiguration und gesetzten Optionen wie ein bereits bestehender ASIQ haben soll kann man sich die gesetzten Optionen aus dem bestehenden Server ziehen und sich gleich die entsprechenden "SET OPTION"-Anweisungen ausgeben lassen. Zum Einsatz kommt die Stored Procedure sp_iqcheckoptions.

Mit der folgenden Query auf dem Quell-Server erstellt man sich zunächst die notwendigen "SET OPTION"-Anweisungen.

SELECT 'SET OPTION '
    +convert(varchar(10), User_name)
    +'.'
    +convert(varchar(30), Option_name)
    +'='''
    +convert(varchar(30), Current_value)
    +''''
    FROM sp_iqcheckoptions()
        WHERE Option_type='Permanent'

Continue Reading »

Die folgenden Queries erstellen die GRAND Anweisungen für SELECT, INSERT, UPDATE, DELETE und ALTER um die Zugriffsrechte auf Objekte für einen bestimmten Benutzer zu kopieren bzw. zu clonen. Das ist besonders dann hilfreich, wenn ein neuer User die gleichen Rechte haben soll, wie ein bereits vorhandener User.

Der String "new_user_name" muss mit dem entsprechenden Neuen Benutzernamen ausgetauscht werden.

Der String "existing_user_name" muss mit dem entsprechenden bereits existierenden Benutzernamen ausgetauscht werden.

Erstellt die GRAND Anweisung um SELECT-Rechte eines Users auf Objekte/Tabellen zu clonen/kopieren

SELECT 'GRANT SELECT ON '
+ user_name(t4.uid)
+ '.'
+ convert(varchar(55), t3.table_name)
+ ' TO new_user_name
go'
FROM sysuserperm t1, systableperm t2, systable t3, sysobjects t4
WHERE t1.user_id = t2.grantee
AND t2.stable_id = t3.table_id
AND t1.user_name = 'existing_user_name'
AND t3.table_name = t4.name
AND selectauth = 'Y'

Continue Reading »

Hier eine Liste, der im ASE® zur Verfügung stehenden Aggregate Functions.

• avg
• count_big
• count(*)
• count
• count_big
• max
• min
• sum

Anmerkung: Die Links, mit denen die Funktionen hinterlegt sind zeigen auf http://de.sybinfo.org/ und geben detailliertere Informationen der jeweiligen Funktion.

Hier eine Liste der im ASE® zur Verfügung stehenden String Funktionen:

• ascii()
• char()
• charindex()
• char_length()
• compare()
• difference()
• lower()
• ltrim()
• patindex()
• replicate()
• reverse()
• right()
• rtrim()
• sortkey()
• soundex()
• space()
• srt()
• stuff()
• substring()
• to_unichar()
• uhighsurr()
• ulowsurr()
• upper()
• uscalar()

Anmerkung: Die Links, mit denen die Funktionen hinterlegt sind zeigen auf http://de.sybinfo.org/ und geben detailliertere Informationen der jeweiligen Funktion.

Um sich an einem ASE mit hilfe eines Clients wie isql oder jisql anmelden zu können, bedarf es eines gültigen Login und dem dazugehörigen Passwort. Nach einem erfolgreichen Login wird der Benutzer zu einer "default database" durchgereicht. Im allgemeinen ist das eine Benutzerdatenbank auf der ein entsprechender User, also einem Benutzer angelegt wurde, der zu dem Login gehört. Eine Verbindung zu einem Adaptive Server® bezeichnet man als Session.