hcidbdump -r -D -d threadname questions

Gerand,

With 100,000 messages in the database, it will take a bit to delete them.  It may appear that your screen is locked up, but don’t get too anxious.  The command is still being executed in the background.   By hitting the ctrl-c, I’m surprised that it didn’t corrupt your database.  NEVER do a

ctrl-c while running an hcidbdump command.  Since you used the -D option, the messages would have been deleted.

Next time, just be patient.   Your prompt will come back without having to run the ctrl-c.  Just give the command time to execute.   The length of time depends on how many messages are in the database.

Hope this helps…

Tom Rioux

Are the 100,000 messages still in the database?  Since you deleted the outbound thread, try deleting the messages using the inbound thread, provided it is still there.  Use the following command to delete the unwanted messages:

hcidbdump -r -f -D

Is the inbound thread still there?  If so, MAKE SURE you take the inbound thread down before doing this and let the messages you do want pass through.  That way you don’t delete any good messages by mistake.

Hope this helps…

Tom Rioux

Hi Gerand,

Like Thomas mentioned, ctrl-c is a major no-no.

However, if your config is such that the inbound thread has more than one outbound thread, you should not execute “hcidbdump -r -f -D”. Thomas is not exactly wrong, but we don’t have the full picture. 😛

I’ve done ‘hcidbdump -r -d -D’ before, but like Thomas mentioned, with large amount of messages, it will take forever…but it will get there….:)

By the way, did you stop-start the process of the inbound thread? Otherwise, the routing of the messages to the deleted thread will continue.

We also use the -F flag at the end of the hcidbdump command.  Manual says this ….. -F deletes sent messages.

Command we normally use….hcidbdump -e -D -d thread_name

Another handy flag is U (username)

hcidbdump -r -D -U MIKE

This uses a different user name of your choice while running the command. This way if you do control-c, you don’t hose the engine’s TEST user name. If you control-c with user MIKE on accident, then use user JANE next time.

Ah Michael: you made my day!!

I hadn’t seen this option and have just implemented it in one of our ‘check’ scripts that we execute every morning to see if everything is running ok. Sometimes when an interface is down, the list of messages in the recovery database is enormous and you will almost automatically control-c to stop the list.

I now use this -U option to use a different user and also lmclear this user first when running the script. Works like a charm.

Thanks!!

I want to add my thanks to Mike for sharing what I think will be an improvement over our currently required standard for doing backend hcidbdbump commands.

Little peices of saved greif really add up when you have a big multiplier (many sites and many interfaces).

MD Anderson Cancer Center currently has a required integration team standard that prohibits doing ctrl-c no matter how long you have to wait on hcidbdump but still happens sometimes.

Then we typically get out of it by doing

    lmclear -u TEST -mp

I like Mike’s approach much better because it never puts the TEST user at risk.

I’m going to present my interpretation seen below of Mike’s method for doing backend hcidbdump commands to our integration team and have them vote on it becoming our new required standard.

    lmclear -u RUSS -mp

    hcidbdump -r -U RUSS whatever_else

    ctrl-c or whatever_else

    lmclear -u RUSS -mp

Since everyone on our team has been burned by this from time to time, I think unanamous approval will be a slam dunk.

more on -U: If you embed the -U parameter into scripts you can still get user ID collisions when using constant strings. One way to minimize the chance of that is to use the process pid (ksh $$ variable or TCL “pid” command) as the User ID.

I use $$ all the time for temp files to prevent collisions but this is another clever use that you pointed out, thanks.