Geir Otto Olsen (THInc Consulting AS) asked a question.
12.8.9
When I try to connect to \\prd-fs04\KompisBackup\AI, I am able to do so from cmd..
I am getting following error in the kompis.lg:
This is the setup:
What can be the reason?
This is not at all clear to me.
The only errors I see in your log excerpt are related to TLS, from a server. The AIMGT lines look fine.
I don't know what this means:
> When I try to connect to \\prd-fs04\KompisBackup\AI, I am able to do so from cmd..
I see you have two list items in your -aiarcdir, and one is a UNC path. Does "second area" refer to the second item in the list?
The AIMD doesn't write to both directories simultaneously. It writes only to the first one for as long as it can. If it fails then it tries, from that point on, to write to the next archive directory in the -aiarcdir list.
Also, you should not use remote shares (e.g. UNC paths, NFS/SMB paths, etc.) with -aiarcdir. You should write locally and then have a separate procedure to copy/move files from the local archive to a safe location, e.g. a DR server.
Thanks Rob, you got it.. I have had it like that in 11.7, but I will definitely drop UNC and use robo-copy to copy them.. if g: fails, we have other problems... so that is good enough.
Intuitively, it sounds like a good idea to use a remote directory with -aiarcdir, to get archived extents off the production box as quickly as possible. But in practice it should not be done.
In case anyone is curious why I say this, there are two reasons. First, not every disaster involves the production server being unusable. There can be disasters where the machine works fine but the database is logically or physically corrupt beyond repair, the the recourse is to restore from backup and roll forward AI files. If the backups or AI files are only available remotely, and must be copied back to the production server, this extends the outage.
Second, remote file system connections are not as robust as local ones. I had a situation many years ago where the -aiarcdir was an NFS share and it went stale. The AIMD attempted to write to it and could not. It was unresponsive and we could not disconnect it from the database. Ultimately we had to restart the database during the business day.
Intuitively, it sounds like a good idea to use a remote directory with -aiarcdir, to get archived extents off the production box as quickly as possible. But in practice it should not be done.
In case anyone is curious why I say this, there are two reasons. First, not every disaster involves the production server being unusable. There can be disasters where the machine works fine but the database is logically or physically corrupt beyond repair, the the recourse is to restore from backup and roll forward AI files. If the backups or AI files are only available remotely, and must be copied back to the production server, this extends the outage.
Second, remote file system connections are not as robust as local ones. I had a situation many years ago where the -aiarcdir was an NFS share and it went stale. The AIMD attempted to write to it and could not. It was unresponsive and we could not disconnect it from the database. Ultimately we had to restart the database during the business day.