0. ssh root@openldap2319
1. slapcat -v -l antares.ldif
2. scp antares.ldif root@openldap2426:/root/ldap/
3. ssh root@openldap2426
4. /etc/init.d/ldap stop
5. slapadd -v -l ldap/antares.ldif
6. /etc/init/d/ldap start
Читать далее
5 лет назад
2014-12-08
Oracle 8i: Corrupt block relative dba
И вечный бой, покой нам только снится.
Oracle 8.1.7.4 на SLES8 SP3. В alert логе найдена вот такая запись:
***
Corrupt block relative dba: 0x1281748b (file 74, block 95371)
Fractured block found during buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x1281748b
last change scn: 0x0000.0004ef13 seq: 0x1 flg: 0x02
consistency value in tail: 0x49e90601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x1281748b (file 74, block 95371) found same corrupted data
Ишем объект, в котором битый блок:
select tablespace_name, segment_type, owner, segment_name
from dba_extents
where file_id =74
and 95371 between block_id and block_id + blocks - 1;
и видим, что это таблица.
Первое что делаем - верификацию файлов данных.
alexsf@24412fa: ssh alexsf@adonis
alexsf@adonis's password:
alexsf@adonis: sudo -s
Password:
adonis:/home/alexsf # su - root
adonis:~ # su - oracle
oracle@adonis: export ORACLE_SID=main
oracle@adonis: sqlplus /nolog
SQL*Plus: Release 8.1.7.0.0 - Production on Mon Dec 8 08:16:56 2014
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SQL> connect system
Enter password:
Connected.
SQL> select tablespace_name, segment_type, owner, segment_name
from dba_extents
where file_id =74
and 95371 between block_id and block_id + blocks - 1;
TABLESPACE_NAME SEGMENT_TYPE OWNER
------------------------------ ------------------ ------------------------------
SEGMENT_NAME
--------------------------------------------------------------------------------
ZARPLATA TABLE ZARPHERSON
FOR_AUDIT
SQL> select file_name from dba_data_files
where tablespace_name ='ZARPLATA';
FILE_NAME
--------------------------------------------------------------------------------
/u02/oradata/main/zarplata01.ora
/u03/oradata/main/zarplata02.ora
SQL> exit
Disconnected from Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
With the Partitioning option
JServer Release 8.1.7.4.0 - Production
oracle@adonis:~> dbv file=/u02/oradata/main/zarplata01.ora blocksize=8192
DBVERIFY: Release 8.1.7.4.0 - Production on Mon Dec 8 08:25:00 2014
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /u02/oradata/main/zarplata01.ora
DBVERIFY - Verification complete
Total Pages Examined : 196608
Total Pages Processed (Data) : 80699
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 57324
Total Pages Failing (Index): 0
Total Pages Processed (Other): 418
Total Pages Empty : 58166
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
oracle@adonis:~> dbv file=/u03/oradata/main/zarplata02.ora blocksize=8192
DBVERIFY: Release 8.1.7.4.0 - Production on Mon Dec 8 08:25:44 2014
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /u03/oradata/main/zarplata02.ora
DBVERIFY - Verification complete
Total Pages Examined : 196608
Total Pages Processed (Data) : 77223
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 63612
Total Pages Failing (Index): 0
Total Pages Processed (Other): 540
Total Pages Empty : 55233
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
И наблюдаем чудо - все у нас хорошо :)
Дальше делаем валидацию структуры таблицы:
oracle@adonis:~> sqlplus /nolog
SQL*Plus: Release 8.1.7.0.0 - Production on Mon Dec 8 08:34:29 2014
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SQL> connect system
Enter password:
Connected.
SQL> ANALYZE TABLE zarpherson.for_audit VALIDATE STRUCTURE CASCADE;
ANALYZE TABLE zarpherson.for_audit VALIDATE STRUCTURE CASCADE
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 74, block # 95371)
ORA-01110: data file 74: '/u02/oradata/main/zarplata01.ora'
О, це вже шо то...
Создаем системные таблицы для проведения работ по починке:
SQL> conn sys as sysdba
Enter password:
Connected.
SQL> BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'REPAIR_TABLE',
TABLE_TYPE => dbms_repair.repair_table,
ACTION => dbms_repair.create_action,
TABLESPACE => 'USERS');
END;
/ 2 3 4 5 6 7 8
PL/SQL procedure successfully completed.
SQL> BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'ORPHAN_KEY_TABLE',
TABLE_TYPE => dbms_repair.orphan_table,
ACTION => dbms_repair.create_action,
TABLESPACE => 'USERS');
END;
/ 2 3 4 5 6 7 8
PL/SQL procedure successfully completed.
Проверяем битые блоки:
SQL> SET serveroutput on
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
corrupt_count => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;
/
SQL> 2 3 4 5 6 7 8 9 10 11 number corrupt: 1
PL/SQL procedure successfully completed.
SQL> SELECT object_name, block_id, corrupt_type, marked_corrupt,
corrupt_description, repair_description
FROM repair_table; 2 3
OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR
------------------------------ ---------- ------------ ----------
CORRUPT_DESCRIPTION
--------------------------------------------------------------------------------
REPAIR_DESCRIPTION
--------------------------------------------------------------------------------
FOR_AUDIT 95371 6148 TRUE
mark block software corrupt
Фиксим найденные битые блоки. Насколько я понял, в реальности ничего не фиксится, только помечается как поврежденное:
SQL> SET serveroutput on
DECLARE num_fix INT;
BEGIN
num_fix := 0;
DBMS_REPAIR.FIX_CORRUPT_BLOCKS (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME=> 'FOR_AUDIT',
OBJECT_TYPE => dbms_repair.table_object,
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
FIX_COUNT=> num_fix);
DBMS_OUTPUT.PUT_LINE('num fix: ' || to_char(num_fix));
END;
/
SQL> 2 3 4 5 6 7 8 9 10 11 12 num fix: 0
PL/SQL procedure successfully completed.
SQL> SELECT object_name, block_id, marked_corrupt
FROM repair_table; 2
OBJECT_NAME BLOCK_ID MARKED_COR
------------------------------ ---------- ----------
FOR_AUDIT 95371 TRUE
Теперь надо найти индексы, ссылающиеся на битый блок:
SQL> select index_name from dba_indexes
where table_name = 'FOR_AUDIT'
and owner = 'ZARPHERSON';
/
2 3
INDEX_NAME
------------------------------
I_FOR_AUDIT_AUDIT_TABLES_ID
I_FOR_AUDIT_AUDIT_USERS_ID
I_FOR_AUDIT_IDKADRY
I_FOR_AUDIT_TIMESTAMP
PK_FOR_AUDIT
SQL> SET serveroutput on
DECLARE num_orphans INT;
BEGIN
num_orphans := 0;
DBMS_REPAIR.DUMP_ORPHAN_KEYS (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'PK_FOR_AUDIT',
OBJECT_TYPE => dbms_repair.index_object,
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
ORPHAN_TABLE_NAME=> 'ORPHAN_KEY_TABLE',
KEY_COUNT => num_orphans);
DBMS_OUTPUT.PUT_LINE('orphan key count: ' || to_char(num_orphans));
END;
/
SQL> 2 3 4 5 6 7 8 9 10 11 12 13 orphan key count: 0
PL/SQL procedure successfully completed.
И так по очереди со всеми. Если "orphan key count: 0", значит все хорошо.
В нашем случае везде был 0.
Однако, если бы что-то было найдено - не беда. Надо просто перестроить индексы.
Ребилдим фрилист таблицы. По сути исключаем битые блоки из доступных:
SQL> BEGIN
DBMS_REPAIR.REBUILD_FREELISTS (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
OBJECT_TYPE => dbms_repair.table_object);
END;
/
2 3 4 5 6 7
PL/SQL procedure successfully completed.
Ну и делаем блоки невидимыми для DML операций:
SQL> BEGIN
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
OBJECT_TYPE => dbms_repair.table_object,
FLAGS => dbms_repair.skip_flag);
END;
/
2 3 4 5 6 7 8
PL/SQL procedure successfully completed.
Проверяем, что для данной таблицы битые блоки будут исключаться из операций:
SQL> SELECT owner, table_name, skip_corrupt
FROM dba_tables
WHERE owner = 'ZARPHERSON'
AND skip_corrupt = 'ENABLED'; 2 3 4
OWNER TABLE_NAME SKIP_COR
------------------------------ ------------------------------ --------
ZARPHERSON FOR_AUDIT ENABLED
Что имеем в итоге - таблицу можно использовать, но проблема не устранена. Блок то битый остался, мы просто наворотили для него механизм невидимости. Но при этом если повторно сделать валидацию структуры - ничего не поменялось. Нам повезло в одном - это таблица аудита. Со всеми вытекающими. В нашем случае делаем так:
connect zarpherson@main
create table for_audit_tmp
as select * from for_audit;
truncate table for_audit;
insert into for_audit
select * from for_audit_tmp;
truncate table for_audit_tmp;
commit;
Делаем анализ структуры и видим:
SQL> ANALYZE TABLE zarpherson.for_audit VALIDATE STRUCTURE CASCADE;
Table analyzed.
То есть битый блок исчез. Ну а теперь же надо вернуть все в зад, чтоб битые блоки не пропускались при DML операциях... Дальше учитывайте, что в REPAIR_TABLE у нас только одна запись!!!
SQL> truncate table repair_table;
Table truncated.
SQL> SET serveroutput on
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
corrupt_count => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;SQL> 2 3 4 5 6 7 8 9 10
11 /
number corrupt: 1
PL/SQL procedure successfully completed.
SQL> SELECT object_name, block_id, corrupt_type, marked_corrupt,
corrupt_description, repair_description
FROM repair_table; 2 3
OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR
------------------------------ ---------- ------------ ----------
CORRUPT_DESCRIPTION
--------------------------------------------------------------------------------
REPAIR_DESCRIPTION
--------------------------------------------------------------------------------
FOR_AUDIT 98250 6148 TRUE
mark block software corrupt
АЧЧЧЧЧПУЕЕЕЕЕТЬ!!!!!
Откуда, мля, я же только проверил, НИЧЕГО НЕ БЫЛО!!!!!
SQL> ANALYZE TABLE zarpherson.for_audit VALIDATE STRUCTURE CASCADE;
Table analyzed.
А-а-а-а-а-а!!! АЧПУЕТЬ АЧПУЕННЕЕ ЧЕМ АЧПУЕЛ!!! КАК???!!!
Та-а-а-ак...
INSERT INTO for_audit_tmp SELECT * FROM for_audit;
DROP TABLE for_audit
/
CREATE TABLE for_audit
(timestamp DATE,
user_name VARCHAR2(30),
table_name VARCHAR2(30),
action VARCHAR2(1),
data_values VARCHAR2(2000),
id NUMBER ,
audit_tables_id NUMBER,
audit_users_id NUMBER,
idkadry NUMBER)
PCTFREE 10
PCTUSED 40
INITRANS 1
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 223846400
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
NOCACHE
NOMONITORING
NOPARALLEL
LOGGING
/
-- Grants for Table
GRANT SELECT ON for_audit TO zp_zarpherson_buh_bez_prop
/
GRANT SELECT ON for_audit TO zp_zarpherson_operator
/
GRANT SELECT ON for_audit TO zp_zarpherson_buhdostup
/
GRANT SELECT ON for_audit TO zp_zarpherson_buhgalter
/
GRANT SELECT ON for_audit TO zp_zarpherson_read_only
/
GRANT SELECT ON for_audit TO zp_zarpherson_read_by_podr
/
GRANT SELECT ON for_audit TO zp_zarpherson_buh_bp_by_podr
/
GRANT SELECT ON for_audit TO plan_1
/
GRANT SELECT ON for_audit TO zp_zarpherson_admin
/
GRANT SELECT ON for_audit TO zp_zarpherson_read_only_dostup
/
-- Indexes for FOR_AUDIT
CREATE INDEX i_for_audit_audit_users_id ON for_audit
(
audit_users_id ASC
)
PCTFREE 5
INITRANS 2
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 1048576
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
NOPARALLEL
LOGGING
/
CREATE INDEX i_for_audit_idkadry ON for_audit
(
idkadry ASC
)
PCTFREE 5
INITRANS 2
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 1048576
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
NOPARALLEL
LOGGING
/
CREATE INDEX i_for_audit_timestamp ON for_audit
(
timestamp ASC
)
PCTFREE 5
INITRANS 2
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 1048576
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
NOPARALLEL
LOGGING
/
CREATE INDEX i_for_audit_audit_tables_id ON for_audit
(
audit_tables_id ASC
)
PCTFREE 5
INITRANS 2
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 1048576
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
NOPARALLEL
LOGGING
/
-- Constraints for FOR_AUDIT
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_action CHECK (ACTION IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_audit_tables_id CHECK (audit_tables_id IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_data_values CHECK (DATA_VALUES IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_table_name CHECK (TABLE_NAME IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_timestamp CHECK (TIMESTAMP IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_user_name CHECK (USER_NAME IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT pk_for_audit PRIMARY KEY (id)
USING INDEX
PCTFREE 5
INITRANS 2
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 2097152
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
/
-- Triggers for FOR_AUDIT
CREATE OR REPLACE TRIGGER tr_for_audit_bi
BEFORE
INSERT
ON for_audit
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
:new.timestamp := SYSDATE;
:new.user_name := USER;
BEGIN
SELECT id
INTO :new.audit_users_id
FROM audit_users
WHERE user_name = user;
EXCEPTION
WHEN no_data_found THEN
INSERT INTO audit_users(user_name)
VALUES(USER)
RETURNING id INTO :new.audit_users_id;
END;
BEGIN
SELECT id
INTO :new.audit_tables_id
FROM audit_tables
WHERE table_name = :new.table_name;
EXCEPTION
WHEN no_data_found THEN
INSERT INTO audit_tables(date_start, date_end, table_name)
VALUES(trunc(sysdate), to_date('01013000', 'ddmmyyyy'), :new.table_name)
RETURNING id INTO :new.audit_tables_id;
END;
SELECT sq_for_audit.nextval
INTO :new.id
FROM dual;
END;
/
-- Comments for FOR_AUDIT
COMMENT ON TABLE for_audit IS 'Таблица с информацией о действиях пользователя над данными'
/
COMMENT ON COLUMN for_audit.action IS 'Действие:
U - UPDATE
I - INSERT
D - DELETE'
/
COMMENT ON COLUMN for_audit.audit_tables_id IS 'Идентификатор таблицы из AUDIT_TABLES'
/
COMMENT ON COLUMN for_audit.audit_users_id IS 'Идентификатор пользователя из AUDIT_USERS'
/
COMMENT ON COLUMN for_audit.data_values IS 'Значение до действия над данными и после'
/
COMMENT ON COLUMN for_audit.id IS 'Идентификатор записи'
/
COMMENT ON COLUMN for_audit.idkadry IS 'Идентификатор работника из T_KADRY'
/
COMMENT ON COLUMN for_audit.table_name IS 'Наименование таблицы'
/
COMMENT ON COLUMN for_audit.timestamp IS 'Дата '
/
COMMENT ON COLUMN for_audit.user_name IS 'Имя пользователя'
/
-- End of DDL Script for Table ZARPHERSON.FOR_AUDIT
-- Foreign Key
ALTER TABLE for_audit
ADD CONSTRAINT fk_for_audit_audit_tables_id FOREIGN KEY (audit_tables_id)
REFERENCES audit_tables (id)
/
-- End of DDL script for Foreign Key(s)
Проверяем, кто тут поц:
SQL> truncate table repair_table;
Table truncated.
SQL> SET serveroutput on
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
corrupt_count => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;SQL> 2 3 4 5 6 7 8 9 10
11 /
number corrupt: 0
PL/SQL procedure successfully completed.
НИКОГО!!! А вот так:
conn zarpherson
insert into for_audit
select * from for_audit_tmp;
commit;
conn sys as sysdba
SQL> SET serveroutput on
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
corrupt_count => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;SQL> 2 3 4 5 6 7 8 9 10
11 /
number corrupt: 1
PL/SQL procedure successfully completed.
SQL>
SQL> SELECT object_name, block_id, corrupt_type, marked_corrupt,
corrupt_description, repair_description
FROM repair_table; 2 3
OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR
------------------------------ ---------- ------------ ----------
CORRUPT_DESCRIPTION
--------------------------------------------------------------------------------
REPAIR_DESCRIPTION
--------------------------------------------------------------------------------
FOR_AUDIT 98250 6148 TRUE
mark block software corrupt
И хрен его знает, кто тут поц и где тут подлива... Таблица пересоздана, и при этом при внесении в нее данных ломается тот же самый блок... При этом валидация структуры проходит нормально...
Ладно, ждем перезапуска базы и анализа всех объектов по счедулеру. А пока проверим, а все ли объекты проходят валидацию структуры???:
set trimspool on
set pagesize 0
set heading off
spool _tmp_1.sql
select 'ANALYZE TABLE '||owner||'.'||table_name||' VALIDATE STRUCTURE CASCADE;'
from dba_tables
where owner not in ('SYS','OUTLN','SYSTEM')
order by owner, table_name;
spool off
@_tmp_1.sql
И вот что в результате надыбал:
ANALYZE TABLE COUNTERSREAD.OSTABLE VALIDATE STRUCTURE CASCADE
*
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file
Из trace file
** 2014-12-08 12:10:13.037
*** SESSION ID:(44.1327) 2014-12-08 12:10:13.037
row not found in index tsn: 9 rdba: 0x03414909
env: (scn: 0x0000.018348c7 xid: 0x0000.000.00000000 uba: 0x00000000.0000.00)col 0; len 8; (8): 34 37 30 35 35 37 32 37
col 1; len 6; (6): 03 01 90 ef 00 09
Block header dump: 0x030190ef
Object id on Block? Y
seg/obj: 0x29ce csc: 0x00.12365be itc: 1 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
и куча мути дальше, похожей да дамп куска области памяти.
По нескольким объектам валидация не прошла, потому что ORA-00054: resource busy and acquire with NOWAIT specified
Читать далее
Oracle 8.1.7.4 на SLES8 SP3. В alert логе найдена вот такая запись:
***
Corrupt block relative dba: 0x1281748b (file 74, block 95371)
Fractured block found during buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x1281748b
last change scn: 0x0000.0004ef13 seq: 0x1 flg: 0x02
consistency value in tail: 0x49e90601
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x1281748b (file 74, block 95371) found same corrupted data
Ишем объект, в котором битый блок:
select tablespace_name, segment_type, owner, segment_name
from dba_extents
where file_id =74
and 95371 between block_id and block_id + blocks - 1;
и видим, что это таблица.
Первое что делаем - верификацию файлов данных.
alexsf@24412fa: ssh alexsf@adonis
alexsf@adonis's password:
alexsf@adonis: sudo -s
Password:
adonis:/home/alexsf # su - root
adonis:~ # su - oracle
oracle@adonis: export ORACLE_SID=main
oracle@adonis: sqlplus /nolog
SQL*Plus: Release 8.1.7.0.0 - Production on Mon Dec 8 08:16:56 2014
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SQL> connect system
Enter password:
Connected.
SQL> select tablespace_name, segment_type, owner, segment_name
from dba_extents
where file_id =74
and 95371 between block_id and block_id + blocks - 1;
TABLESPACE_NAME SEGMENT_TYPE OWNER
------------------------------ ------------------ ------------------------------
SEGMENT_NAME
--------------------------------------------------------------------------------
ZARPLATA TABLE ZARPHERSON
FOR_AUDIT
SQL> select file_name from dba_data_files
where tablespace_name ='ZARPLATA';
FILE_NAME
--------------------------------------------------------------------------------
/u02/oradata/main/zarplata01.ora
/u03/oradata/main/zarplata02.ora
SQL> exit
Disconnected from Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
With the Partitioning option
JServer Release 8.1.7.4.0 - Production
oracle@adonis:~> dbv file=/u02/oradata/main/zarplata01.ora blocksize=8192
DBVERIFY: Release 8.1.7.4.0 - Production on Mon Dec 8 08:25:00 2014
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /u02/oradata/main/zarplata01.ora
DBVERIFY - Verification complete
Total Pages Examined : 196608
Total Pages Processed (Data) : 80699
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 57324
Total Pages Failing (Index): 0
Total Pages Processed (Other): 418
Total Pages Empty : 58166
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
oracle@adonis:~> dbv file=/u03/oradata/main/zarplata02.ora blocksize=8192
DBVERIFY: Release 8.1.7.4.0 - Production on Mon Dec 8 08:25:44 2014
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /u03/oradata/main/zarplata02.ora
DBVERIFY - Verification complete
Total Pages Examined : 196608
Total Pages Processed (Data) : 77223
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 63612
Total Pages Failing (Index): 0
Total Pages Processed (Other): 540
Total Pages Empty : 55233
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
И наблюдаем чудо - все у нас хорошо :)
Дальше делаем валидацию структуры таблицы:
oracle@adonis:~> sqlplus /nolog
SQL*Plus: Release 8.1.7.0.0 - Production on Mon Dec 8 08:34:29 2014
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SQL> connect system
Enter password:
Connected.
SQL> ANALYZE TABLE zarpherson.for_audit VALIDATE STRUCTURE CASCADE;
ANALYZE TABLE zarpherson.for_audit VALIDATE STRUCTURE CASCADE
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 74, block # 95371)
ORA-01110: data file 74: '/u02/oradata/main/zarplata01.ora'
О, це вже шо то...
Создаем системные таблицы для проведения работ по починке:
SQL> conn sys as sysdba
Enter password:
Connected.
SQL> BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'REPAIR_TABLE',
TABLE_TYPE => dbms_repair.repair_table,
ACTION => dbms_repair.create_action,
TABLESPACE => 'USERS');
END;
/ 2 3 4 5 6 7 8
PL/SQL procedure successfully completed.
SQL> BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'ORPHAN_KEY_TABLE',
TABLE_TYPE => dbms_repair.orphan_table,
ACTION => dbms_repair.create_action,
TABLESPACE => 'USERS');
END;
/ 2 3 4 5 6 7 8
PL/SQL procedure successfully completed.
Проверяем битые блоки:
SQL> SET serveroutput on
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
corrupt_count => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;
/
SQL> 2 3 4 5 6 7 8 9 10 11 number corrupt: 1
PL/SQL procedure successfully completed.
SQL> SELECT object_name, block_id, corrupt_type, marked_corrupt,
corrupt_description, repair_description
FROM repair_table; 2 3
OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR
------------------------------ ---------- ------------ ----------
CORRUPT_DESCRIPTION
--------------------------------------------------------------------------------
REPAIR_DESCRIPTION
--------------------------------------------------------------------------------
FOR_AUDIT 95371 6148 TRUE
mark block software corrupt
Фиксим найденные битые блоки. Насколько я понял, в реальности ничего не фиксится, только помечается как поврежденное:
SQL> SET serveroutput on
DECLARE num_fix INT;
BEGIN
num_fix := 0;
DBMS_REPAIR.FIX_CORRUPT_BLOCKS (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME=> 'FOR_AUDIT',
OBJECT_TYPE => dbms_repair.table_object,
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
FIX_COUNT=> num_fix);
DBMS_OUTPUT.PUT_LINE('num fix: ' || to_char(num_fix));
END;
/
SQL> 2 3 4 5 6 7 8 9 10 11 12 num fix: 0
PL/SQL procedure successfully completed.
SQL> SELECT object_name, block_id, marked_corrupt
FROM repair_table; 2
OBJECT_NAME BLOCK_ID MARKED_COR
------------------------------ ---------- ----------
FOR_AUDIT 95371 TRUE
Теперь надо найти индексы, ссылающиеся на битый блок:
SQL> select index_name from dba_indexes
where table_name = 'FOR_AUDIT'
and owner = 'ZARPHERSON';
/
2 3
INDEX_NAME
------------------------------
I_FOR_AUDIT_AUDIT_TABLES_ID
I_FOR_AUDIT_AUDIT_USERS_ID
I_FOR_AUDIT_IDKADRY
I_FOR_AUDIT_TIMESTAMP
PK_FOR_AUDIT
SQL> SET serveroutput on
DECLARE num_orphans INT;
BEGIN
num_orphans := 0;
DBMS_REPAIR.DUMP_ORPHAN_KEYS (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'PK_FOR_AUDIT',
OBJECT_TYPE => dbms_repair.index_object,
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
ORPHAN_TABLE_NAME=> 'ORPHAN_KEY_TABLE',
KEY_COUNT => num_orphans);
DBMS_OUTPUT.PUT_LINE('orphan key count: ' || to_char(num_orphans));
END;
/
SQL> 2 3 4 5 6 7 8 9 10 11 12 13 orphan key count: 0
PL/SQL procedure successfully completed.
И так по очереди со всеми. Если "orphan key count: 0", значит все хорошо.
В нашем случае везде был 0.
Однако, если бы что-то было найдено - не беда. Надо просто перестроить индексы.
Ребилдим фрилист таблицы. По сути исключаем битые блоки из доступных:
SQL> BEGIN
DBMS_REPAIR.REBUILD_FREELISTS (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
OBJECT_TYPE => dbms_repair.table_object);
END;
/
2 3 4 5 6 7
PL/SQL procedure successfully completed.
Ну и делаем блоки невидимыми для DML операций:
SQL> BEGIN
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
OBJECT_TYPE => dbms_repair.table_object,
FLAGS => dbms_repair.skip_flag);
END;
/
2 3 4 5 6 7 8
PL/SQL procedure successfully completed.
Проверяем, что для данной таблицы битые блоки будут исключаться из операций:
SQL> SELECT owner, table_name, skip_corrupt
FROM dba_tables
WHERE owner = 'ZARPHERSON'
AND skip_corrupt = 'ENABLED'; 2 3 4
OWNER TABLE_NAME SKIP_COR
------------------------------ ------------------------------ --------
ZARPHERSON FOR_AUDIT ENABLED
Что имеем в итоге - таблицу можно использовать, но проблема не устранена. Блок то битый остался, мы просто наворотили для него механизм невидимости. Но при этом если повторно сделать валидацию структуры - ничего не поменялось. Нам повезло в одном - это таблица аудита. Со всеми вытекающими. В нашем случае делаем так:
connect zarpherson@main
create table for_audit_tmp
as select * from for_audit;
truncate table for_audit;
insert into for_audit
select * from for_audit_tmp;
truncate table for_audit_tmp;
commit;
Делаем анализ структуры и видим:
SQL> ANALYZE TABLE zarpherson.for_audit VALIDATE STRUCTURE CASCADE;
Table analyzed.
То есть битый блок исчез. Ну а теперь же надо вернуть все в зад, чтоб битые блоки не пропускались при DML операциях... Дальше учитывайте, что в REPAIR_TABLE у нас только одна запись!!!
SQL> truncate table repair_table;
Table truncated.
SQL> SET serveroutput on
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
corrupt_count => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;SQL> 2 3 4 5 6 7 8 9 10
11 /
number corrupt: 1
PL/SQL procedure successfully completed.
SQL> SELECT object_name, block_id, corrupt_type, marked_corrupt,
corrupt_description, repair_description
FROM repair_table; 2 3
OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR
------------------------------ ---------- ------------ ----------
CORRUPT_DESCRIPTION
--------------------------------------------------------------------------------
REPAIR_DESCRIPTION
--------------------------------------------------------------------------------
FOR_AUDIT 98250 6148 TRUE
mark block software corrupt
АЧЧЧЧЧПУЕЕЕЕЕТЬ!!!!!
Откуда, мля, я же только проверил, НИЧЕГО НЕ БЫЛО!!!!!
SQL> ANALYZE TABLE zarpherson.for_audit VALIDATE STRUCTURE CASCADE;
Table analyzed.
А-а-а-а-а-а!!! АЧПУЕТЬ АЧПУЕННЕЕ ЧЕМ АЧПУЕЛ!!! КАК???!!!
Та-а-а-ак...
INSERT INTO for_audit_tmp SELECT * FROM for_audit;
DROP TABLE for_audit
/
CREATE TABLE for_audit
(timestamp DATE,
user_name VARCHAR2(30),
table_name VARCHAR2(30),
action VARCHAR2(1),
data_values VARCHAR2(2000),
id NUMBER ,
audit_tables_id NUMBER,
audit_users_id NUMBER,
idkadry NUMBER)
PCTFREE 10
PCTUSED 40
INITRANS 1
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 223846400
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
NOCACHE
NOMONITORING
NOPARALLEL
LOGGING
/
-- Grants for Table
GRANT SELECT ON for_audit TO zp_zarpherson_buh_bez_prop
/
GRANT SELECT ON for_audit TO zp_zarpherson_operator
/
GRANT SELECT ON for_audit TO zp_zarpherson_buhdostup
/
GRANT SELECT ON for_audit TO zp_zarpherson_buhgalter
/
GRANT SELECT ON for_audit TO zp_zarpherson_read_only
/
GRANT SELECT ON for_audit TO zp_zarpherson_read_by_podr
/
GRANT SELECT ON for_audit TO zp_zarpherson_buh_bp_by_podr
/
GRANT SELECT ON for_audit TO plan_1
/
GRANT SELECT ON for_audit TO zp_zarpherson_admin
/
GRANT SELECT ON for_audit TO zp_zarpherson_read_only_dostup
/
-- Indexes for FOR_AUDIT
CREATE INDEX i_for_audit_audit_users_id ON for_audit
(
audit_users_id ASC
)
PCTFREE 5
INITRANS 2
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 1048576
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
NOPARALLEL
LOGGING
/
CREATE INDEX i_for_audit_idkadry ON for_audit
(
idkadry ASC
)
PCTFREE 5
INITRANS 2
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 1048576
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
NOPARALLEL
LOGGING
/
CREATE INDEX i_for_audit_timestamp ON for_audit
(
timestamp ASC
)
PCTFREE 5
INITRANS 2
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 1048576
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
NOPARALLEL
LOGGING
/
CREATE INDEX i_for_audit_audit_tables_id ON for_audit
(
audit_tables_id ASC
)
PCTFREE 5
INITRANS 2
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 1048576
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
NOPARALLEL
LOGGING
/
-- Constraints for FOR_AUDIT
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_action CHECK (ACTION IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_audit_tables_id CHECK (audit_tables_id IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_data_values CHECK (DATA_VALUES IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_table_name CHECK (TABLE_NAME IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_timestamp CHECK (TIMESTAMP IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT nn_for_audit_user_name CHECK (USER_NAME IS NOT NULL)
/
ALTER TABLE for_audit
ADD CONSTRAINT pk_for_audit PRIMARY KEY (id)
USING INDEX
PCTFREE 5
INITRANS 2
MAXTRANS 255
TABLESPACE zarplata
STORAGE (
INITIAL 2097152
NEXT 262144
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
)
/
-- Triggers for FOR_AUDIT
CREATE OR REPLACE TRIGGER tr_for_audit_bi
BEFORE
INSERT
ON for_audit
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
:new.timestamp := SYSDATE;
:new.user_name := USER;
BEGIN
SELECT id
INTO :new.audit_users_id
FROM audit_users
WHERE user_name = user;
EXCEPTION
WHEN no_data_found THEN
INSERT INTO audit_users(user_name)
VALUES(USER)
RETURNING id INTO :new.audit_users_id;
END;
BEGIN
SELECT id
INTO :new.audit_tables_id
FROM audit_tables
WHERE table_name = :new.table_name;
EXCEPTION
WHEN no_data_found THEN
INSERT INTO audit_tables(date_start, date_end, table_name)
VALUES(trunc(sysdate), to_date('01013000', 'ddmmyyyy'), :new.table_name)
RETURNING id INTO :new.audit_tables_id;
END;
SELECT sq_for_audit.nextval
INTO :new.id
FROM dual;
END;
/
-- Comments for FOR_AUDIT
COMMENT ON TABLE for_audit IS 'Таблица с информацией о действиях пользователя над данными'
/
COMMENT ON COLUMN for_audit.action IS 'Действие:
U - UPDATE
I - INSERT
D - DELETE'
/
COMMENT ON COLUMN for_audit.audit_tables_id IS 'Идентификатор таблицы из AUDIT_TABLES'
/
COMMENT ON COLUMN for_audit.audit_users_id IS 'Идентификатор пользователя из AUDIT_USERS'
/
COMMENT ON COLUMN for_audit.data_values IS 'Значение до действия над данными и после'
/
COMMENT ON COLUMN for_audit.id IS 'Идентификатор записи'
/
COMMENT ON COLUMN for_audit.idkadry IS 'Идентификатор работника из T_KADRY'
/
COMMENT ON COLUMN for_audit.table_name IS 'Наименование таблицы'
/
COMMENT ON COLUMN for_audit.timestamp IS 'Дата '
/
COMMENT ON COLUMN for_audit.user_name IS 'Имя пользователя'
/
-- End of DDL Script for Table ZARPHERSON.FOR_AUDIT
-- Foreign Key
ALTER TABLE for_audit
ADD CONSTRAINT fk_for_audit_audit_tables_id FOREIGN KEY (audit_tables_id)
REFERENCES audit_tables (id)
/
-- End of DDL script for Foreign Key(s)
Проверяем, кто тут поц:
SQL> truncate table repair_table;
Table truncated.
SQL> SET serveroutput on
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
corrupt_count => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;SQL> 2 3 4 5 6 7 8 9 10
11 /
number corrupt: 0
PL/SQL procedure successfully completed.
НИКОГО!!! А вот так:
conn zarpherson
insert into for_audit
select * from for_audit_tmp;
commit;
conn sys as sysdba
SQL> SET serveroutput on
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'ZARPHERSON',
OBJECT_NAME => 'FOR_AUDIT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
corrupt_count => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;SQL> 2 3 4 5 6 7 8 9 10
11 /
number corrupt: 1
PL/SQL procedure successfully completed.
SQL>
SQL> SELECT object_name, block_id, corrupt_type, marked_corrupt,
corrupt_description, repair_description
FROM repair_table; 2 3
OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR
------------------------------ ---------- ------------ ----------
CORRUPT_DESCRIPTION
--------------------------------------------------------------------------------
REPAIR_DESCRIPTION
--------------------------------------------------------------------------------
FOR_AUDIT 98250 6148 TRUE
mark block software corrupt
И хрен его знает, кто тут поц и где тут подлива... Таблица пересоздана, и при этом при внесении в нее данных ломается тот же самый блок... При этом валидация структуры проходит нормально...
Ладно, ждем перезапуска базы и анализа всех объектов по счедулеру. А пока проверим, а все ли объекты проходят валидацию структуры???:
set trimspool on
set pagesize 0
set heading off
spool _tmp_1.sql
select 'ANALYZE TABLE '||owner||'.'||table_name||' VALIDATE STRUCTURE CASCADE;'
from dba_tables
where owner not in ('SYS','OUTLN','SYSTEM')
order by owner, table_name;
spool off
@_tmp_1.sql
И вот что в результате надыбал:
ANALYZE TABLE COUNTERSREAD.OSTABLE VALIDATE STRUCTURE CASCADE
*
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file
Из trace file
** 2014-12-08 12:10:13.037
*** SESSION ID:(44.1327) 2014-12-08 12:10:13.037
row not found in index tsn: 9 rdba: 0x03414909
env: (scn: 0x0000.018348c7 xid: 0x0000.000.00000000 uba: 0x00000000.0000.00)col 0; len 8; (8): 34 37 30 35 35 37 32 37
col 1; len 6; (6): 03 01 90 ef 00 09
Block header dump: 0x030190ef
Object id on Block? Y
seg/obj: 0x29ce csc: 0x00.12365be itc: 1 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
и куча мути дальше, похожей да дамп куска области памяти.
По нескольким объектам валидация не прошла, потому что ORA-00054: resource busy and acquire with NOWAIT specified
Читать далее
2014-11-05
PostgreSQL ERROR: could not access status of transaction
Давича на версии 8.2.23 получили мы такую вот хрень:
postgres@cn:~> psql
psql (9.2.4, сервер 8.2.23)
ПРЕДУПРЕЖДЕНИЕ: psql имеет версию 9.2, а сервер - 8.2.
Часть функций psql может не работать.
Введите "help", чтобы получить справку.
postgres=# \c cndata
psql (9.2.4, сервер 8.2.23)
ПРЕДУПРЕЖДЕНИЕ: psql имеет версию 9.2, а сервер - 8.2.
Часть функций psql может не работать.
Вы подключены к базе данных "cndata" как пользователь "postgres".
cndata=# vacuum analyze pp_movement;
ERROR: relation "pp_movement" does not exist
cndata=# vacuum analyze cn.pp_movement;
ERROR: could not access status of transaction 655427477
ПОДРОБНОСТИ: Could not open file "pg_clog/0271": Нет такого файла или каталога.
cndata=# reindex table cn.pp_movement;
ERROR: could not access status of transaction 655427477
ПОДРОБНОСТИ: Could not open file "pg_clog/0271": Нет такого файла или каталога.
Предпосылок к возникновению такой фигни на сервере не нашли. Поэтому побродив по просторам интернета полечили таким вот способом:
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0271 bs=256K count=1
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000657219 s, 399 MB/s
cn:/opt/pgsql-8.2/data/pg_clog # chown postgres:postgres 0271
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 3332701758
ПОДРОБНОСТИ: Could not open file "pg_clog/0C6A": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0C6A bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000499456 s, 525 MB/s
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 57351653
ПОДРОБНОСТИ: Could not open file "pg_clog/0036": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0036 bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000472071 s, 555 MB/s
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 1653895707
ПОДРОБНОСТИ: Could not open file "pg_clog/0629": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0629 bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000490669 s, 534 MB/s
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 4102869982
ПОДРОБНОСТИ: Could not open file "pg_clog/0F48": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0F48 bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000469307 s, 559 MB/s
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 3931397121
ПОДРОБНОСТИ: Could not open file "pg_clog/0EA5": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0EA5 bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000490203 s, 535 MB/s
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 309829755
ПОДРОБНОСТИ: Could not open file "pg_clog/0127": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0127 bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000480744 s, 545 MB/s
cndata=# select count(*) from cn.pp_movement;
count
---------
1308439
(1 строка)
Походу потеряли часть транзакций, но все заработало.
Пора валить на 9-ю версию...
Читать далее
postgres@cn:~> psql
psql (9.2.4, сервер 8.2.23)
ПРЕДУПРЕЖДЕНИЕ: psql имеет версию 9.2, а сервер - 8.2.
Часть функций psql может не работать.
Введите "help", чтобы получить справку.
postgres=# \c cndata
psql (9.2.4, сервер 8.2.23)
ПРЕДУПРЕЖДЕНИЕ: psql имеет версию 9.2, а сервер - 8.2.
Часть функций psql может не работать.
Вы подключены к базе данных "cndata" как пользователь "postgres".
cndata=# vacuum analyze pp_movement;
ERROR: relation "pp_movement" does not exist
cndata=# vacuum analyze cn.pp_movement;
ERROR: could not access status of transaction 655427477
ПОДРОБНОСТИ: Could not open file "pg_clog/0271": Нет такого файла или каталога.
cndata=# reindex table cn.pp_movement;
ERROR: could not access status of transaction 655427477
ПОДРОБНОСТИ: Could not open file "pg_clog/0271": Нет такого файла или каталога.
Предпосылок к возникновению такой фигни на сервере не нашли. Поэтому побродив по просторам интернета полечили таким вот способом:
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0271 bs=256K count=1
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000657219 s, 399 MB/s
cn:/opt/pgsql-8.2/data/pg_clog # chown postgres:postgres 0271
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 3332701758
ПОДРОБНОСТИ: Could not open file "pg_clog/0C6A": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0C6A bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000499456 s, 525 MB/s
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 57351653
ПОДРОБНОСТИ: Could not open file "pg_clog/0036": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0036 bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000472071 s, 555 MB/s
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 1653895707
ПОДРОБНОСТИ: Could not open file "pg_clog/0629": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0629 bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000490669 s, 534 MB/s
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 4102869982
ПОДРОБНОСТИ: Could not open file "pg_clog/0F48": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0F48 bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000469307 s, 559 MB/s
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 3931397121
ПОДРОБНОСТИ: Could not open file "pg_clog/0EA5": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0EA5 bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000490203 s, 535 MB/s
cndata=# select count(*) from cn.pp_movement;
ERROR: could not access status of transaction 309829755
ПОДРОБНОСТИ: Could not open file "pg_clog/0127": Нет такого файла или каталога.
cn:/opt/pgsql-8.2/data/pg_clog # dd if=/dev/zero of=0127 bs=256K count=1; chown postgres:postgres *
1+0 records in
1+0 records out
262144 bytes (262 kB) copied, 0.000480744 s, 545 MB/s
cndata=# select count(*) from cn.pp_movement;
count
---------
1308439
(1 строка)
Походу потеряли часть транзакций, но все заработало.
Пора валить на 9-ю версию...
Читать далее
2014-10-02
ORA-00354: corrupt redo log block heade
2014.10.02
Техническая
информация:
Операционная
система: SuSE Linux Enterprise Server 8 Service Pack 3 32bit
БД: Oracle Enterprise Server
8.1.7.4 32bit
Дополнительная
информация: Указанная проблема возникала
ранее 1 раз - 28.08.2014.
Симптомы
проблемы:
1.
При подключении к ПО «Финколлекции»
выдается ошибка о невозможности
подключения в связи с невозможностью
произвести архивирование журналов
транзакций (Connect Internal Only until freed).
2.
В файле /u01/admin/main/bdump/alert_main.log множественные
сообщения (аналогичные указанному с
учетом того, что могут быть другие даты
и имена файлов):
Thu
Oct 2 00:04:11 2014
ARC0:
Beginning to archive log# 7 seq# 16005
ARC0:
Archiving not possible: No primary destinations
ARC0:
Failed to archive log# 7 seq# 16005
Описание
проблемы:
В журнале транзакций,
находящемся в группе 7 обнаружен
поврежденный блок данных, в результате
чего операции с данным журналом транзакций
невозможны.
Причины
возникновения проблемы:
Причины возникновения
неясны. Предположительно связано с
устаревшей версией БД Oracle. При анализе
возникновения ошибки была проведена
проверка файловой системы сервера,
анализ журналов работы системы. Никаких
предпосылок к возникновению проблемы
обнаружено не было.
Методика
решения:
adonis:/u01/admin/main/bdump #
su - oracle
oracle@adonis:~> export
ORACLE_SID=main
oracle@adonis:~> svrmgrl
SVRMGR> connect internal
Connected.
SVRMGR> shutdown abort
ORACLE instance shut down.
SVRMGR> startup
ORACLE instance started.
Total System Global Area
1726288032 bytes
Fixed Size
73888 bytes
Variable Size
250187776 bytes
Database Buffers
1475198976 bytes
Redo Buffers
827392 bytes
Database mounted.
ORA-16038: log 7 sequence#
16005 cannot be archived
ORA-00354: corrupt redo log
block header
ORA-00312: online log 7 thread
1: '/u02/oradata/main/redo07_01.rdo'
ORA-00312: online log 7 thread
1: '/u03/oradata/main/redo07_02.rdo'
SVRMGR> alter database
clear unarchived logfile group 7;
Statement processed.
SVRMGR> alter database drop
logfile group 7;
Statement processed.
SVRMGR> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SVRMGR> startup
ORACLE instance started.
Total System Global Area
1726288032 bytes
Fixed Size
73888 bytes
Variable Size
250187776 bytes
Database Buffers
1475198976 bytes
Redo Buffers
827392 bytes
Database mounted.
Database opened.
SVRMGR>
Замечания
после устранения:
Во время решения
проблемы была удалена группа журналов
транзакций №7. Восстанавливаем ее. Не
покидая консоль, открытую в пункте
«Методика решения», выполняем:
SVRMGR> !
oracle@adonis:~> rm -v
/u02/oradata/main/redo07_01.rdo
removed
`/u02/oradata/main/redo07_01.rdo'
oracle@adonis:~> rm -v
/u03/oradata/main/redo07_02.rdo
removed
`/u03/oradata/main/redo07_02.rdo'
oracle@adonis:~> exit
exit
SVRMGR> ALTER DATABASE ADD
LOGFILE GROUP 7
('/u02/oradata/main/redo07_01.rdo',
'/u03/oradata/main/redo07_02.rdo')
SIZE 10240K REUSE
/ 2> 3> 4>
Statement processed.
SVRMGR>
Кроме того, цепочка
архивных журналов транзакций в результате
невозможности архивирования группы 7
была разорвана. В случае необходимости
проведения восстановления БД с
использованием журналов за период
времени, включающий поломку, операция
восстановления будет невозможна.
Читать далее
2014-08-18
Приколы с конфигурированием cyrus-imapd
После долгих мучений с применением параметров с конфигурационных файлах cyrus-imapd выяснилось:
Если ты в конфигурационном файле /etc/imapd.conf изменил значение параметра, то последующее комментирование данного параметра не вернет его в значение по умолчанию. По крайней мере это касается версии 2.4.17. Если тебе нужно для параметра поставить другое значение, его нужно прописывать явно. Иначе будет работать установленное в последний раз.
Читать далее
Если ты в конфигурационном файле /etc/imapd.conf изменил значение параметра, то последующее комментирование данного параметра не вернет его в значение по умолчанию. По крайней мере это касается версии 2.4.17. Если тебе нужно для параметра поставить другое значение, его нужно прописывать явно. Иначе будет работать установленное в последний раз.
Читать далее
2014-07-22
Ну мля чем еще админу заняться???
Принес директор ноут, что-то греется, говорит. И не важно, что у нас нет никого, кто имеет опыт сборки разборки - надо сделать.
Порыл инет, нашел инструкции:
1. http://ander.su/repair/article/15/1
2. http://people.overclockers.ru/vGamBIT/17624/Chistka_ot_pyli_i_zamena_termopasty_na_Acer_Aspire_5750G/
3. http://draber.pp.ua/?p=910
4. http://habrahabr.ru/post/140120/
Вооружившись отвертками, все сделал. Разбирать пришлось, правда, 2 раза.
Собственно и не писал бы, но вдруг опять тот же ноут принесут, а у меня ссылки остались :)
Читать далее
Порыл инет, нашел инструкции:
1. http://ander.su/repair/article/15/1
2. http://people.overclockers.ru/vGamBIT/17624/Chistka_ot_pyli_i_zamena_termopasty_na_Acer_Aspire_5750G/
3. http://draber.pp.ua/?p=910
4. http://habrahabr.ru/post/140120/
Вооружившись отвертками, все сделал. Разбирать пришлось, правда, 2 раза.
Собственно и не писал бы, но вдруг опять тот же ноут принесут, а у меня ссылки остались :)
Читать далее
2014-05-19
XenServer + NTP = unreal offset!!! Постоянный рассинхрон времени ВМ на XenServer 6.2
Имеем проблему - виртуалки на XenServer постоянно сбиваются по времени. Не все, но некоторые.
На XenServer настроен ntp, он работает, время корректное. Каждая ВМ настроена на синхронизацию времени с гипервизором и с NTP сервером. Но несмотря на это периодически время сбивается. Если NTP пнешь руками - ситуация исправляется, но ненадолго. До смешного - передернул NTP, время исправилось, через 15 секунд опять сбилось на 1-2 минуты.
В предыдущем посте писал насчет проверки через nagios plugin check_ntp_time. Все что там написано - актуально. К этому добавляем следующее.
В /etc/sysctl.conf добавляем строку
xen.independent_wallclock = 1
и перезапускаем хост.
Есть подозрение, что поймут эту инструкцию только хосты, где работают XenServer Tools, но и то гуд.
Читать далее
На XenServer настроен ntp, он работает, время корректное. Каждая ВМ настроена на синхронизацию времени с гипервизором и с NTP сервером. Но несмотря на это периодически время сбивается. Если NTP пнешь руками - ситуация исправляется, но ненадолго. До смешного - передернул NTP, время исправилось, через 15 секунд опять сбилось на 1-2 минуты.
В предыдущем посте писал насчет проверки через nagios plugin check_ntp_time. Все что там написано - актуально. К этому добавляем следующее.
В /etc/sysctl.conf добавляем строку
xen.independent_wallclock = 1
и перезапускаем хост.
Есть подозрение, что поймут эту инструкцию только хосты, где работают XenServer Tools, но и то гуд.
Читать далее
2014-05-08
ntp, nagios check_ntp_time, версии, заковыки, проблемы...
Начались у нас в конторе проблемы с синхронизацией времени. Начались, а узнали мы об этом, когда нас из-за этих проблем пришли бить больно. Нас громко сказано - меня.
А почему узнали уже в момент отгребания - а потому что nagios ничего, падла, нам не сказал, чтоб наше внимание привлекло. Все горело зелененьким, приятненьким таким цветом.
А после снятия побоев после отгребания после того как nagios ничего не сказал после того как проблемы уже были херзнаетсколько времени, так вот после всего этого оказалось, что в некоторых случаях плагин check_ntp_time статус показывает так (горит зеленым):
NTP OK: Offset 0.0008825864061 secs
, а в некоторых так(и сука тоже горит зеленым):
NTP OK: Offset unknown
Ну я же не смотрю на зеленое, система мониторинга и нужна падла для того, чтоб привлекать внимание к проблемным местам правильным способом...
Во-о-о-от. А там разбалансы по 10 минут.....
Собственно, в результате было выяснено, что существует незакрытый баг (по крайней мере все так говорят) в этом плагине, который тянется из версии в версию. На данный момент доступна версия 1.5, и в ней баг тоже присутствует.
В ходе разборок было выяснено, что офсет не проверяется на серверах, где версия ntp стоит выше, чем 4.2.4p8-1.3.28, это SuSE Linux Enterprise Server Service Pack 3 64bit (ntp-4.2.4p8-1.22.1.x86_64.rpm)
Проблема была решена понижением версии пакета ntp до ntp-4.2.4p8-1.3.28.
На всякий случай конфиги.
Сервер NTP
server 127.127.1.0
fudge 127.127.1.0 stratum 10
server ua.pool.ntp.org iburst
server pl.pool.ntp.org iburst
server se.pool.ntp.org iburst
server si.pool.ntp.org iburst
server uk.pool.ntp.org iburst
server fi.pool.ntp.org iburst
server ie.pool.ntp.org iburst
server ru.pool.ntp.org iburst
driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp
logconfig =all
disable auth
disable monitor
Клиент NTP (по сути тоже сервер, но время берет из сервера выше, поэтому клиент)
server 127.127.1.0
fudge 127.127.1.0 stratum 10
server 10.77.11.70 prefer iburst
server 10.77.11.8 iburst
server 10.77.1.8 iburst
driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp
logconfig =all
В /etc/sysconfig/ntp присутствует:
NTPD_FORCE_SYNC_ON_STARTUP="yes"
NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP="yes"
Читать далее
А почему узнали уже в момент отгребания - а потому что nagios ничего, падла, нам не сказал, чтоб наше внимание привлекло. Все горело зелененьким, приятненьким таким цветом.
А после снятия побоев после отгребания после того как nagios ничего не сказал после того как проблемы уже были херзнаетсколько времени, так вот после всего этого оказалось, что в некоторых случаях плагин check_ntp_time статус показывает так (горит зеленым):
NTP OK: Offset 0.0008825864061 secs
, а в некоторых так(и сука тоже горит зеленым):
NTP OK: Offset unknown
Ну я же не смотрю на зеленое, система мониторинга и нужна падла для того, чтоб привлекать внимание к проблемным местам правильным способом...
Во-о-о-от. А там разбалансы по 10 минут.....
Собственно, в результате было выяснено, что существует незакрытый баг (по крайней мере все так говорят) в этом плагине, который тянется из версии в версию. На данный момент доступна версия 1.5, и в ней баг тоже присутствует.
В ходе разборок было выяснено, что офсет не проверяется на серверах, где версия ntp стоит выше, чем 4.2.4p8-1.3.28, это SuSE Linux Enterprise Server Service Pack 3 64bit (ntp-4.2.4p8-1.22.1.x86_64.rpm)
Проблема была решена понижением версии пакета ntp до ntp-4.2.4p8-1.3.28.
На всякий случай конфиги.
Сервер NTP
server 127.127.1.0
fudge 127.127.1.0 stratum 10
server ua.pool.ntp.org iburst
server pl.pool.ntp.org iburst
server se.pool.ntp.org iburst
server si.pool.ntp.org iburst
server uk.pool.ntp.org iburst
server fi.pool.ntp.org iburst
server ie.pool.ntp.org iburst
server ru.pool.ntp.org iburst
driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp
logconfig =all
disable auth
disable monitor
Клиент NTP (по сути тоже сервер, но время берет из сервера выше, поэтому клиент)
server 127.127.1.0
fudge 127.127.1.0 stratum 10
server 10.77.11.70 prefer iburst
server 10.77.11.8 iburst
server 10.77.1.8 iburst
driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp
logconfig =all
В /etc/sysconfig/ntp присутствует:
NTPD_FORCE_SYNC_ON_STARTUP="yes"
NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP="yes"
Читать далее
2014-03-20
Linux. Склерозник. Полезные наборы команд.
Рекурсивно подсчитает количество файлов в текущем каталоге и всех вложенных
find . -type f|wc -l
Смотрим изменения в файле в динамике
watch -n 1 -d "egrep 'High|Low' /proc/meminfo"
Делаем локальную копию сайта
wget -r -k -l 7 -p -E -nc http://www.puschitz.com
Установка проски без редактирования конфигов
export http_proxy=http://10.77.111.111:3128
Проверяем, какие слорты ОЗУ на матери заняты, какие свободны:
dmidecode -t memory
Читать далее
find . -type f|wc -l
Смотрим изменения в файле в динамике
watch -n 1 -d "egrep 'High|Low' /proc/meminfo"
Делаем локальную копию сайта
wget -r -k -l 7 -p -E -nc http://www.puschitz.com
Установка проски без редактирования конфигов
export http_proxy=http://10.77.111.111:3128
Проверяем, какие слорты ОЗУ на матери заняты, какие свободны:
dmidecode -t memory
Читать далее
2014-03-12
Автозапуск VM на XenServer 6.2
Как всегда только через консоль...
xe vm-param-set uuid=92c10c64-51cb-5ede-c257-f428b6f291a9 other-config:auto_poweron=true
Читать далее
xe vm-param-set uuid=92c10c64-51cb-5ede-c257-f428b6f291a9 other-config:auto_poweron=true
Читать далее
2014-03-05
Xen Orchestra 3.2 Настройка сети
Из коробки виртуалка Xen Orchestra идет с сетевым интерфейсом, настроенным по DHCP.
Кстати, XOA3 сделан на базе Debian 7
Кто хочет статику, меняете файл /etc/network/interfaces. По умолчанию он такой:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
А у меня он такой:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 10.77.11.8
netmask 255.255.255.0
gateway 10.77.11.62
auto eth0
Читать далее
Кстати, XOA3 сделан на базе Debian 7
Кто хочет статику, меняете файл /etc/network/interfaces. По умолчанию он такой:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
А у меня он такой:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 10.77.11.8
netmask 255.255.255.0
gateway 10.77.11.62
auto eth0
Читать далее
Блокирование трафика с подсети (iptables)
Часто нужно залочить трафик с подсети на какой-то хост.
Делаем просто - на хосту, куда подсеть не должна попасть:
Блокировка диапазона ip
iptables -I INPUT -m iprange --src-range 10.77.1.1-10.77.1.254 -j DROP
Разблокирование диапазона ip
iptables -D INPUT -m iprange --src-range 10.77.1.1-10.77.1.254 -j DROP
Или аналогично с маской:
iptables -A INPUT -s 10.77.1.0/24 -j DROP
iptables -D INPUT -s 10.77.1.0/24 -j DROP
Читать далее
Делаем просто - на хосту, куда подсеть не должна попасть:
Блокировка диапазона ip
iptables -I INPUT -m iprange --src-range 10.77.1.1-10.77.1.254 -j DROP
Разблокирование диапазона ip
iptables -D INPUT -m iprange --src-range 10.77.1.1-10.77.1.254 -j DROP
Или аналогично с маской:
iptables -A INPUT -s 10.77.1.0/24 -j DROP
iptables -D INPUT -s 10.77.1.0/24 -j DROP
Читать далее
2014-03-04
SSH без пароля
Это реально удобно.
Реальная ситуация - есть два сервера, с одного на другой каждую ночь нужно копировать некий файл. Чтобы ничего не монтировать, не настраивать nsf или samba cisf, можно использовать scp, предварительно проведя небольшую настройку.
Итак, первый сервер adonis01. С него будет копироваться файл на второй сервер ora8t1. На обоих серверах динозаврик SLES8SP3(OpenSSH_3.4p1, SSH protocols 1.5/2.0)
ssh root@adonis01
adonis01:~ # ssh-keygen -t rsa -b4096
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
12:23:56:78::ab:cd:ef:12:ee:56:4r:58:e2:d8:d1 root@adonis01
После этого в /root/.ssh появилось 2 файла - id_rsa и id_rsa.pub
adonis01:~ # scp /root/.ssh/id_rsa.pub root@ora8t1:/root/.ssh/id_rsa_adonis01
ssh root@ora8t1
ora8t1:~ # cat /root/.ssh/id_rsa_adonis01 >> /root/.ssh/id_rsa_remote
ora8t1:~ # mcedit /etc/ssh/sshd_config
PermitRootLogin yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/id_rsa_remote
HostbasedAuthentication no
UseLogin no
ChallengeResponseAuthentication no
X11Forwarding yes
UsePrivilegeSeparation no
Subsystem sftp /usr/lib/ssh/sftp-server
ora8t1:~ # /etc/init.d/sshd restart
Все, настроили.
Проверяем
ssh root@adonis01
adonis01:~ # ssh ora8t1 df -hl
Должны получить нужный результат. Все, теперь для scp ничего вводить не надо - все будет работать без паролей.
Читать далее
Реальная ситуация - есть два сервера, с одного на другой каждую ночь нужно копировать некий файл. Чтобы ничего не монтировать, не настраивать nsf или samba cisf, можно использовать scp, предварительно проведя небольшую настройку.
Итак, первый сервер adonis01. С него будет копироваться файл на второй сервер ora8t1. На обоих серверах динозаврик SLES8SP3(OpenSSH_3.4p1, SSH protocols 1.5/2.0)
ssh root@adonis01
adonis01:~ # ssh-keygen -t rsa -b4096
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
12:23:56:78::ab:cd:ef:12:ee:56:4r:58:e2:d8:d1 root@adonis01
После этого в /root/.ssh появилось 2 файла - id_rsa и id_rsa.pub
adonis01:~ # scp /root/.ssh/id_rsa.pub root@ora8t1:/root/.ssh/id_rsa_adonis01
ssh root@ora8t1
ora8t1:~ # cat /root/.ssh/id_rsa_adonis01 >> /root/.ssh/id_rsa_remote
ora8t1:~ # mcedit /etc/ssh/sshd_config
PermitRootLogin yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/id_rsa_remote
HostbasedAuthentication no
UseLogin no
ChallengeResponseAuthentication no
X11Forwarding yes
UsePrivilegeSeparation no
Subsystem sftp /usr/lib/ssh/sftp-server
ora8t1:~ # /etc/init.d/sshd restart
Все, настроили.
Проверяем
ssh root@adonis01
adonis01:~ # ssh ora8t1 df -hl
Должны получить нужный результат. Все, теперь для scp ничего вводить не надо - все будет работать без паролей.
Читать далее
2014-02-26
Старинные меры длины. Визуальненько.
Давно искал хороший склерозник для старинных мер длины. Вот у братухи в одноклассниках выхватил:
Читать далее
Читать далее
2014-02-24
Citrix XenServer 6.2 Изменение количества CPU
Бывает такая фигня - через интерфейс XenCenter невозможно изменить количество CPU. Вот так можно это сделать с консоли
[root@xen11 ~]# xe vm-param-set VCPUs-max=32 uuid=7f905bc6-6d60-65fd-34f5-caa1121deb8f
[root@xen11 ~]# xe vm-param-set VCPUs-at-startup=32 uuid=7f905bc6-6d60-65fd-34f5-caa1121deb8f
[root@xen11 ~]# xe vm-param-set PV-args='console=ttyS0 xencons=ttyS maxcpus=32' uuid=7f905bc6-6d60-65fd-34f5-caa1121deb8f
Читать далее
[root@xen11 ~]# xe vm-param-set VCPUs-max=32 uuid=7f905bc6-6d60-65fd-34f5-caa1121deb8f
[root@xen11 ~]# xe vm-param-set VCPUs-at-startup=32 uuid=7f905bc6-6d60-65fd-34f5-caa1121deb8f
[root@xen11 ~]# xe vm-param-set PV-args='console=ttyS0 xencons=ttyS maxcpus=32' uuid=7f905bc6-6d60-65fd-34f5-caa1121deb8f
Читать далее
2014-02-12
Пинок для оптимизатора PostgreSQL 9.1
Война с базой продолжается.
Вот программисты во время оптимизации запросов нашли набор параметров, который, по их словам, ускорил работу базы просто пипецкакофигенно... Я разницы не заметил, но может я не так смотрю. Параметры добавил в postgresql.conf
join_collapse_limit = 10
seq_page_cost = 0.0000001
random_page_cost = 0.0000001
cpu_operator_cost = 0.0000001
default_statistics_target = 3000
Читать далее
Вот программисты во время оптимизации запросов нашли набор параметров, который, по их словам, ускорил работу базы просто пипецкакофигенно... Я разницы не заметил, но может я не так смотрю. Параметры добавил в postgresql.conf
join_collapse_limit = 10
seq_page_cost = 0.0000001
random_page_cost = 0.0000001
cpu_operator_cost = 0.0000001
default_statistics_target = 3000
Читать далее
2014-02-07
Ловим засранцев на PostgreSQL 9.1, или кто подвесил базу...
У нас такая ситуация часто - какой-то запрос повесил блокировку, из-за которой все остальные запросы жестко сосут. Вот в интернете нашел метод, как таких гадов ловить :
SELECT usename, application_name, client_addr, client_hostname,
NOW() - query_start as s, procpid, current_query, 'pg_ctl kill TERM '||procpid
FROM pg_stat_activity
WHERE current_query NOT IN ('','')
ORDER BY s DESC;
и убивать:
pg_ctl kill TERM сюда_вставить_procid
Читать далее
SELECT usename, application_name, client_addr, client_hostname,
NOW() - query_start as s, procpid, current_query, 'pg_ctl kill TERM '||procpid
FROM pg_stat_activity
WHERE current_query NOT IN ('','
ORDER BY s DESC;
pg_ctl kill TERM сюда_вставить_procid
Читать далее
2014-01-20
CentOS 4.9 на Citrix XenServer 6.2 SP1. Пляски с бубном...
Если бы не необходимость переехать с VMWare ESXi Server на Citrix XenServer 6.2, никаких плясок с бубнами не было бы. А так...
Короче, нужно запустить Oracle 9iR2 на виртуальной машине linux. Как известно, варианта 2 - SLES9 либо CentOS4(или RHEL4). SLES9 на XenServer 6.2 не поддерживается, и не ставится, сука, хотя я и люблю его очень... Но поставить не удалось. Так что вариант 1 - RH4.
Итак, во склерозник по приведению CentOS4 в нормальное состояние для решения моей задачи:
1. Графики на CentOS в виртуальной консоли НЕ БУДЕТ!!! ВЫКУСИТЕ ФСЕ!!! Пипец. Когда ставишь с шаблоном для не поддерживаемых ВМ, графика есть, но есть и проблемы с настройкой ядра и установкой XenTools, а вот из шаблона графики нет. vncserver вам в помощь, хоть он работает... Но, внимание, уровень исполнения д.б. 5, так что редайтируйте inittab, а то замахаетесь руками между уровнями прыгать...
2. После обновления до 4.9 ломается yum, выдает ошибку:
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in ?
yummain.main(sys.argv[1:])
File "/usr/share/yum-cli/yummain.py", line 97, in main
result, resultmsgs = do()
File "/usr/share/yum-cli/cli.py", line 477, in doCommands
return self.updatePkgs()
File "/usr/share/yum-cli/cli.py", line 955, in updatePkgs
self.doRepoSetup()
File "/usr/share/yum-cli/cli.py", line 71, in doRepoSetup
yum.YumBase.doRepoSetup(self, thisrepo=thisrepo)
File "__init__.py", line 225, in doRepoSetup
File "repos.py", line 523, in baseurlSetup
File "repos.py", line 832, in getMirrorList
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 583, in urlopen
return default_grabber.urlopen(url, **kwargs)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 741, in urlopen
return self._retry(opts, retryfunc, url)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 702, in _retry
r = apply(func, (opts,) + args, {})
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 740, in retryfunc
return URLGrabberFileObject(url, filename=None, opts=opts)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 893, in __init__
self._do_open()
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 960, in _do_open
fo, hdr = self._make_request(req, opener)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 1059, in _make_request
fo = opener.open(req)
File "/usr/lib/python2.3/urllib2.py", line 326, in open
'_open', req)
File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain
result = func(*args)
File "/usr/lib/python2.3/urllib2.py", line 502, in
lambda r, proxy=url, type=type, meth=self.proxy_open: \
File "/usr/lib/python2.3/urllib2.py", line 509, in proxy_open
if '@' in host:
TypeError: iterable argument required
Полечить можно только правильно прописав proxy в /etc/yum.conf
Читать далее
Короче, нужно запустить Oracle 9iR2 на виртуальной машине linux. Как известно, варианта 2 - SLES9 либо CentOS4(или RHEL4). SLES9 на XenServer 6.2 не поддерживается, и не ставится, сука, хотя я и люблю его очень... Но поставить не удалось. Так что вариант 1 - RH4.
Итак, во склерозник по приведению CentOS4 в нормальное состояние для решения моей задачи:
1. Графики на CentOS в виртуальной консоли НЕ БУДЕТ!!! ВЫКУСИТЕ ФСЕ!!! Пипец. Когда ставишь с шаблоном для не поддерживаемых ВМ, графика есть, но есть и проблемы с настройкой ядра и установкой XenTools, а вот из шаблона графики нет. vncserver вам в помощь, хоть он работает... Но, внимание, уровень исполнения д.б. 5, так что редайтируйте inittab, а то замахаетесь руками между уровнями прыгать...
2. После обновления до 4.9 ломается yum, выдает ошибку:
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in ?
yummain.main(sys.argv[1:])
File "/usr/share/yum-cli/yummain.py", line 97, in main
result, resultmsgs = do()
File "/usr/share/yum-cli/cli.py", line 477, in doCommands
return self.updatePkgs()
File "/usr/share/yum-cli/cli.py", line 955, in updatePkgs
self.doRepoSetup()
File "/usr/share/yum-cli/cli.py", line 71, in doRepoSetup
yum.YumBase.doRepoSetup(self, thisrepo=thisrepo)
File "__init__.py", line 225, in doRepoSetup
File "repos.py", line 523, in baseurlSetup
File "repos.py", line 832, in getMirrorList
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 583, in urlopen
return default_grabber.urlopen(url, **kwargs)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 741, in urlopen
return self._retry(opts, retryfunc, url)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 702, in _retry
r = apply(func, (opts,) + args, {})
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 740, in retryfunc
return URLGrabberFileObject(url, filename=None, opts=opts)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 893, in __init__
self._do_open()
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 960, in _do_open
fo, hdr = self._make_request(req, opener)
File "/usr/lib/python2.3/site-packages/urlgrabber/grabber.py", line 1059, in _make_request
fo = opener.open(req)
File "/usr/lib/python2.3/urllib2.py", line 326, in open
'_open', req)
File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain
result = func(*args)
File "/usr/lib/python2.3/urllib2.py", line 502, in
lambda r, proxy=url, type=type, meth=self.proxy_open: \
File "/usr/lib/python2.3/urllib2.py", line 509, in proxy_open
if '@' in host:
TypeError: iterable argument required
Полечить можно только правильно прописав proxy в /etc/yum.conf
Читать далее
Подписаться на:
Сообщения (Atom)
