Log segment for recovery

[Former Member]

Hi All,

We have two systems A and B

We are trying to restore and recover PIT using A's backup and archived log files into B.

Now the question i have is that do i need to copy the stuff under these as well and place into B?

hostname:/hana/log/SID/mnt00001/hdb00004> ls -1

__DO_NOT_TOUCH_FILES_IN_THIS_DIRECTORY__

logsegment_000_00000000.dat

logsegment_000_00000001.dat

logsegment_000_00000002.dat

logsegment_000_directory.dat

[Former Member · Accepted solution]

If we check the admin guide it says this.

This recovery option uses the following data:○

The last data backup or storage snapshot available before the specified point in time (File, Backint, or storage snapshot)○

Log backups made since the data backup to be used (including the log backups made after the desired point in time of the recovery)○

Log areaNote

[Former Member · Accepted solution]

Hi,

Do not think logsegment data files under /hana/log/SID/mnt0000X/hdb000Y/ are necessary for the recovery when you are recovering a HANA system other than the source

HANA will need the Data backup and the subsequent log backups to make a PIT recovery

It is highly possible HANA may not recover to a certain PIT although you notice the log backups until that point of time, the reason is not all services may have their log backups upto that point

I have noticed this a few times and had to choose PIT accordingly

Hope this helps

Sunil

[Former Member · Accepted solution]

Hi Sunil,

Thanks a ton for the response, if you check the admin guide you would be knowing that there is a section where it tells to copy the log area. Since those are the active logs.

[Former Member · Accepted solution]

Your requirement is to recover the HANA system B upto point in time using the backups from HANA System A; right?

I beleive you are referring to the below screenshot from the latest HANA Administration guide under section 5.2.5.2.1: Recover a Database to its most recent state or to a Point in time can you confirm?

[Former Member · Accepted solution]

Hi Sunil,

Right on the point. Correct it mentions the log area right.

[Former Member · Accepted solution]

You have been looking at section 5.2.5.2.1: Recover a Database to is most recent state or to a point in time

But you need to recover a HANA system B to point in time using backups from HANA system A

You should be looking at the section 5.2.6.2 Copy a Database to a point in time using File based backups or Storage snapshots

Here you will see the comments under the pre requisite section to make data and log backups from source Database made available in the appropriate directory

You definitely do not need log segments from the source system to recover the destination system point in time

Hope this helps

Sunil

[Former Member · Accepted solution]

Its not about needing, i was checking since i didnt want to miss any data in the active logs. So thats the reason was asking if there is a way to do it.

[Former Member · Accepted solution]

Is it clear that you cannot use the active HANA Log segments from Source A to Destination B recovery?

The PIT recovery is carried out using the Data and log backups from source and all committed data at the source hardened on the log file will be available for the recovery

Is your question answered?

Sunill

[Former Member · Accepted solution]

Hi Sunil,

Since you have said it cannot be used, probably yes.

Also if i had to use it on the same system i can use the log segments and also what would be option to use end of logs recovery rather than using a time stamp?

[Former Member · Accepted solution]

If you are recovering it to the same system the below option 1, will make use of the log segments and help recover the HANA system to the most recent state

1. *Recover the database to its most recent state*

2. Recover the database to a specific point in time

3. Recover the Database to a specific data backup

Sunil

[Former Member · Accepted solution]

Sunil,

I was looking for something like in other databases. End of logs recovery rather than using the recovery every time using PIT time.

[Former Member · Accepted solution]

Yes and I mentioned use the option 1 for this

1. Recover the Database to its most recent state

This is different from Option 2. Recover the database to a specific point in time

Option 1 will proceed with the recovery of the Database until the most recent state with the help of the log segments

Sunil

[Former Member · Accepted solution]

As per Admin Guide SPS09, this would not be the option as you would have to Initialize the log area (please see my latest answer with the referenced page). I don't think SPS10 changed that.

[Former Member]

You dont need those.

[Former Member]

Pavan before making a conclusion can you please let me know as to why when its mentioned in the guide.

[Former Member]

it all depends on you RPO (recovery point objective).

If you want to restore your B to the last logback up, it means all your committed transactions since the last log backup (which are stored in log area) will be lost.

If you want to recover your database to the most recent consistent state (to teh last committed transaction), you need to restore data backup, apply log backups, AND play forward the redo logs that are in the log area.

you can also use hdbbackupdiag or Backup editor, which should tell you what files you will need for your recovery.

[Former Member]

Hi Liz,

Thanks a ton for your response.

One question, is there a way to use the log segments from system A into system B to recover to all the logs.

[Former Member]

I just realized what you are asking (well I think so).

If you are doing recovery on the same system - you can replay your log area and restore to the most recent consistent state.

If you are doing system refresh (that's what you imply by moving A to B I guess), then NO. The only thing you can do is apply databackup, log backup and you MUST INITIALIZE your log area which means log area will be delted. This is the same scenario when your log area is unusable and you have to recover your database by applying data backup, log backup and INITIALIZE the log area so that it is not played forwarded during recovery.

That's a good question btw.

Here is a snapshot from Admin Guide where they talk about system copy (p 644)

Oh, if that helps, I would love a point