Hi guys!
I have a problem and I dont know to get it solved.
Here we go:
My company is migrating from London, USA and Canada to Brazil (where we are based) more than 400 databases.
The problem is, I need to analyze all those dbs quickly and as faster as possible.
What I need to check, before migration, is if all those databases are web or client, if it is linked to other databased - has comunication between them -, if will be any future problem if we migrate and etc.
I’ve tried the Teamstudio widgets and the Ytria widgets too, to scan and analyze and search for some words like Ips, numbers and etc. They dont fit to our problem.
What I want to know from you, guys, is if are there other widgets ou plugins or any other way to analyze 400 databases and its elements as conections, links, sizes, modification dates, anything that doesnt take 3 or 4 months to solve.
Are there a solution for my problem that is fast enough to read 400 databases and return me all those information, so I can put it together in an excel sheet?
Thanks in Advance.
Subject: Analyze
I am not aware of any tools that will do that.
However, if the applications are well written (by a competent developer) they should have a profile document where all the servers it is connecting to are defined.
That kind of info should never be hard coded in the actual program code. And you should never use IP addresses, always use either Domino server names or FQDN.
This is an example from one of my applications: Imgur: The magic of the Internet
As you see I soft-code a lot of information, like database names and location, folders to read/write data from, file names, etc.
If you just move all the servers and keep the same DOmino server names, everything should work. But ff you have IP addresses hard-coded, you are screwed… You might be able to use TeamStudio Configuaror to perform a search-and-replace for the known IP addresses, but it will still take a lot of time.
To find out if the databases are web or Notes client there is no easy way. You have to check each database and the documentation left by the developer, or the original specifications/development request. This is why I request that anyone at my company who want a database deisgned write a detailed specification which is then submitted thourgh out (Notes-based) ticket system. That way we have a clear record what every application is doing.
Subject: Suggestion
As Karl has said without any good documentation your best bet would be to basically build the servers in Brazil with the old server name. Might be able to eliminate dbs that you know are replicas and just have them use the existing replica copy that is on the Brazil server. putting a replica copy of catalog.nsf on the servers and the catalog task will give you a feel for what dbs are replicas.
You should know that when the user access the server by the same name and and diff ip address it first use the savedipaddress field in the address book (location doc) and on failure will look for what is in the fqn name on the servers doc and then at dbs to resolve to the correct ip address.
Subject: I realized that
Ok Guys,
Thanks you so much.
I realized there’re anything I could do but analyze all dbs. It’ll take so much time but as I can see its the only way to do that.
As karl said, I’ll try use Teamstudios Configurator and Barry’s suggestion will be applied too.
Thank you both again.
Best regards.
Gabrielle Souza
Subject: TeamStudio does have a module that reports design elements as docs…
I remember using it to find things similar to this.
Word of advice: start a profile in every database with this kind of data. Don’t leave it to massive search & replace the next time an app is relocated to another server. Once it’s in the profile, you know where you’ll go to change it.
It’s the start of “loose coupling”, and there’re very explosive things you can do with the concept. I define way, way more stuff there: what views are opened, formulas for the view key, what Web services are requested, even validation & translation formulas that users keep shifting what they want to do.
Profiles aren’t always easy (and their caching scheme is annoying). But they make so much else, easier.
