Search results for query: *

As long as the directory in which the the database was cataloged is intact, you can use " "DB2 CATALOG DATABASE xxxxxx ON PATH yyyyyyyyy" Where yyyyyyyy is the path to the database directory. After you've installed the software and recreated the instance if necessary. This works fine in AIX...

I'd like to export the contents of a table directly to tape (4mm DAT or DLT). I've seen the procedure somewhere but I can't recall where. I know that a "named pipe" has to be created but I cannot recall the sequence of commands. I'd also need to know how to re-import that same table...

I believe the instance's userid is what creates the message file eventhough you may have logged in and imported using another id. There the umask will be reflective of the instance owner not the id running the import. I know it didn't work let that before, but I noticied something changed after...

I've had this some problem. It seems that the directory you wish to write the message log must have write permission for the instance owner. It doesn't mention that in the documentation and that requirement somehow changed between release 7.1 abd 8.1

I've found that mirroring LVs then brokening the mirror is the easiest and quickest way to move LVs from one device to another. You'd add the new device to the current volume group. Issue "lsvg -l yourvolumegroupname" Then use smit the mirror all of the LVs in that volume group...

You could implement Network Information Services (NIS). That would keep all of your servers in sync.

Looks like you'll have to recompile the Oracle DBD. You'll get that kind of message when the versions of perl didn't match for particular modules. I guess you've already noticed that the migration to AIX5 for AIX4.3.3 completed wipes out all of you perl add-on modules and you'll have to...

After the install, did you run the "db2imigr" command as root ?

Two are at least two ways I can think of but there are probably more: 1. The database configuration was changed from: LOGRETAIN=RECOVERY to LOGRETAIN=OFF 2. A LOAD utility was run with COPY NO and without NONRECOVERABLE as parameters. As I said there may be more but those are the cases I've run...

You can download the edittor "vile" from ftp://invisible-island.net/vile I've used this to edit some very large files. Feels like vi only better

The last time this happened to me, I ended up copying and deleting files the with .so and .a suffixes. Somehow shared libraries remain open even though the application is stopped. Hope this helps. [dazed] I believe this happened with DB2 or BMC-patrol, it was a long time ago.

See thread Thread178-641780 [thumbsup]

If you issue the command: db2 get database configuration for xxxxx (x's = database name) Look at the line: "Path to log files" This will show you where the log files are stored. Beyond that, I don't know who you'd be able to read their contents. [3eyes]

I've seen this happen when the filesystem was exported. I've had to "exportfs -u xxxx" and also had to remove the filesystem entry from /etc/exports. I've also had to kill the parent of a child process which may have used the filesystem. hope this helps

To cause to LOAD not to place the table in BACKUP PENDING, you can use the parameter NONRECOVERABLE instead of COPY YES/NO in the LOAD command. I know this works in version 7 and it may work in version 6 (UNIX). Version 8 will only lock the table during a LOAD rather than the entire tablespace.