I just can't connect to Firebird on Ubuntu.
Through the terminal I do:
rafaeljesus#ubuntu:/tmp$ isql-fb
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect .my_database.gdb user sysdba password masterkey;
Statement failed, SQLSTATE = -922
file /tmp/cnes.gdb is not a valid database
Searching on the web I realized that this occurs when the file is corrupted, which is not the case ... I do not know if this is because the file is in gdb. instead of fdb..I do not know about Firebird ...
I really need some help.
As you don't specify any version information, ODS version of the database, if you upgraded the Firebird version, or whether this database was moved from another system etc I provide some options:
The database was created on a 32 bit platform and now moved to a 64 bit platform without backup/restore: older file structures of Firebird (at least ODS 10 from Firebird 1.0 and InterBase 6) are specific to the bitness of the platform: a backup on the 32 bit platform and a restore on the 64 bit platform should suffice
The database was created on a big-endian platform and now moved to a little-endian platform without backup/restore
NOTE: In both cases make sure you create a transportable backup (it is the default, but check).
Another option could be that a restore of the database failed before the full database was restored. Check your restore log and address any errors (see Firebird 2.5 reports "is not a valid database" although it is for a suggestion )
If all else fail: contact a Firebird/Interbase recovery/repair company like IB Surgeon.
Related
I'm considering using remote OS authentication to connect to an Oracle database (version 11g). What are the guidelines for using [remote_os_authent]
Here's what I want to do:
We set up a catalog DB to used by RMAN to store metadata about Oracle databases.
I want to connect to the catalog DB via the local machine and execute this command for resync catalog db:
rman target sys/pass#localdb;
connect catalog catuser/password#catdb;
RESYNC CATALOG;
Is it possible for me to do this through oracle Enterprise Manager job?
(I did this process by calling the execute file, but the problem is that the passwords are clear in the executable file.)
I need it because I do not want user passwords to be available and visible.
I can't use oracle valet for passwordless connection.
Using remote os authentication is considered a bad habit because it is insecure.
If you want to have scripting without having to store passwords in a readable format to prevent leaking passwords, easiest is to use the oracle wallet for this.
This still keeps you busy maintaining passwords in the database and in the wallet but it is pretty safe.
Your connection would be something line sqlplus /#tns_alias
where the tns_alias is the key into the wallet that fetches the username and the password.
An example of setup can be found here: http://ronr.blogspot.com/2017/01/cleartext-userid-and-passwords-in.html
An other option could be to enable Central Managed Users (CMU) and kerberos. This does need quite a bit of setup and is less suitable for scripting. For interactive use it works very nice, assuming you have kerberos correctly setup.
An example of CMU setup can be found here: https://blog.pythian.com/part-1-creating-an-oracle-18c-centrally-managed-users-testbed-using-oracle-cloud-infrastructure/
Please change back remote_os_authentication to false. It is not safe because users can easily be spoofed.
All of a sudden one day (on my DEV PC) my Microsoft SQL Server 2012 instance (installed as instance name "SQL2012") would not start (all my other installed instances did). Trying to start it manually under Services failed. I don't recall making any recent changes prior to this. The cause of the failure was a mystery.
On inspecting Event Viewer, under System it showed a rather amusing error message [emphasis mine]:
The SQL Server (SQL2012) service terminated with the following service-specific error:
WARNING: You have until SQL Server (SQL2012) to logoff. If you have not logged off at this time, your session will be disconnected, and any open files or devices you have open may lose data.
checking under Application Event Log, I found these 2 error messages (preceded by a number of MSSQL$SQL2012 informational messages):
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 200, state 7, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
followed by:
Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.
Fearing having lost my system databases (and not having a backup of them to restore - who makes backups of their system dbs anyway??) and needing to access the instance, and attached databases - I was willing to try anything. Even the possible restore of the system databases: Restoring the SQL Server Master Database Even Without a Backup - but that looked quite complex.
Fortunately, I was eventually able to start the instance (thank you to this answer: https://stackoverflow.com/a/59676743/4993856 which I trusted, because Pinal Dave also mentions that particular switch in: SQL SERVER – Script level upgrade for database ‘master’ failed because upgrade step msdb110_upgrade.sql encountered error 926, state 1, severity 25) if I ran:
net start mssqlserver$SQL2012 /T902
This pointed to some issue with the upgrade script... (Remember SQL is installed with instance name: SQL2012, hence the mssqlserver$SQL2012 used above for the named instance).
After some more searching I discovered this post: Installing service pack / cumulative update on SQL Server 2016 / 2017 breaks database engine (not exactly the same SQL version as mine) which pointed to the following possible Region Settings setting (Control Panel [when viewed by 'icons'] > All Control Panel Items > Region > Administrative > "Change system locale..."):
"Beta: Use Unicode UTF-8 for worldwide language support" in Region Settings
THAT WAS IT!!! After de-selecting that option (and possibly restarting my computer), the MSSQL Server 2012 Instance started up without any issue, and I was able to access all my previously attached databases.
I assume the pending upgrade scripts ran successfully. Thinking back about it now, it is possible that I agreed to installing a SQL Update, and never bothered to test access to the instance afterwards.
I also don't recall exactly why I chose to enable that specific setting under Region Settings, possibly due to some Linux compatibility, but it looks like it has become defaulted 'on' in recent Windows builds.
I got the same problem SQL2017 after update Windows Patch Hotfix3391(KB5001228)
after restart server MSSQL Fail to start and event viewer shown error below
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 200, state 7, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Solution
Fix by remove Beta:Use Unicode UTF-8 for Worldwide lang.. in the Region Settings
Then it require restart server. After restart MSSQL can start as normal.
The problem is the msdb_110.sql update script, the script is a bit of a mess, with mixed tabs and spaces (wtf?).
It tries to run a couple of procedures that fail, on startup of sql-server. They fail when the code-page is 65001 (usually because the BETA utf-8 code page option has been selected) and so SQL server fails to start.
This appears to happen any time a SQL Server update is installed. I only experience this error with SQL Server 2017, not 2019
Why?
Don't know? The script is a mess.
Solution
Deselect the use utd-8 code page option
Restart the machine
Start sql server and let it run the script
(optional) reselect the use utd-8 code page option
Restart machine again and sql server
(optinal but recommended) uninstall windows, install a unix and run postgres
Before you close me for a duplicate. I know there is a work around for this at the link below.
My question is: why is this "suddenly" happening? I work at company and we have probably 40+ dts packages running regularly. None have ever had this issue when going between our Oracle and SQL Server 2008 platforms.
I suspect it is because of some update to one of the platforms, or because we migrated to a new server for SQL Server.
Does anyone know what setting this would be that needs to be changed in order to avoid this?
Additionally, every package we create / edit throws warnings for this, however, every legacy package works just fine.
SSIS Package: convert between unicode and non-unicode string data types
You mention that you migrated to new SQL Server. I suspect that you also change architecture from 32-bit to 64-bit which can cause your problems.
To determine this is your case run your DTS/SSIS from command line using default dtexec from Program Files\...\Binn and second from Program Files(x86)\...\Binn.
Second you mentioned that your legacy dts works fine, try to delete their source adapter and recreate it and check if it'll cause your problem.
Possible solution: install 32-bit Oracle drivers and use them
from SQL Server Agent Job in tab Execution Options set Use 32 bit Runtime
Read carefully 64 bit Considerations for Integration Services
To fix this issue I used the connection type:
Microsoft OLE DB Provider for Oracle.
Note I did not have to install any special version
This alone did not fix the issue, I also had to edit my OLE DB Souce connection properties. Under Custom Properties is the choice for AlwaysUseDefaultCodePage. This is by default set to false, when I set it to true this fixed my issue. I have not seen this error come back since.
This statement returns null instead of 64 random bytes:
select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
What is causing it to return null? Database is Oracle 10.1.0.2.0 running on Windows Server 2003 and I want to use the random bytes as salt for password hashing.
Edit: Here's the output from sqlplus:
Connected to:
Oracle Database 10g Release 10.1.0.2.0 - Production
SQL> select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
DBMS_CRYPTO.RANDOMBYTES(64)
--------------------------------------------------------------------------------
SQL>
Edit2: When switching to Oracle 11 the query works. I have no idea why it doesn't work on Oracle 10 but have decided to not use that old database.
It works perfectly. I have tested it on Oracle 12c.
Update
I have checked My Oracle Support(Metalink), however, did not find anything related to this function returning NULL. Certainly, not a bug.
Anyway, looking deeper into the function and it's usage in the documentation, I came across SQLNET.CRYPTO_SEED
SQLNET.CRYPTO_SEED
Purpose
Use the parameter SQLNET.CRYPTO_SEED to specify the characters used
when generating cryptographic keys. The more random the characters
are, the stronger the keys are. The string should be 10-70 random
characters. This optional parameter is required for when encryption or
checksumming are turned on. Encryption is turned on if the
SQLNET.ENCRYPTION_CLIENT parameter is specified for the client and the
SQLNET.ENCRYPTION_SERVER parameter is specified for the database
server; checksumming is turned on if the SQLNET.CRYPTO_CHECKSUM_CLIENT
parameter is specified for the client and the
SQLNET.CRYPTO_CHECKSUM_SERVER parameter is specified for the database
server.
It might be possible that the parameter is not properly set in your environment. I don't have 10g version(obsolete though) to test.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing option
SQL> select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
DBMS_CRYPTO.RANDOMBYTES(64)
--------------------------------------------------------------------------------
427AECD44D27CDF6CDC8F290D9F8079109BAB8AECD7E687E7ADF8E15825BBDF3D746FBC181059443
965B1425B224CC46E8CD07CC2D02B2E023238E8883520A19
SQL>
I wouldn't describe myself as afraid of change - but afraid of new technologies? YES INDEED! Technologies from operating systems, to database servers just seem to become bugged, inefficient and backward the further they "progress"
MSDE 2000 (what they might call "SQL 2000 Express" in today's world)
BACKUP [MyDatabase] TO FILE 'c:\backups\mybackup.backup'
SQL 2008 EXPRESS
Wait up! Its a 'user instance' - to back it up we need to attach it to a server instance
Wait up! To attach it we need SQL Management Studio Express (78MB download)
Wait up! When we login to our .\SQLEXPRESS server instance and try to attach our database it gives us an error that literally looks like a bug in our homebrew dev project:
TITLE: Microsoft SQL Server Management Studio
Cannot show requested dialog.
------------------------------ ADDITIONAL INFORMATION:
Parameter name: nColIndex Actual value
was -1.
(Microsoft.SqlServer.GridControl)
Can someone explain how to backup a user instance of a SQL Server 2008 Express database in T-SQL code?
(sorry if this comes across like a flame at ummmm, Microsoft - I'm actually a huge fan of theirs. Just really angry about things like this! please don't vote me down...)
Um, if it's a user instance, then the simplest backup strategy is to copy the file. (whilst it's not connected to SQL Server).
If you need a more comprehensive backup strategy (e.g. transactional backups), then you really should be looking at a more comprehensive database (e.g. a "normal" one attached to a full SQL Server instance)
SOME KEY TIPS TO NOTE WHEN TRYING TO ACHIEVE USER INSTANCE BACKUP
a.) Connecting
Your connection string should look like this:
Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\MyDatabase.mdf;Integrated Security=True;User Instance=True;Database=MyDatabaseAlias
It is essential that your connection string gives the connection an alias Database=MyDatabaseAlias - this alias cannot be duplicated concurrently on the same machine or your connection may fail.
b.) Backing Up
As pointed out above, the Transact SQL to backup a database is the same on SQL MSDE/2000/2005/2008/R2 - once you have your database attached and aliased!
BACKUP DATABASE MyDatabaseAlias TO DISK = 'c:\backups\mydatabase_20101117.backup'
Whats truly amazing is the bull$h!t errors you can get because your connection string doesnt have the alias Database=MyDatabaseAlias part.
e.g. Unable to open the physical file 'c:\Code\MyProject\App_Data\MyDatabase.mdf' Operating system error 32: "32(The process cannot access the file because it is being used by another process.)".BACKUP DATABASE is terminating abnormally.
c.) Restoring
USE [master]; RESTORE DATABASE MyDatabaseAlias FROM DISK = 'c:\backups\mydatabase_20101117.backup' WITH REPLACE
Do not forget the all essential USE [master]; at the beginning of this statement (and note that its all on one line for those executing the command from a DataContext or similar) If you do, it wont be able to overwrite the existing database because you'll still be connected to it.
Once again, the assortment of totally misleading errors you might receive here, due to an invalid connection string, is endless.