Setting up Logs in a SQL Anywhere v17 High Availability Mirrored Server System

[former_SQLA_member1694877]

Hello,

I have been working to set up a SQL Anywhere v17 High Availability mirrored server system. In particular I'd like server logs and have a couple of questions:

1) I am using the -o option to create server message logs. We can cause some confusion if the log files are all just placed in a ./Logs directory. Are there any "best practices" for how to "segregate" log files here:

A) ./Logs/Primary, ./Logs/Mirror and ./Logs/Arbiter

B) Place a ./Logs directory in the each of the three (Primary, Mirror and Arbiter) database directories

2) Is there any recommended size for the -os option in the dbsrv17 launch command to limit the size of the log file before a new log file is created?

Thank you.

[VolkerBarth]

Just to understand option B:

Does it mean all your database dirs are located on the same physical drive? (I would expect all three database servers are running on separate HW...)

[former_SQLA_member1694877]

Hi Volker,

Option B came from some confusion. Per your prior response, the logs file is for the server so putting it "the database directory" makes no sense as soon as we have 2+ dbs. Given three servers, each on its own host I plan to have a directory "alongside" the various database directories to contain the log files for that server.

Thanks!

[former_SQLA_member1694877]

Hi Volker,

This is my 1st question on this forum and I think I have misused it in the sense that I don't see any way to "give you some points". If you care, please tell me what I did wrong in all of the back-and-forth and if there is a way to thank you with points for all of your responses.

Thanks.

[VolkerBarth]

No need to fear "mis-use" here - we're friendly people and don't work for points...

FWIW, there are several ways to "reward" postings:

• Questions and anwers can be upvoted and downvoted.
• Comments cannot be voted, but you can "like" them (see the right most icon below each comment). (You cannot however "dislike" those.)
• The person asking the question can "accept" an answer as fitting/best answer by clicking on the "check mark" icon below the downvote in front of the answer.
• By clicking on the same icon again, you can undo your vote - but AFAIK only within 24 hours.
• If you want to choose a comment as "accepted answer" then that is not directly possible. However, there's a tool to turn comments into answers and vice versa - which might not be available to you until you reach a certain point level. So, if there's that need, you ask someone to do so.

But as stated, there's no need to "pay" for help:)

---

Just to add: You can also reply a comment to a comment (thereby making a nested comment) via the "reply" tool below each comment. That's what I have used here.

[Breck_Carter · Accepted solution]

(1) There is no "best practices" other than "avoid confusion" which you already understand.

IMO the -o files should be named [whatever].txt because they are text files, not database.log files.

IMO the -o files should go in the same folders as the *.db files.

IMO the creation of extra folders increases confusion. For example, if the *.db, *.log and *.txt files are all going to be placed on the same drive, put them in the same folder. Of course, if the *.db and *.log files are being placed on different drives for performance, they must go in different folders.

(2) Choose a -os value depending on the program used to browse the files. For example, if memory serves, Wordpad has problems with files larger than 10M.

(3) Congratulations on using -o and -os! ...they are very important in a production environment.

[former_SQLA_member1694877 · Accepted solution]

Hi Breck,

Thanks for the quick reply and in such detail! I have a follow on:

I thought I had read somewhere that the database folder should be kept clear of all files (other than the .db and .log of course). Given your recommended location, was that advice incorrect?

Thanks.

[VolkerBarth · Accepted solution]

FWIW, I always keep the console log files in a separate directory, mainly for three reasons:

• the DB engine may run several databases, and the log belongs to the engine, not to a particular database.

• In test environments, the log may be used further on, while the DB files may be exchanged by a new set of those.

• I like to keep the DB dir free from different files.

Just my 2 cents, anyway...

[VolkerBarth · Accepted solution]

For a HA system, I would think each partner/arbiter should use a local console log folder. When using a "shared" folder (i.e. one not local to the engine's machine), you would have the problem that a missing connection may both lead to a failover and one of the servers would not be able to access it's log file so he cannot tell what has happened...

[former_SQLA_member1694877 · Accepted solution]

Hi Volker,

Thanks for your input. It sounds like you "adhere" to the advice that the database folder be kept clear of all files other than the .log. Is this a "best practice"?

Thank you.

[Breck_Carter · Accepted solution]

I'm a contrarian... is it a "best practice" or is it an "old habit"?

The practice of creating different folders for different file types often causes great confusion among maintenance staff. In some cases, there are legitimate technical reasons for keeping certain types of files segregated in separate folders (multiple transaction logs for a single replicating database, database and transaction logs stored on separate drives for performance, etc).

In the absence of real technical reasons, avoid unnecessary folder proliferation... 1 folder is simpler than 2, or 10.

[VolkerBarth · Accepted solution]

I guess "my personal best practice" to prefer only database files in the database file directory has its root in the usage of SQL Remote/MobiLink, because - AFAIK - their offline transaction file dir should only contain log files (besides the .db files). As I'm commonly using the real database file directory for the offline logs, too, I keep that "clean". (And BTW, I also follow Breck's advice to prevent unneccessary folders...).

But as Breck has clearly stated, there are several different and reasonable approaches here, so there's no one single "best practice", methinks.