on 10-20-2014 10:05 PM
Hi team,
I have a doubt , when compared to traditional databases like oracle, db6 and sybase. we have a different data and log file systems.
Here in HANA why is it the same any reason or else any recomendation from SAP since its designed like this.
In many customers i have seen the backups for logs and data in the same file system , i am not sure about the logic. May be some reasoning behind this.
Message was edited by: Tom Flanagan
Is it really the same? SAP HANA has two parameters that specify the data and log location. There is the parameter basepath_datavolumes and the parameter basepath_logvolumes. They should not point to the same file system.
What appliance or system do you have?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hay,
I am aware of what you are talking.
global.ini:basepath_logbackup
global.ini:basepath_databackup
First i would like to clarify my question, the question was the backup destinations on the disk there are on the same FS.
For a multinode its shared backup directory and all the backups go into the FS , i have seen with IBM and HP.
Now comparison arised due to like this in DB6 or Oracle how de we write scripts whenever we have the FS above some threshold it should be backed up so as to release the free space.
Now to your question , i think i have seen in both IBM and hp the paths might be different but they were pointing to the same FS.
probably forum members can share
info regarding how they have seen in their in appliances Log/data path. log/data backup paths same fs or a different fs.
Thanks,
I think you are now mixing the 4 parameters that are involved in this.
The parameters 1) and 2) are for the running database and should be different filesystems as these storage locations have indeed very different specifications for there KPI's. What kind of hardware the hardware verndor uses is up to the hardware vendor.
The 3) and 4) are used to store the database data and log backups. The best practice for these two locations is that they are also on different filesystems and these should not be on the same location as 1) and 2). Even better the data and log backup location should not be in the same server as were the SAP HANA is running.
Maybe it is confusing that after an SAP HANA installation the parameters basepath_databackup = $(DIR_INSTANCE)/backup/data and basepath_logbackup=$(DIR_INSTANCE)/backup/log look very identical, but the are pointing to different locations.
I must admit that in the Oracle world I haven't often seen disk backup areas, because backups were mainly written directly to tape.
On SAP HANA side I have recently come across a situation where a company located log backups, data backups and trace files on the same disk area. This disk area filled up to 100 % and as a consequence - nothing happened! At least not in the first place: Data and log backups were no longer taken and traces were no longer written, but this didn't impact the running production system directly. It would have become worse if the maximum number of allowed log segments (default: 10240) would have been reached, but in this case the file system was extended after half a day and everything remained stable all the time.
This means: The famous Oracle problem "archiver stuck" illustrated in SAP Note 391 doesn't happen on SAP HANA in the same way and so the log backup area is less critical here.
Indeed, maybe you can't, but Linux can! The problem is that you look at the file system usage instead of the directory usage.
The logbackup location is a different directory then the databackup location, so using the commands:
would give you different size indications.
p517710 sap basis wrote:
... We design scripts based on ...
I haven't written scripts for backing up the log files, but you have.
In your scripts you said you were not able to distinguish between log and data backups. I showed you how you can distinguish between those. So now you can incorporate this in your script and it should work.
On help.sap.com you can find the the documentation on SAP HANA Database Backup and Recovery
Hi Martin,
I don't think that's the case - the archivelog principles are the same for HANA. If the backup volume fills and the database is doing auto-log backups, then the database will freeze if it is unable to rotate the redolog files (because the archivelog destination is full). I've seen this a few times. It is actually trickier to handle than other (unmentionable) databases because simple releasing space on the backup volume does not cause HANA to auto-resume. When last I checked. I presume this will be modified at some point.
Regarding whether or not the *backup* fileystem can be shared for database backups and log backups - yes - why not. And it is the same for most production systems, irrespective of vendor. The only special case for database storage is the redolog destination, which benefits from isolation from other activity, protection from being inadvertently filled and also the highest I/O speed possible to minimize redo write times. As these files are filled they are peeled off the archivelog destination- in HANA's case - the backup/log directory - where it is a straight sequential copy and I/O rate is not a concern.
mark teehan
singapore
It is similar, but different in several area's.
And now looking at your other problem were you cannot recover it might be a good moment to start reading the SAP HANA Backup and Recovery.
User | Count |
---|---|
78 | |
10 | |
9 | |
7 | |
6 | |
6 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.