[Apologies, this may be a google-driving-failure; sure I've seen this documented somewhere, but I can't find it. I'm seeking a reference I can pass to colleagues.]
I am addressing the scenario of deploying multiple Project/WAR Runtimes to an MFP server environment, that environment using an Oracle database.
We see the documented requirement:
Each configuration for a MobileFirst runtime environment must use a
different runtime database or schema
And as for Oracle there is a one-one mapping from user to schema, in the WAR deployment instructions we see
For Oracle, the database user must be different.
The question here is about the privileges necessary for those Runtime users.
For the other schemas, used by the MFP server itself, there are table-creation scripts that are run during server-creation. Hence the DBAs can run those scripts, grant necessary privileges and at runtime the MFP servers users do not need capabilities such as table creation.
What privileges do these Runtime users need? I think they will at least need to create tables? Is there a point when it is safe to remove those privileges? That is, is there dynamic table creation?
The privileges the Runtime users need are listed in the documentation on the page that provide you manual installation steps for installing the Runtime
"Setting up your Oracle databases manually"
http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.deploy.doc/admin/t_setting_up_your_oracle_database_manually.html?lang=en
Those privileges are : CREATE SESSION, CREATE SEQUENCE, CREATE TABLE
There is no dynamic table creation.
The same privileges are used when you install Runtimes using Ant tasks or with the Server Configuration Tool.
Basically, it is not a good idea to remove the CREATE TABLE privilege for the user after the Runtime installation because you may run into trouble when performing an upgrade
to a new release in which one or more tables may have been added.
Related
Is there any other way to run tSQLt on a SQL Server database without sysadmin role or ALTER TRACE permission?
We are currently trying to use a test tool called SQLTest from Redgate which uses the tSQLt framework. We have installed it successfully on the database with the sysadmin role, but no one is able to use the tool apart from the person with the sysadmin role. Anyone else who tries gets an error message relating to permission.
I've been in touch with Redgate support and all they tell me is that the sysadmin role is needed or at least ALTER TRACE permission. These are elevated permissions and shouldn't be given to all users on a database.
Any help would be appreciated.
It is not clear exactly what your use case is but...
Typically, developers would use SQLTest and/or tSQLt on a local sandbox e.g. SQL Server Developer Edition installed on their laptops. If that is the case, most orgs should have no problems allowing developers to be sysadmin on their own locally installed SQL Server instance.
If you are using this on a shared SQL Server instance, again this should be a DEV environment where, hopefully SQL devs are allowed to administer their own dev environment.
I can't imagine any org allowing developers sysadmin access in a production instance but then you really shouldn't be using tSQLt in production anyway.
I might be wrong, but I believe it's only db_owner that's required to run tSQLt tests. Might depend on what procedures you're testing. Almost all of our tests are just data quality AssertTableEmpty tests.
If you have the Redgate Toolbelt (or SQL Compare, specifically), you should be able to create personal dev databases on the fly, make your changes, run the tests, then SQL Compare back to shared dev db.
There are two things at play here. tSQLt requires the executing principal to have permissions to alter any object in the database. Usually, you achieve that by making them part of the db_owner role.
Redgate SQLTest requires (in some circumstances) additional permissions. For example, the ALTER TRACE permission is needed to execute the code coverage tool that comes with SQLTest.
In addition to the above, there is a file called prepareserver.sql that needs to be executed once per SQL SERVER (not per database). It requires sysadmin privileges.
So, if you cannot use dedicated environments as #datacentricity recommended, you can execute tSQLt directly and not use SQLTest, or figure out which options to disable if you want to use SQLTest.
Like others here, I strongly recommend you use dedicated environments to do your development, independent of tSQLt.
I have a question regarding the purpose of some service in sql. What does the process, the purpose of them.
OracleSchedulerXE
OracleORADB19Home1MTSRecoveryService
OracleOraDB19home1TNSListner
OracleRemExecServiceV2
OracleServiceXE
OracleVSSWriter
I tried to find something about OracleSchedurXE but I did nt find anithing.
Thank you.
If I Google any of the service names, I get back several pages that go into detail about what they do.
OracleSchedulerXE is used by Oracle for the dbms_scheduler package that lets you schedule jobs to run inside the database.
OracleORADB19Home1MTSRecoveryService is used for interacting with the Microsoft Transaction Server. Most commonly, that is used to allow applications to manage distributed transactions that involve Oracle and other Windows services.
OracleOraDB19home1TNSListner is used for the TNS listener.
That's the process that allows users to connect to the database from remote machines.
OracleRemExecServiceV2 is a service used by the Oracle Universal Installer during installation that will be removed once you reboot after a successful install.
OracleServiceXE is the service that actually runs the Oracle database
OracleVSSWriter is a service that interacts with the Windows Volume Shadow Copy service to ensure that backups see files in a consistent state.
I developed an application that used SQL Server database 2017. I wrote most of the business logic in stored procedures, triggers & UDF. Now at the time of Go-Live, I want to deploy a compiled database on a client-server machine so no one can view or change scripts.
I can manage this from the SQL Security, access rights, etc. but actually, the Client network administrator has all the credentials and rights of the database and I do not want anyone to view/change the script even the administrator.
can I deploy a compiled database on a client-server instead of a regular one so no one can view/change scripts but can execute them Similarly like EXE file users can execute it but cannot view/change the code?
Does Microsoft SQL Server provide a solution on this or any workaround?
please suggest thanks in advance.
I've been following Microsoft's guide for installing a dev environment on Windows 7:
http://msdn.microsoft.com/en-us/library/ee554869.aspx
In order for it to not run like a dog I've created a SQL Server 2008 instance on our database server specifically for this dev machine. The article does mention that you might be wanting to use an external database in regard to making sure the database cumulative update is installed. It doesn't make any other mention of configuring it to use a external database. I was hoping that the configuration wizard would then prompt about which database to use but annoyingly it just set-up the configuration database locally.
How do I go about installing SharePoint on a dev environment with an external database, and will I need to reformat this machine and do it all again?
Well, this depends on what your environment looks like. For instance, is this machine part of a domain?
If so, it should be as simple as selecting "Server Farm Install", or something like that when you did the binaries installation. Then, when you run Products and Configuration Wizard, it will ask you for DB info. Note: if you are doing this, I would recommend you to be part of the 'sa' role on the database server as you will be creating databases.
If you are not part of a domain, it gets a little trickier, but not too bad. Check out this article.
http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=112
-= Plan B =-
You can always give this a whirl. This is the method we use to keep the DB guys from screaming. It also allows us to give our databases nice names.
http://technet.microsoft.com/en-us/library/cc262869.aspx
Simple problem. I'm working on a Delphi 2007/WIN32 application which now uses MS Access as simple data store. I have to modify it to support SQL Server Express, which is easy. These modifications are working so the application can be deployed using either SQL Server or MS Access. (Whatever the user prefers.) I did consider deploying the whole application together with the SQL Compact but this is not practicak. Using SQL Server Express 2008 instead of 2005 is an option, but also has a few nasty side-effects which we don't want to resolve for now.
The problem is deploying the whole project. The installation with SQL Server would need a quiet installation so the user won't notice it. SQL Server is mentioned in the documentation so they know it's there. We just don't want to bother them with technical issues. In most cases, such an installation will go just fine.
But what if the user already has an SQL Server (2005) installation which is used for something else? Personally, I would prefer to just install a second instance of SQL Server on their system so it won't conflict with the other installation. (Thus, if they uninstall the other app, the SQL instance will just stay installed.)
While SQL Server 2005 and 2008 can be installed on the same system simply by using two different names for the instance, I wonder if it's also possible to install SQL Server 2005 twice on a single system to get two instances. And if possible, how?
To answer your question: yes SQL2005/SQL2008 and SQLExpress2005/2008 can all live happily side by side. The default instance name for the SQLExpress install is [machine name]\SQLEXPRESS. But having said that, you should consider giving your customer the option to use the sql instance they already have, and only install a new instance if they choose to.
I don't know if SQLExpress can be installed silently (most likely it can as long as you specify the right properties on the command line when you install it). But we have rolled it out to lots of customers, and they have very few issues installing it normally.
Edit: I have added this as an edit because a comment doesn't allow enough.
I understand your reluctance to both having the user install SQL manually, and to sharing another instance. To address these points:
uninstalling a product should never automatically uninstall the SQL instance, even if that SQL instance was put there when installing that product. By all means the database can be blown away, but uninstalling a SQL instance should be a manual process, as it is a server product that may be used by many other products
you can make your task a lot easier by using a decent installer product. For instance, we use InstallShield. It has a sql browse dialog built in (its a baked in feature of InstallShield) that the user can use to select which sql instance and database they want to use for our product. The details the user enters are then inserted in to the web.config file using an XML file change task (also functionality baked into InstallShield). By using dialogs like this you eliminate a lot of potential user errors.
if there is already an existing sql instance, use it. The only dependence your database should have on the instance is that it is the right version (i.e. SQL2005, and 2008 is fine for a 2005 database). The only time you should demand your own instance is if you are processing/storing enough data that you require your own server, or if you are depending upon undocumented features. If the existing instance is already under heavy load, then insisting on a new instance on a different server is fine, but then you have also avoided that whole side-by-side situation. Alternatively you could just install in to the existing instance and get the customer to commit to upgrading the hardware.
I hope this helps somewhat - i'm just trying to persuade you that there are limited reasons for needing a separate instance and that 99% of the time you will be fine installing in to an existing instance. It's nice to have your own instance but in reality it brings you few real benefits, especially if you are using a robust installer.
You can install SQL Server Express in silent mode using the /Q command line switch or use the /QS command line switch to see setup progress without user input. You can install a named instance on a system that already has SQL Server installed.
http://msdn.microsoft.com/en-us/library/ms144259.aspx
There are a number of reasons why it is very useful to have your own instance of an SQL Server.
You can decide for yourself what type of authentication you use (SQL authentication or Windows authentication). Although Windows authentication is recommended, scenario's exist where this is simply not an option. And enabling SQL authentication for an instance where other products use the same instance is a security risk.
You can safely assume that your product is the only user of the installed instance. So with installing and uninstalling the instance you know the version and databases in use by that instance. No extra detection needed, as long as different versions of your product use the same SQL configuration and version.
Isolation of your installments (files, registry keys, dll's and other products) is a very good practice!
Also, uninstalling an SQL Server instance doesn't lead to data loss, because the data files of the databases will not be removed. After reinstalling, you can attach the data files again if needed.
that being said, SQL Server express can be installed in three different interaction modes:
Full UI, including SQL license agreement acceptance
Silent, but with detailed progress UI
Silent, without any progress UI (and suppressed errors!)
Detailed instructions for installation can be found at http://msdn.microsoft.com/en-us/library/ms144259(SQL.90).aspx