Is there a faster way to shut down a database than proshut

I'll try to explain this in very simplistic manner. It is the state that matters in starting and stopping a DB, so shutting a DB will always take more time.

1. When starting a DB, the DB is at rest, not accessible and hence there are no ongoing transaction and/or activities being performed on it. So the amount of verification and validation needed to start the DB are very minimal (comparably).

2. When stopping a DB, the DB is active and there is lot of activity going on. The shutdown command needs to make sure that all those activities are either finished or rolled back in full before the DB can be stopped, resulting in a consistent DB state.

In theory it should be better to allow for all processes to undo their transactions when db shutdown is initiated. Otherwise they will be rolled by in single threaded mode by broker at next db startup. So the -F option to shut db down can be a bad choice. Though I did not verify this in the tests.

BTW, we can easy get the time of crash recovery at db startup. It's the difference between broker login time and db startup time:

FOR FIRST DICTDB._DbStatus NO-LOCK,
    FIRST DICTDB._Connect  NO-LOCK
    WHERE DICTDB._Connect._Connect-Id EQ 1:
 DISPLAY  DICTDB._Connect._Connect-Time
          DICTDB._DbStatus._DbStatus-LastOpen
 WITH SIDE-LABELS 1 DOWN.
END.

or the interval between the messages:
BROKER 0: (333) Multi-user session begin.
BROKER 0: (10471) Database connections have been enabled.

I agree with Akshay.

And I'll add a little bit that you can try using the -shutdownTimeout parameter with the PROSHUT utility.

From the OpenEdge documentation:

[quote]

-shutdownTimeout [ immed | maximum |n[ h | m | s]]
Specifies the amount of time for normal database activity to stop and users be disconnected before
immediately shutting down (killing users still connected). If all normal activity ceases before the
timeout value is reached, normal shutdown proceeds. If not specified, the default is 10 minutes. 

[/quote]

However, keep in mind that those transactions that do not have time to rollback by the time the database is stopped still require time to rollback during the next start of database.

-shutdownTimeout immed

Shutdown occurs in approximately 60 seconds, regardless of transaction backout status

proshut -F waits only 5 seconds:

[2018/01/31@11:27:45.893+0300] P-3644       T-8376  I SHUT    5: (452)   Login by George on CON:. 
[2018/01/31@11:27:45.893+0300] P-3644       T-8376  I SHUT    5: (-----) Warning: The Force Access (-F) option has been specified.
[2018/01/31@11:27:45.903+0300] P-3644       T-8376  I SHUT    5: (5316)  Emergency shutdown initiated... 
[2018/01/31@11:27:50.907+0300] P-3644       T-8376  I SHUT    5: (2250)  Database killed by George on CON: 
[2018/01/31@11:27:51.407+0300] P-8936       T-7824  I BROKER  0: (453)   Logout by George on CON:. 
[2018/01/31@11:27:52.408+0300] P-8936       T-7824  I BROKER   : (334)   Multi-user session end. 
[2018/01/31@11:28:18.920+0300] P-3644       T-8376  I SHUT     : (334)   Multi-user session end. 

Both options mean: "kill the processes even if they are still rolling back their transactions".

Thank you for all your posts Sirs.  I understand very well that in case of opened transactions it is expected to take time to shut down a DB.

However, in my tests, I just do not start any transaction, and I even play with one single User.

To tell you all, I am working at solving an old interesting problem : our App works with a main DB, and an additional DB rather rarely.  Until now, for this 2nd DB, our guys used to apply the following pattern ;

    1-connect,  2-do-something   3-disconnect.  

I'd like to stop that and keep long term connections for performance sake (let alone the log file), but some like the ability to be able to shut down that additional DB without causing error 778 and 735 (error reading socket etc...) in the client sessions when it is not used, which I like the idea.

 => don't make me wrong, for the main DB with long term DB bound code, I know very well there is no way to do that and it is fine.

Now, it seems that I have found a reliable way to catch and handle these errors 778 and 735 as long as we keep the connection quite (not DB bound .r code kept in memory, nor any dynamic buffer, and of course no transaction).

As I am testing this, I need to often stop and restart this local 2nd DB of mine, a DB that has a very tiny activity (just one single quick read), then I started to wonder whether it would it be possible to reduce these long 30s for a simple shutdown

Could it be faster if I start the DB with a small value for some parameters ?  (-L  -B etc...)

TIA

Hmmm, perhaps the solution was too simple:

  proshut -F -by    takes about 33s to complete.  

  proshut -by         takes just about 6s to complete.  

 =>  So I should just have tried to not use -F , at least for a first attempt.

The answer was too simple after all...  for this pretty idel DB:

 proshut -F -by   takes 33s to complete

 proshut -by       takes  6s to complete.

I should just have tried to not use -F, at least for a first attempt.

> proshut -F -by   takes 33s to complete

Progress version?

Proshut -F sets a shutdown flag in shared memory and then waits a few second before it start killing the processes (if they are still connected to a database). The timeout is not tunable and it can depend from Progress version (but I'm not 100% sure).

(bizarre I've posted something this morning, but its seems to be lost.)

My progress version is 11.6.2

Finally, I believe I have found out the answer.  A bit too simple to be honest...

   proshut -F -by    takes about 33s to complete

   proshut -by  (no -F) takes only 6s

So, my mistake was to use -F systematically, perhaps because I had seen a DBA doing this way in the past.

Indeed, if the DB is idle, with few connections and no transaction, then a simple proshut is capable of shutting it rather quickly  (I'm happy with 6s indeed).  Doing -F seems to do a lot more, for nuts.  Never mind, now I will wait a bit before using that -F option.

(bizarre I've posted something this morning, but its seems to be lost.)

My progress version is 11.6.2

Finally, I believe I have found out the answer.  A bit too simple to be honest...

  proshut -F -by    takes about 33s to complete

  proshut -by  (no -F) takes only 6s

So, my mistake was to use -F systematically, perhaps because I had seen a DBA doing this way in the past.

Indeed, if the DB is idle, with few connections and no transaction, then a simple proshut is capable of shutting it rather quickly  (I'm happy with 6s indeed).  Doing -F seems to do a lot more, for nuts.  Never mind, now I will wait a bit before using that -F option.

[bizarre I keep trying posting something since this morning, but it keeps vanishing]

My progress version is 11.6.2

Finally, I believe I have found out the answer.  A bit too simple to be honest:

  proshut -F -by    takes about 33s to complete

  proshut -by  (no -F) takes only 6s

So, my mistake was to use -F systematically, perhaps because I had seen a DBA doing this way in the past.

Indeed, if the DB is idle, with few connections and no transaction, then a simple proshut is capable of shutting it rather quickly  (I'm happy with 6s indeed).  Doing -F seems to do a lot more, for nuts.  Never mind, now I will wait a bit before using that -F option.

(I get this same bizarre behave of forum... when posting frantically... all post won't remain .. as amatter of fact, only the first post remain.)javascript:void(0);

you see what I mean?  that void(0) isn't mine  (last one is first time in my life I write void(0) ... so this is second ;)