Zakresy portów:
2049-2052
7937-9936
Notatki z działań, rozwiazywanie problemów itp. (głównie oracle i linux)
Zakresy portów:
2049-2052
7937-9936
— standalone
— weryfikacja:
show parameter recovery_file_dest;
— gdzie mają archlogi lecieć (czy lokalnie czy ASM) oraz ile mają użyć miejsca (ew. jeszcze format log_archive_format)
alter system set log_archive_dest_1=’LOCATION=/u01/baza/arch’ scope=both;
alter system set log_archive_dest_1=’location=+ASMARCH’ scope=spfile;
alter system set db_recovery_file_dest_size=200G scope=both;
— kładziemy bazę, montujemy, archivelog mode, open
shutdown immediate
startup mount
…
err np. w /var/log/messages:
sshd[*]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key
sshd[*]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
sshd[*]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
— sprawdzamy jakie klucze są dostępne i generujemy brakujące:
ls -la /etc/ssh/ssh*key
-rw-r—– 1 root ssh_keys 963 Nov 23 2017 /etc/ssh/ssh_host_key
-rw-r—– 1 root ssh_keys 1679 Nov 23 2017 /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa -f /etc/ssh/ssh_host
…
Przykładowe zapytania:
select * from v$rman_status;
SELECT MEDIA FROM V$BACKUP_PIECE_DETAILS WHERE SESSION_KEY=:B3 AND SESSION_RECID=:B2 AND SESSION_STAMP=:B1 AND DEVICE_TYPE = 'SBT_TAPE’ AND ROWNUM = 1 (cloudcontrolowe – dzięki Sławek)
to patchujemy DB, jak już nie ma dotępnych patchy bo np. mamy zbyt starą DB i nie chcemy się bawić w requesta patchy to:
exec dbms_stats.DELETE_TABLE_STATS(’SYS’,’X$KCCRSR’); — sam delete nie zadziała – trzeba przeliczyć statystyki również
exec dbms_stats.LOCK_TABLE_STATS(’SYS’,’X$KCCRSR’);
…
— standalone
alter system flush shared_pool;
alter system flush buffer_cache;
— RAC
alter system flush shared_pool global;
alter system flush buffer_cache global;
…
Jak nie działa shrink z menu, a plik mamy rozepchany to:
use BAZA
DBCC SHRINKFILE (’plik_log’, NOTRUNCATE);
DBCC SHRINKFILE (’plik_log’, 1000); — 1000 rozmiar pliku
dodatkowo:
wielkość:
DBCC SQLPERF(LOGSPACE);
zawartość log-a:
DBCC LOGINFO(’BPOWDKArch’)
Corrupt Block Found
TSN = 2, TSNAME = TEMP
RFN = 5, BLK = 2168258, RDBA = 23139778
OBJN = -1, OBJD = 23139776, OBJECT = , SUBOBJECT =
SEGMENT OWNER = , SEGMENT TYPE =
…
Dumping diagnostic data in directory=[cdmp_], requested by (instance=1, osid=), summary=[incident=*].
Corrupt Block Found
TSN = 2, TSNAME = TEMP
RFN = 5, BLK = 2168258, RDBA = 23139778
OBJN = -1, OBJD = 23139776, OBJECT = , SUBOBJECT =
SEGMENT OWNER = , SEGMENT TYPE =
tworzymy nowego tbs-a:
CREATE TEMPORARY TABLESPACE TEMP2 TEMPFILE '/data/temp201.dbf’ SIZE 100M AUTOEXTEND ON NEXT 100M MAXSIZE 65500M TABLESPACE GROUP ” EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
ustawiamy jako defaulta:
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP2;
ubijamy sesje, które mają dane jeszcze w temp (ew. restart DB) i dopiero wtedy można zdropować starego temp-a
SELECT b.tablespace,b.segfile#,b.segblk#,b.blocks,a.sid,a.serial#,
a.username,a.osuser, a.status, 'ALTER SYSTEM KILL
…
Jeżeli robimy bckp bez trybu arch, to niestety odpalamy bazę w mouncie i dopiero wtedy FULL + INCrementale
Jeżeli mamy w trybie arch, to na spokojnie możemy robić full + inc + arch w trybie open ale! jeżeli mamy tabele, indexy nologging to dupa – lepiej na czas migracji (o ile chcemy 1:1 bez utraty danych) włączyć force logging-a: ALTER DATABASE force logging; – weryfikacja select name, force_logging from v$database; i dopiero teraz full, inc teoretycznie powinien dociągnąć od ostatniego scn-a, ale komu chce się bawić i sprawdzać pliki które są w nologgingu i od jakiego scn-a są, no ale w razie czego to weryfikujemy:
SELECT file#, name, unrecoverable_change# FROM v$datafile where unrecoverable_change# > 0;
jeżeli nie zweryfikujemy to niestety możemy zostać zbluzgani przy pierwszym lepszym select (który odnośi się akurat do nolooginngowej tabeli albo indexu), oczywiście jeżeli został zmodyfikowany po full-u i nawet kolejnych incrementalach (będzie komunikat o tym, że należy zrobić recovery pliku, ale nie ma na bckp)
— bckp full
$ORACLE_HOME/bin/rman target /
connect catalog rman/x@rcat;
run
…
Po restorze DB i alter database openresetlogs; może wyskoczyć:
ORA-00392: log 8 of thread 2 is being cleared, operation not allowed
czyścimy daną grupę:
alter database clear
…
— pełny błąd:
2022-05-02T11:50:30.341692+02:00
Adjusting the default value of parameter parallel_max_servers
from 880 to 348 due to the value of parameter processes (500)
Starting ORACLE instance (normal) (OS id: 231844)
2022-05-02T11:50:30.362069+02:00
Sys-V shared memory will be used for creating SGA
2022-05-02T11:50:30.365273+02:00
Dump of system resources acquired for SHARED GLOBAL AREA (SGA)
2022-05-02T11:50:30.365469+02:00
Domain name: system.slice/oracle-ohasd.service
2022-05-02T11:50:30.365587+02:00
Per process system memlock (soft) limit = UNLIMITED
2022-05-02T11:50:30.365658+02:00
Expected per process system memlock (soft) limit to lock
instance MAX SHARED GLOBAL AREA (SGA) into memory: 3192M
2022-05-02T11:50:30.365765+02:00
Available system pagesizes:
4K, 2048K
2022-05-02T11:50:30.365868+02:00
Supported system pagesize(s):
2022-05-02T11:50:30.365920+02:00
PAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s)
2022-05-02T11:50:30.366069+02:00
2048K 16792 1596 1109 ORA-27125
2022-05-02T11:50:30.366123+02:00
Reason for not supporting certain system pagesizes:
2022-05-02T11:50:30.366193+02:00
4K – Large pagesizes only
2022-05-02T11:50:30.366275+02:00
SGA: Realm creation failed
–odpalamy skrypt z Doc.ID 401749.1 (najlepiej aby wszystkie instancje były odpalone):
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=361323.1&id=401749.1
[oracle@dm02 ~]$ vi hugepages_settings.sh
[oracle@dm02 ~]$ chmod +x hugepages_settings.sh
[oracle@dm02 ~]$ ./hugepages_settings.sh
Recommended setting: vm.nr_hugepages =
…