In eigener Sache – Serverwechsel
Da ich vergangenes Wochenende mit dem Blog auf einen neuen Server gewechselt habe kann es bei der Anzeige diverser Blogeinträge oder Bilder zu Problemen kommen.
Falls euch etwas auffällt wäre es super wenn ihr mir einfach einen kleinen Hinweis gebt, ich schaue dann das ich das Problem behoben bekomme.
SAP ASE System Kopie
In den letzten Tagen war ich dabei, eine System-Kopie für einen Kunden durchzuführen, welcher aus seiner 2-Systemlandschaft eine 3-Systemlandschaft machen wollte. Dazu wurde das Produktivsystem kopiert und zum neuen QAS System gemacht.
Bei den Systemen handelte es sich alle um ein NetWeaver 7.4 und eine SAP ASE 16.
Beim Laden des Database dump musste ich feststellen, dass die ASE mehr Platz benötigt als die kopierte Datenbank. Also musste der Platz und die Datenbank erweitert werden:
disk resize name=<name des DATA Files>,size="<zu erweiternder Wert>"
go
Damit wäre zwar das DATA File erweitert, aber noch nicht die Datenbank.
alter database <SID> on <DATA device>="<zu erweiternder Wert>"
go
Leider fiel der letzte Befehl auf die Nase mit folgender Meldung:
Database '<SID>' cannot be opened because either an earlier system termination left LOAD DATABASE incomplete or the database is created with 'for load' option. Load the database or contact a user with System Administrator (SA) role.
Um diesen Fehler zu umgehen muss man an den alter Befehl noch die Option „for load“ anhängen. z.B.:
alter database SMI on SM1_data_001="10G" for load
go
grub2: systemd target während boot
Unter SLES12 und RedHat 7 wird Grub2 ausgeliefert. Um während dem Bootvorgang in ein bestimmtes „System target“ zu booten kann man während Grub die Auswahl der Kernelversionen anzeigt mit „e“ in den Edit Modus springen.
Hier kann man in die „linux“ (Kernelzeile) Zeile das System Target mit angeben wie in diesem Screenshot zu sehen ist.
In diesem Fall habe ich über die Angabe „systemd.unit=rescue.target“ in den Rescue Modus gebootet. Mit F10 oder CTRL-X bestätigen wir die Eingabe und anschließend landet ihr in dem angegeben System Target.
Synology: Video Station -> „Audio Format wird nicht unterstützt“
Veraltet! Da der Blogartikel hat ja bereits ca. 2 Jahre alt ist, ist dieser nicht mehr auf dem aktuellsten Stand. Unter DSM 6.X würde ich die Vorgehensweise aus diesem Artikel empfehlen: https://costigator.com/system-administration/how-to-enable-dts-support-on-synology/ empfehlen und das Community Paket einspielen!
Bis vor 6 Wochen war ich Besitzer einer Synology DS211+. Wie der Name schon sagt stammte die Diskstation mit 2 Bays aus dem Jahre 2011. Lange Zeit wurde die Diskstation für OwnCloud und alle internen Dokumente/persönliche Filme/Audio und Bilder genutzt. Beim streamen von Filmen auf unterschiedliche Clients im LAN (Fernseher, Stereoanlage, iPad, iPhone, Laptop Win, MacBook) hatte ich überhaupt keine Probleme.
Anfang diesen Jahres habe ich mir eine neue Synology DS916+ zugelegt. Es bedurfte einfach mal einem Upgrade :D. Dabei bemerkte ich schnell das es gerade beim streamen von Filmen sehr oft auf den Clients, und auch sehr ärgerlich auf dem Fernseher, zum Fehler „Audio Codec wird nicht unterstützt“ kam. Diverse Videos konnten seit dem Upgrade bei mir nicht mehr abgespielt werden. Mit ein bißchen suchen fand ich heraus das es ausschließlich Videodateien mit DTS Sound betrifft.
Heute bin ich über diesen Beitrag von Nuno Horta gestolpert. Es gibt scheinbar ein 3rd Party Application welche den DTS Codec wieder zur Verfügung stellt.
SAP HANA: Best Practices für das Deployment von SAP HANA in einer VMware vSphere Umgebung
Bereits vor einigen Tagen hat VMware seinen Best Practice Guide für das deployment von SAP HANA VMs in einer virtuellen Infrastruktur (vSphere) aktualisiert. Viel spannendes KnowHow welches bei uns auch in einen dreitägigen Workshop AD661 meines Arbeitgebers mit einfließt.
Den vollständigen Best Practices Guide von VMware bekommt ihr unter folgendem Link -> Klick mich ich bin ein Link <-
ESXi Konfigurations Backup
Da die meisten ESXi Hosts mittlerweile nicht mehr auf lokalen Festplatten sondern auf einem USB-Stick oder SD-Karten installiert sind, kommt es öfters mal vor, dass diese Devices kaputt gehen. Dann taucht eine Meldung im vSphere auf, dass der ESXi Host sein Boot Device nicht mehr findet.
Diese Meldung ist erstmal kein Problem, da der ESXi beim booten komplett in den RAM geladen wird und erst wieder bei einem Neustart auf das Boot Device angewiesen ist.
Jedoch sollte mal bei nächster Gelegenheit das Boot Device austauschen. Um die ganze Einstellungen nicht wieder von vorne zu tätigen gibt es zwei Wege wie man Sich die Konfiguration sichern kann und danach wieder zurückspielen.
Methode 1:
Man erstellt ein Hostprofile des ESXi Hosts mit dem defekten Boot Device. Diese kann dann nach dem austauschen des Boot Mediums wieder auf diesen Host zurückgespielt werden.
Methode 2:
In der VMware KB gibt es einen Hinweise mit folgender Nummer: 2042141
Dieser bietet mehrere Möglichkeiten, wie man die Konfiguration eines ESXi Hosts sicher kann. ich bevorzuge die Möglichkeit direkt über die ESXi Command Line.
Hierfür folgenden Befehl absetzen:
vim-cmd hostsvc/firmware/backup_config
Wenn der Vorgang abgeschlossen ist, erhält man eine URL welche man mit einem Browser öffnet und ein .tgz File herunterladen muss. Diese Archiv enthält die Konfiguration des ESXi Hosts.
Nun kann der neue Stick mit einem neuen Image betank werden und dann spielt man einfach die Konfiguration zurück.
Zuerst muss der ESXi Hosts in Maintenance Mode genommen werden:
vim-cmd hostsvc/maintenance_mode_enter
Danach kann man die Konfiguration wieder zurück laden:
vim-cmd hostsvc/firmware/restore_config <Pfad zu Konfigurations Archiv>
Danach den ESXi Host einfach neustarten.
Oracle: selektieren nach Schemas in der DB
Auf der Suche mir alle Schemas einer Oracle Datenbank anzeigen zu lassen bin ich über folgenden Befehlsaufruf gestolpert:
select distinct owner from dba_segments
where owner in (select username from dba_users
where default_tablespace not in ('SYSTEM','SYSAUX')
)
;
Sehr hilfreich.
SAP: Uhrzeitanalyse
In SAP lässt sich über den Report rsdbtime die verschiedenen Uhrzeitstände des OS vs. SAP System und DB auf einen Blick prüfen:
macOS: Remote Tool verschiedene Protokolle
Ich bin ein Freund von RemoteTools welche viele unterschiedliche Protokolle beherrschen. Mich nervt einfach nur 5 unterschiedliche Tools für RDP, VNC, SSH, Teamviewer etc. bediehnen und auf dem Rechner zu haben.
Vor allem auch die Möglichkeit mit einem Tool per Tabs auf unterschiedlichen Rechnern zuzugreifen finde ich hier sehr angenehm.
Auf Linux habe ich meistens Remmina genutzt welches hier den Dienst ganz ordentlich verrichtete.
Auf Windows nutze ich eigentlich eine Mischung aus mRemoteNG und MobaXterm von denen ich eigentlich beidermaßen begeistert bin je nachdem für welchen Anwendungszweck.
Für MacOS hab ich bisher noch so ein Tool gesucht und bin mit Royal TSX fündig geworden.
Aktuell nutze ich noch die freie Version. Da ich das Tool erst seit ende letzter Woche im Einsatz habe möchte ich es noch ausgiebig testen bevor ich an eine Subscription denke.
Die freie Version ist (ähnlich wie bei MobaXterm) eingeschränkt nutzbar. Wobei mich diese Einschränkungen aktuell noch nicht stören.
- Up to 10 connections
- Up to 10 credentials
- 1 document
Linux systemd: Unit Files
Um ein Skript bei Systemstart des SLES12 Server mit systemd aus zu führen benötigt man zwei Dinge:
1. das Skript welches man ausführen möchte und 2. ein „.service“ File (Unit-File) für den Systemd.
Wir legen beispielsweise ein Skript für die Ausführung unter „/root/bin/skript.sh“.
Das .service File wird unter dem Verzeichnis /etc/systemd/system abgelegt. Beispiel: /etc/systemd/system/skript.service
Anschließend sieht das Unitfile hierfür folgendermaßen aus:
[Unit]
Description=Skript für Systemboot
[Service]
Type=oneshot
ExecStart=/root/bin/skript.sh
[Install]
WantedBy=multi-user.target
Dies wäre die einfachste Art ein Skript bei Systemstart aus zu führen.
Falls es sich um einen Service handelt der gestoppt und gestartet werden soll könnte das dementsprechende Skript folgendermaßen aussehen:
start() {
exec hierdasexecutable start
}
stop() {
exec hierdasexecutable stop
}
case $1 in
start|stop) "$1" ;;
esac
Das dazu passende .service (Unit File) könnte dann folgendermaßen aussehen:
[Unit]
Description=Skript für Systemboot
[Service]
Type=oneshot
ExecStart=/root/bin/skript.sh start
ExecStop=/root/bin/skript.sh stop
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Anschließend kann man sein Skript steuern mit:
systemctl start skript.service | systemet stop skript.service
Für den nächsten Systemstart einplanen:
systemctl enable skript.service
RSS Feed
Alle Beiträge unter CC–BY–SA 3.0 unported
Diese(s) Werk(e) bzw. Inhalt(e) von Thorsten Geister steht/stehen unter einer Creative Commons Namensnennung-Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.
Beruht auf einem Inhalt unter linux-voodoo.de.