Laura Thomas's questions

I have a database server that supports a single application. Sadly much of the configuration of this box is strictly controlled by the vendor. So in the event we change things they may discontinue support.

Apparently one of their scripts has stopped running, because since June 15 we have been accumulating tons of files who's names have the following format: ARCxxxxx_xxxxxxxxxx.001 They are all basically just under 25MB. What are these files? The content is binary, they appear not to change once written (looking at the backups of this server and what's in the incrementals). Can I just delete them? They appear to be some sort of transaction logging based on the number generated when compared to our work weeks?

Vendor Support has not been forthcoming and has just told me "that shouldn't happen, the script should deal with them." But they won't tell me which script. I'm not getting error logging in the event logs. Is there an oracle log that might tell me which script is failing so I can see if I can figure out why?

Server: Windows 2003 Oracle: 10.2.0.3.0

First a quick overview of the environment:

• NetBackup running on Windows Servers (6.5.4 if you care) with LTO3 drives.

• The backup target used to be a Solaris 9 server, on Sun hardware, with Veritas Volume Manger.

• Rebuilt as RHEL5 box using LVM to manage the volumes, now on a Xiotech SAN. With a large number of volumes.

The nature of the data and the application that the box runs (Optix) is such that it used to write to a volume until it reached a certain size and then that volume was locked forever more. Hence we have \u01 \u02 \u03 ... \u50. A while back (still on the solaris build) we expanded and opened those volumes back up for writing so in any given day any or all of them might change. Backup throughput used to average 40MB/sec.

In the new Linux build we're averaging something closer to 8MB/sec. Given that here is 2.1TB of data here that's sort of wildly unacceptable, even running 4 streams it is taking 48+ hours to complete. I/O on the server is pegged. I am pretty sure it's not the SAN because other clients using the same class of storage and similar server hardware are backing up at a pokey but tolerable 20MB/sec.

I'm looking for ideas on improving throughput. The Solaris guys in the office next door are blaming LVM on Linux. Nobody thinks it's the backup environment, because that's still performing as expected everywhere else. The admin of the now very slow box says "I don't know it's not me, the users say it's fine." Which is probably true because it's a document management system and they're reading and writing small files.

Troubleshooting ideas? Has anybody seen LVM trash backup or other I/O performance? Especially given a largeish number of volumes holding a very large number (10 million maybe)of small files?

Edited to correct units.

Edited to add:

NIC is at 1000/Full (as checked from both the OS and Switch)

Filesystem is EXT3.

More new information....

The performance hit appears to be happening on several boxes running LVM and EXT3. Basically all the new RHEL5 boxes we built this summer.

The university where I work uses DHCP for the vast majority of our IP addressing needs. Workstations and the like.

However for servers we obviously use static IP addresses. The current method to figure out if an IP address is available works like this.

1. Guess an IP in the data center range, or look for one that doesn't show on the spreadsheet created nightly from the managed switch
2. ping it if it responds go back to step 1 if not procede to step 3
3. nslookup on it and see if anyone else has named it

About 90% of the time this works fine, but it is labor intensive, and not perfect. Given 10 administrators and about 300 servers in the main data center, and another 50 or so servers in our secondary data center, it seems like there should be a solution.

For static IP addresses (printers, MFDs, the occasional workstation) in the workstation ranges Client Services uses ipplan. It seems to be missing a few things we'd like: logging of who claimed IPs; multiple logins, preferably with LDAP so we can use existing accounts; a user interface simple enough that when you have to use it only a half dozen times a year it is still easy.

How do you manage your Data Center IP addressing? Do you track it? Is there "the IP address guy"? A paper list on the wall? Some variant on what we're doing with the poke til you find one?

When we deploy a new server currently we do a Nessus scan on the sever from inside the firewall and we do a firewall audit to verify that only the desired ports are open on the firewall (since we do occasionally recycle IP addresses).

What are you doing in your organization? Do you think it is enough? What would you be doing if you could?

So I just got out of a meeting between IT, the Library Archivist, and the Journalism Faculty of the University where I work. One of the things that came up is with the new media form our campus newspaper will be taking one of the things they'll be doing is Twittering. Since this is official publication should be archived.

Does anybody know of a tool that will archive all the tweets from an account, and the direct messages and @replies to that account?

It is possible we will decide this is beyond the scope of archiving, but for now I get to figure this out.

I'm getting ready to migrate a server from old hardware to new hardware. I'm thinking of doing a P2P migration rather than actually rebuilding, reinstalling and migrating databases. The servers are Dell 2950s with Hardware RAID, running Windows.

Options include: using a software solution like Platespin, or break the mirror on the existing server and mirror the drive onto the new server, then rebuild the mirror again on the new server so both drives in it are new drives. All the hardware will be similar, although the targets will be three years newer.

Words of wisdom? Warnings? Software suggestions?