[DownByLaw123]

I will be moving the SQL config database from my BES server to a SQL server in a few weeks. My DBA group wants to move it first to a test SQL server which can go up and down from time to time.

I understand the config database holds handheld specific info in it - phone logs, handheld settings, etc... But what if that SQL database is out of the picture for let's say 20 minutes? Will the handhelds still get mail? Or without that SQL database in the loop, will the BES lose all user account info and just sit there?

I want to move the SQL db straight to production SQL server and I want to let DBAs know the answer to this topic.

Thanks

[ocman]

Mail will still flow but PIM Sync updates will not function correctly since they need the database. New Policy changes and updates will not function as well as any additions or modifications to users.

Thats what I understand from reading a guide another member distrubuted to me.

[bfrye]

I don't think they will actually. We've had the database go down before, and we just get continuous SQL query errors from our controller logs.

[ocman]

You have way more posts than me so I suspect im probably wrong here.

[bfrye]

That's with GW bes though. It could be different with exchange or notes, but I doubt it. Theoretically I would think there would be nothing to tell the server what's been checked and what hasn't yet. So it would either continuously send mail, or send nothing I guess...

[ocman]

Here is what the DOC I had reads. Its a little jumbled.

v4.0ComponentConsequences when SQL Server database is unavailable to the BlackBerry EnterpriseServerThe Management ConsoleThe Management Console cannot connect if the database is unavailable.


No administration can be done while the configuration database is unavailable.The BlackBerry DispatcherThe Dispatcher cannot compare new keys that the mailbox agent retrieves from user mailboxes or the Domino Profiles database against the read-only copy in the configuration database.


It cannot detect if any new users have been added and it cannot read the user-to-mailbox mapping table updates.

The BlackBerry Policy ServiceThe Policy Service needs to be able to check the database for new User Policy Templates and any pending commands to user handhelds that need to be pushed out.

BlackBerry Mobile Data ServiceThe main thing that the Mobile Data Service needs to access is the user PIN-to-email address mappings table. If the database is unavailable, the effect is minimal because this information is cached by the Mobile Data Service while running.BlackBerry Synchronization Service•


If the database is not available, the Synchronization Service cannot determine what PIM sync updates need to be handed off to the Mailbox Agents for updating user’s mail files.

•Any new device configuration changes that the Synchronization Service receives from devices cannot be written to the database while it is unavailable.

•The Device Management Information database updates from the handhelds to the database in SQL cannot occur while the SQL database is unavailable.

[bfrye]

Well sounds like browsing/IM/etc will be unaffected, but mail will stop flowing in or out since it uses the database to track changes in mail status.

[ocman]

More info I found.

What to expect if database is not available.
BlackBerry Enterprise Server status
Consequence of configuration database
failure on the BlackBerry Enterprise
Server
Warning
Running


The following activities may not be affected for several hours, but during an outage the BlackBerry Enterprise Server should be considered to be in a “Failure Condition”.

•Email redirection, calendar updates and the Mobile Data Service (including push applications)

The following activities are immediately affected:
•The BlackBerry Enterprise Server Console cannot be opened
•Policies cannot be pushed to devices
•PIM data synchronization requests are queued until the database is back online
•Administration activities (for example, adding and deleting users or changing IT policies) cannot be performed

Do not shut down the BlackBerry Enterprise Server when the SQL configuration database is unavailable. This immediately stops email redirection and the server cannot restart without the database available.
Starting up


If the configuration database is not available at startup, the BlackBerry Enterprise Server cannot start.
If the BlackBerry Enterprise Server is already running when the connection to the database fails, then do not restart the BlackBerry Enterprise Server because it interrupts operation.
Shutting down

If the SQL connection is lost while the BlackBerry Enterprise Server is shutting down, it has no effect on the BlackBerry Enterprise Server. The BlackBerry Enterprise Server reads the database upon startup, not shutdown.
—

[udontknowjack]

Guys, you are assuming downbylaw123 has 4.0 but we don't know what version of BES is being used. With 3.5 or 3.6 the database can be down indefinitely and mail will still flow. The only thing you can't do is manage the BES, ie: add/remove users.

Sorry, I didn't read the rest of the post abobe All that info is completely correct.

With 4.0, the document above is correct. I will add, hower that if the database is down with 4.0 on Exchange, mail will flow for about 3 hours but don't restart the BES or mail will quit completely until the database comes backup. Certin info is cached on the bes to allow mail to flow if the database is unavailable but if you restart the BES, then the cached info is lost and BES 4.0 won't start unless it can connect to the database.

[bfrye]

right jack... I think the dispatcher, sync and policy services will fail to start without database connectivity

[jibi]

Originally Posted by udontknowjack

Guys, you are assuming downbylaw123 has 4.0

He is.

Originally Posted by udontknowjack

but we don't know what version of BES is being used.

Sure we do. Well, I'm sure ocman and bfrye didn't actually look at his past posts, and I personally didn't until you posted this. hehe. But with BES admins who have posted here more than 5 times, they will have usually mentioned their BES version.



and FYI, yes, I'm bored.

[DownByLaw123]

Sorry for lack of info:
BES 4.0 / Exchange
All handhelds on 4.0

I have talked my SQL DBAs into letting me move the SQL config DB straight to a production SQL server, so all is well there.

I am interested, though, in this line of comments. With the SQL database now on a separate server, when the server team does quarterly Windows patching, and that SQL box reboots - those 10-15 minutes the BB's will be squirrelly. Patching is always a late change, but still, it's good to know how the BB's will be affected.

thanks to everyone for their responses.

[bfrye]

Just to avoid any mishaps, I might see about rebooting the BES server after the SQL server has come back up. At least with GW it can have some quirky results after coming back up.

[jibi]

DBL, i would imagine that patching would be somewhat scheduled, correct? if it is, just plan on doing patching of the BES at the same time and have the reboot occur (as recommended by bfrye) just after the SQL server comes back online. two birds (possibly an entire flock), one stone.

and speaking of birds, my car took the brunt of about 10 birds' irritable bowel syndrome this morning. *sigh*

[amukhey]

Simple, if the SQL Server is down / cant connect, BB Dispatcher svc goes offline and cannot send / receive mail, any otac or otafm will be processed. Basically it will try to contact the sql server and wont be able to-it has to access the besmgmt db and if it cant do so, then it wont do anything. This is experience on the Domino end as recent as 1 week doing a sql move to a remote sql server.

[Northern_Monkey]

I don't visit here as much as I should but here's my 2 pence worth.

Our SQL DB was on a BES server and it needed a rebuild. So prior to this a standby server was built with BES installed. Services were transferred over and stopped on the original BES - tested OK users happy.

On the SQL we published the database and setup on another SQL server to read the published database. So any changes made on the SQL were being replicated to the other SQL.

We then changed on the BES console the SQL server name (or IP) to point to the new SQL.

The BES server was rebuilt as well as a new SQL server. We then exported the database and again amended the BES console to point to the new SQL server.

All in, the DB very portable and you can throw it around left right and centre. The backup of is easy as well as the restore.