Within the DBWalker Configuration interface, do I have to create multiple configurations for each table/view within a given tablespace? For example, I have one tablespace on Oracle that has 53 tables and 48 views. To be able to search all information that is contained within that tablespace, do I have to create separate configurations for each?
Also, within the "Live Search" page (or the Serach script) when I add a db entry so the search includes a database, is it pulling from the live db or the dbwalker results?
> To be able to search all information that is contained within that tablespace, do I have to create separate configurations for each?
Yes. We're considering more "automated" ways of creating configurations, but each table needs its own configuration.
> when I add a db entry so the search includes a database, is it pulling from the live db or the dbwalker results?
DBWalker itself doesn't cache data, but DBWalker is walked by the appliance just like any other HTML page.
This means that when a search is performed, it's searched against the search appliance's local collection (which is cached), but if a link is followed to the actual DBWalker output, then it will be fetched from the remote database.
> Is there a limit on the number of configs that I can add?
> I guesstimate it will be around 300 or so.
There is no limit built in to DBWalker. Each config makes its own connection to the remote DB, and it's cached for a couple minutes for repeat requests. This means if a profile with all those configs is being walked, the remote DB could have as many as 300 simultaneous connections; as long as it's ok with that, you shouldn't have a problem.
To minimize db thrashing during a DBWalk, should I use separate profiles with each having a portion of the dbwalker configs, then stagger the execution times of the walk?
You could do that. Note that when I said "300 simultaneous connections", that just meant that many connections open, not queries being actively executed on all of them.
The "threads" setting in the walking profile controls how many simultaneous walks will be on the database. If you set it to "1", then even though there may be multiple JDBC connections between DBWalker and the remote DB, only one of them will have activity at a given time.
I was saying that the connection from a config that has been finished walking will be held open a little while in a cache while a new config establishes a new connection.
Sounds like maybe full Texis would be more appropriate for your application than the appliance. It sounds like you're trying to shoehorn a multifaceted database search application into something designed mainly for "page" indexing and searching (where a database record can be treated as a page).
Thanks for the info Jason. Mark called and we talked some since he was concerned with the purchse. I explained to him that I am just seeing how much I can push the appliance. And trying to gain speed vs PHP on the searching/generating graphs pages. Mark suggested opening a ticket where I can ask more pointed questions referencing the internals of the system (closed network here).
