I have intersystem cache database file (cache.dat around 160MB). From management portal, I created a new database which point to my file.
But when i go for mounting the file into database, it gives me an error -
ERROR #86: the database default collation is not available
Please help me on this.
For your information i am using intersystem cache version 2011.1.2
Make a COPY, convert copy with cvendian:
noddy#chopin 11:24:36 /scratch3/noddy/chopin/mgr/db16k
$ ../../bin/cvendian CACHE.DAT
This database is little-endian.
This database has a block size of 16384 Bytes.
This database has 1 volume and 1 map.
The last block in the primary volume is 768.
Original manager directory is /home/isc/cache/mgr/db16k/
No extension volumes.
Done converting CACHE.DAT to big-endian
Hope this appears in a timely fashion
That means that you either trying to mount Unicode database on 8 bit system (or vice versa) or you are trying to mount a database with collation that is not installed to your cache system. In the last case you will need to install a locale file with required collation. You can look into cconsole.log file in mgr directory to see if there is a better error description there.
I had this problem, and I believe it was because I was trying to mount a database that was big-endian on a little-endian system (or maybe the other way around--doesn't really matter.) I'm not certain this was the problem, but it's the only difference I can think of between the two databases I was trying to mount.
Related
Basically when creating new database, PostgreSQL make directory in "data/base" with OID.
Now I have a directory like this from my previous database, can i import this directory as a real database in pgAdmin?
I have a folder from my old database called 16384.I past it in my data/base folder but pgAdmin does not recognize it as a database.
I want to import it in my Pgadmin.
Is there any way to do this?
Thanks a lot.
no. you can't do it with pgadmin.
try starting postgres with your data_directory pg_ctl -D DIR_WITH_BASE_CATALOG. If you lucky to star it, you can try taking a full backup - if success, the directory is usable, if not, you would recommend asking experts to help you extract as much as possible. If you decide to use zero_damaged_pages or other advanced features you can irreversibly destroy data (if there still is what to destroy)
anyway, before you start, I'd recommend copying the whole data_directory to somewhere else, and trying to start cluster from copy, not original...
I am pretty new with postgresql and pgAdmin and I made a beginner error.
I changed the hard drive of my computer and unfortunately (and stupidly I really admit) I have not make a backup of my database in pgAdmin3 before. Is there anyway I can manage to transfer it back from my old hard drive to the new one?
I tried to copy the file "Data" of pgAdmin from the old hard drive to the new one but it did not succeed. Is there any hidden file that would retain information of my database still on the old hard drive?
If I re-install the old hard drive, would I be able to access the database back?
if anyone have any idea I would be really glad,
thanks
Do as "Richard Huxton" suggested, then
On Windows you need may need to set PG as a Service
Run the following on the command line (as adminstrator):
pg_ctl.exe register -N postgres -D "C:\Program Files\PostgreSQL\9.6\data"
Start the service
answer from:
Register and run PostgreSQL 9.0 as Windows Service
Three steps are required:
Copy everything in the data folder (base, global, ... pg_xlog, ...)
Make sure the permissions are right
Make sure you have the same version of the PostgreSQL binaries installed.
Then just point the configuration at it (data_directory) and start it up. If there are any problems, check the logs for details - it'll probably be permissions.
Sometimes it's convenient to do all this in a virtual machine if you have that sort of stuff set up already.
I am receiving this error message while creating DB from a .mdf and .ldf files located on a network drive.
Query executed:
create database DatabaseName ON
(FileName = '\\gyancluster-sql\g$\Backup\WSS_Content_DB.mdf'),
(FileName = '\\gyancluster-sql\g$\Backup\WSS_Content_DB_log.ldf')
for attach
GO
Error
The file "\gyancluster-sql\g$\Backup\WSS_Content_DB.mdf" is on a
network path that is not supported for database files.
So what is your problem? What is the question? No question there - just dumping a sentence ;)
I mean, without wanting to sound too sarcastic, but you CAN read, or?
The file "\gyancluster-sql\g$\Backup\WSS_Content_DB.mdf" is on a network path that is not supported for database
files.
That is pretty clear, isn't it? It is not supported - for VERY good reasons, btw., until now.
Are you asking us now whether MS lies? No, they do not lie - this is not supported. They REALLY MEAN what they say.
There are ways around (http://support.microsoft.com/kb/304261) but that is it ;)
Do you want us to reword the error message? Maybe into "dude, that wont worx, not cool, see"? Clearer?
Seriously - soudns harsh, but I always wonder why people do not actually READ the error message.
Use DBCC TRACEON(1807) before trying to create the Database.
Also, you can add the linea "-t 1807" to the MSSQL server startup parameters, it will make the change permanent. The command above let you use network storage, but on a reboot you will lose the flag.
You are lucky that the OS is warning you that opening database files directly over a network is a bad idea. Older database api's let you do that with no warning and then network users of that database application are forever blighted with corrupt databases.
If \gyancluster-sql\g$ refers for Local Disk G on the computer gyancluster-sql which also happens to be where the sql service is running, then you really should be using
create database DatabaseName ON
(FileName = 'G:\Backup\WSS_Content_DB.mdf'),
(FileName = 'G:\Backup\WSS_Content_DB_log.ldf')
for attach
GO
Note this remains true even if you are running the script from another computer.
It would still be a bad idea, but you may able to use the UNC names, but only if the service under which sql is running is able to access the share(eg if running under the Domain Administrator account), but that is normally considered an unnecessary security risk.
If you are really trying to store the database on network device, then obviously that means the sql service does need access to the share, so that would be the first thing to check, but you also need to read the Microsoft article which Chris Dickson has pointed you to (ie http://support.microsoft.com/kb/304261) which details when this is supported.
You need to enable the database file over network shared, the following post explain step by step how to do it.
https://blogs.msdn.microsoft.com/varund/2010/09/02/create-a-sql-server-database-on-a-network-shared-drive/
The same post explains the risks to do it.
I hope this helps
Regards
My EC2 database server failed, preventing SSH or other access (not sure why ... grrr AWS ... that's another story).
I was able to make a snapshot of the EBS root volume. I can not boot a new instance from this volume (I'm guessing the boot partition is corrupt). However, I can attach and mount the volume on a new instance.
Now I need to get the PostgreSQL 8.4 on the new machine (Ubuntu 10.04) to load the data from the mounted volume. Is this possible? I've tried:
pg_ctl start -D /<mount_dir>/etc/postgresql/8.4/main/
But no joy ... PostgreSQL just starts with empty tables.
Is /etc/postgresql/8.4/main/ the correct location for PostgreSQL data files?
Is there a way to recover the data from the mounted volume in a way that PostgreSQL can read again?
(You should really specify your distro and version, etc, with this sort of system admin question.)
Running Pg via pg_ctl as shown above should work, assuming the original database was from Pg 8.4 and so are the binaries you're trying to use to start it. Perhaps you forgot to stop the instance of PostgreSQL automatically started by the distro? Or connected on the wrong port, so you got the distro's default instance instead of your DB on another port (or different unix socket path, for unix sockets)?
Personally I wouldn't do what you're doing anyway. First, before I did anything else, I'd make a full backup of the entire data directory because you clearly don't have good backups, otherwise you wouldn't be worrying about this. Take them now, because if you break something while restoring you're going to hate yourself. As demonstrated by this fault, trusting Amazon's storage (snapshot or otherwise) probably isn't good enough.
Once you've done that: The easiest way to restore your DB will be to, on a new instance you know you don't have any important data on that has the same major version (eg "8.4" or "9.0") of postgresql as your original instance did installed:
/etc/init.d/postgresql-8.4 stop
datadir=/var/lib/postgresql/8.4/main
rm -rf "$datadir"
cp -aR /<mount_dir>/etc/postgresql/8.4/main/ "$datadir"
chown -R postgres:postgres "$datadir"
/etc/init.d/postgresql-8.4 start
In other words: take a copy, fix the permissions, start the DB.
You might need to edit /etc/postgresql/8.4/main/postgresql.conf and/or /etc/postgresql/8.4/main/pg_hba.conf because any edits you made to the originals aren't there anymore; they're on your corrupted root FS. The postgresql.conf and pg_hba.conf in the datadir are just symlinks to the ones in etc under Debian - something I understand the rationale behind, but don't love.
Once you get it running, do an immediate pg_dumpall and/or just a pg_dump of your important DB, then copy it somewhere safe.
i usually have my database updated in my development machine.
I need to transfer it to the client using some media like cd, dvd, pendrive or other.
When the client copies it and attaches it in his computer it shows readonly format and no transaction is allowed.
I don't know what i am missing to make it work?
Steps i follow:
1.) Copy database files from my computer to thumb drive
2.) hand Over it to client
3.) Client copies it to his machine
4.) removes previous one and Attaches the DB
I need to transfer it to the client
using some media like cd, dvd,
pendrive or other.
When the client copies it and attaches
it in his computer it shows readonly
format and no transaction is allowed.
Check whether the FILES are read only to start with. Not sure - but if the MEDIA is read only, I think file copies are read only, too.
It isn't totally clear what you did, but what happens if you just remove the READONLY setting? Even if it fails, you may get a useful error message that helps to point you in the right direction:
ALTER DATABASE MyDB SET MULTI_USER
And you should probably review "Copying Databases to Other Servers" and sp_detach_db in Books Online to make sure that whatever exactly you're doing is actually supported. For what it's worth, BACKUP and RESTORE is often the easiest way to go in my experience.
Just give write permissions to the SQLite file in the assets folder (if you are using a database of yours).