Next, we setup the Oracle TNSName Network Connection in an Oracle folder under the D: directory. We created backup copies of the existing TNSName Network Connection file and altered the file to connect to the server's IP address. Due to the file being an ORA file type that is not originally designated to be opened by a preset program, we opened the file using notepad. In the file, there was a line that had the text "HOST =" and "PORT =" in separate parenthesis. For "HOST =", the IP Address of the server we were connecting to was required. My mentor stated that typing the IP address directly did not work since the IP address was given a name. However, typing in the name associated with the IP address worked instead. Therefore, we we entered in the name associated with the IP address of the server we were connecting to, rather than the actual numbers of the IP address. As for "PORT = ", the preset port associated with the IP address was typed.
After this was set up, we installed the PL/SQL developer, a tool that would allow us to create, add, update, and delete tables in the database once we connect to the server. This was easy to install; it was just like any other software and was not nearly as difficult as installing the database.
In order to connect to a server, a computer must have a client that can connect to it. Therefore, what we did next was to install the Oracle 11g Release 2 32-Bit Client onto the computer. At first, I was confused with this. I didn't get why we were installing a 32-bit client when associating with a 64-bit software. I wasn't even sure if that would work. My mentor assured me that it would work with either a 32-bit client- or a 64-bit client.The only reason why we installed the 32-bit version was because of the PL/SQL Developer, a 32-bit piece of software. In order for the PL/SQL Developer tool to work with the data base, it reqires the client to be 32-bit as well.
Next, we tested the SYS account for the PL/SQL developer and created new users that could be used. Upon opening the PL/SQL Developer, we entered in SYS for the Username field, the designated password for the account, the database name, and what to connect to the database as. We connected as SYSDBA. Before connecting, we turned off windows firewall since leave it on can cause some errors in the connection process. After doing all of this, were were able to connect successfully to the database.
We then created new users by right clicking on the User file and clicking "New..." In the popup window, we were required to fill in the username, the password for the account, and the permissions for the account. First, we created an account with the name "MISADMIN" and tested to make sure it was working properly by logging in to the account. Once we confirmed that it was working, we then made 4 other accounts in the same way, but with different permissions.
To fill the database with tables and data records to test and work on, we then transferred test data records from the FRS Test Database by exporting and importing those files. First, we created a folder to designate with as to where the exported data should go to. We then opened cmd.exe while connected to the server the test database was in. We used the command "exp" and filled in necessary information such as the username and password. We also created a .log file to record what is exported. After running the program and waiting for a significant amount of time, we finally ended up with both a .log and a .dmp file. The dump file contained all the data records and tables from the test database.
In order to transfer this file from the test server to the server with which the new database was installed, a tool named Total Commander was used. The servers were already connected to each other so, in Total Commander, all we needed to do was to move the .log and the .dmp files over. In the server with the database that we just installed, we opened cmd.exe again and, instead of typing in "exp" for export, we instead did the "imp" command to import it into the corresponding location.
Next, we needed to install the software that would allow us to actually create web applications. In this case, we used the ColdFusion 9.0 64-Bit Enterprise Server as it could be used with the Oracle Database. In making this work, we set up the Internet Information Services (IIS) and the Web Server IIS. We enabled this through windows by going to the Control Panel and running the server manager. Here, we enabled IIS and allowed for Application Development, IIS 6 management Compatibility, and the FTP Server. After installing the IIS, we tested it to make sure it was working by opening Internet Explorer and typing in "http://localhost." What was display was an image of IIS7.
After this, we installed the ColdFusion 9.0 64-Bit Enterprise Server on the same server as the database. This installation was straight forward. It was like installing any other piece of software with a product key. After filling the key in, marking the corresponding settings, and creating an administrative password, the installation of the ColdFusion 9.0 64-Bit Enterprise Server was complete.
We then setup the final settings for the ColdFusion 9.0 Administrator Configuration Site. We connected to the servers IP address and opened the file under the directory CFIDE/Administrator/Index.cfm. There, we entered in the password and changed the settings for each major component: Server Settings, Data & Services, Debugging & Logging, Server Monitoring, Extensions, Event Gateways, Security, and Packaging & Deployment. Each one of these component consisted of many different sub settings. Once all of these were set properly (which took a long time due to the immense number of settings), the installation of the Oracle Database and ColdFusion Web Application Development Platform was complete.
Overall, this entire process of completing this work assignment took 9.5 hours in total and spanned over 2 days.
No comments:
Post a Comment