Shulou(Shulou.com)06/01 Report--

Environment: VSPHERE5.5+ stand-alone oracle 11G database

Phenomenon: open the vcenter server console, enter the password, the card does not respond in the welcome interface, and the client can not log in normally.

Not even a normal restart. Because the virtual machine where the VC is located is a stand-alone disk, it cannot make a snapshot and cannot prepare for the current state.

Check the WINDOWS system log and find that there may be a hardware problem.

This is an offset and does not mean that there is a problem with the hardware. It is suspected that there is a problem with the database connected to VC. Log in and check.

1. Log in 11.15.146.2

First check the database process, normal.

2. Check the alarm log of the database and find a problem.

This is actually a relatively common mistake. Generally speaking, log groups are switched when the log is full, which triggers a checkpoint,DBWR to write dirty blocks in memory to the data file. As long as the log group is not finished, the log group will not be released. If archiving mode is turned on, it will also be accompanied by the ARCH write archiving process. If the redolog is generated too fast, when the CPK or archiving is not completed, and the LGWR has already filled the rest of the log group and is about to write redolog to the current log group, a conflict will occur and the database will be suspended. And will always write an error message similar to the above in alert.log.

Analyze the reasons:

The server has three log groups G 1, G 2, G 3. When G1 is finished, write to G2, which requires archiving and checkpoint. Then the other two log groups continue to write. When both G2 and G3 are written, you have to write to G1, but the problem is that G1 has not yet completed the archiving and checkpoint operations. So then the police will be called.

Solution:

Add a few more log groups, and each log group has a little more space, which slows down time and leaves G1 plenty of time to complete archiving and checkpoint tasks. There will be no misreporting.

Procedure:

First check the log group status of the database

View online log groups: SQL > select * from v$log

View the members of the log group: SQL > select * from v$logfile

View the specific status of the log group: SQL > select group#,sequence#,bytes,members,status from v$log

GROUP# SEQUENCE# BYTES MEMBERS STATUS

1 28825 52428800 1 INACTIVE

2 28826 52428800 1 ACTIVE

3 28827 52428800 1 CURRENT

CURRENT: indicates the current log.

INACTIVE: dirty data has been written to the data block. This state can be drop.

ACTIVE: dirty data has not been written to the data block.

The log is only 50m too small.

Expand the log group size

SQL > alter database add logfile group 4 ('/ u01ax size size 500m)

Database altered.

SQL > alter database add logfile group 5 ('/ u01ax size) size 500m

Database altered.

SQL > alter database add logfile group 6 ('/ u01ax size size 500m)

Database altered.

Toggle log group

SQL > alter system switch logfile

System altered.

SQL > alter system switch logfile

System altered.

Note: the difference between alter system switch logfile and alter system archive log current.

Alter system switch logfile is switch logfile without waiting for the archive to be completed. If database does not have archive log mode enabled. Then there is no doubt about using this switch. In addition, log switching is also performed for the current instance in single instance database and RAC mode.

Alter system archive log current, on the other hand, needs to wait for the archiving to complete before switch logfile. Log switching is performed on all of these instances.

Overall, in the automatic archiving library, the results of the two commands are almost the same. The difference is that alter system archive log current takes longer than alter system switch logfile.

Delete log group

SQL > alter database drop logfile group 1

Database altered.

SQL > alter database drop logfile group 2

Database altered.

SQL > alter database drop logfile group 3

Database altered.

Note that log groups and log group members are deleted:

Principle: before deletion, you must abide by the following principle: each instance must have at least two log groups; when a group is in the state of ACTIVE or CURRENT, it cannot be deleted; the operation of deleting a log group only changes the database, and the files of the operating system have not been deleted; when the DROP LOGFILE GROUP N statement is applied when deleting, all members in GROUP N will be deleted.

ALTER DATABASE DROP LOGFILE GROUP N

Change in the status of the log group:

SQL > select group#,sequence#,bytes,members,status from v$log

GROUP# SEQUENCE# BYTES MEMBERS STATUS

--

1 201268 2147483648 1 CURRENT

2 201263 2147483648 1 ACTIVE

3 201264 2147483648 1 ACTIVE

4 201267 524288000 1 ACTIVE

5 201265 524288000 1 ACTIVE

6 201266 524288000 1 ACTIVE

SQL > ALTER SYSTEM CHECKPOINT

SQL > select group#,sequence#,bytes,members,status from v$log

GROUP# SEQUENCE# BYTES MEMBERS STATUS

--

1 201268 2147483648 1 CURRENT

2 201263 2147483648 1 INACTIVE

3 201264 2147483648 1 INACTIVE

4 201267 524288000 1 INACTIVE

5 201265 524288000 1 INACTIVE

6 201266 524288000 1 INACTIVE

The principle for deleting log members: when you delete a member that is the last member in the group, you cannot delete this member; when the turntable of the group is in the state of current, you cannot delete the group member; in archive mode, you must archive before deleting; the operation of deleting the log group member only changes the database, and the files of the operating system have not been deleted.

Delete the log group and then delete the corresponding log files, such as redo01.log

SQL >! rm / u01/app/oracle/oradata/pvdb/redo01.log

SQL > alter system switch logfile

System altered.

SQL > select group#,sequence#,bytes,members,status from v$log

GROUP# SEQUENCE# BYTES MEMBERS STATUS

4 28828 524288000 1 INACTIVE

5 28829 524288000 1 ACTIVE

6 28830 524288000 1 CURRENT

Finally, after cutting the log group, observe that the new REDO log group has been applied, the database is normal, there is no alarm in the database log, and the problem is solved.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.